[00:03] Is there a discussion anywhere of how the change of keymap support away from hal to udev-extras is supposed to work? [00:04] (I find that my keymap has spuriously reverted to US layout in current karmic) [00:05] ok i need help i installed the supybot and now i cant find it can someone help === rickspencer3-afk is now known as rickspencer3 [00:51] Has anyone noticed that the daily UNR build link is broken? [00:51] http://cdimage.ubuntu.com/ubuntu-netbook-remix/daily-live/current/jaunty-netbook-remix-i386.img [00:53] That's because Jaunty is released [00:54] And because the dailies are broken ... [00:55] What image is suggested for UNR users? The Download link on the UNR maing page points to the broken link. [00:55] https://wiki.ubuntu.com/UNR#Downloading%20the%20Image [00:55] I'll update the link if someone can point me to an alternative to the daily builds. [00:57] britton: The dailies for Karmic should start appearing soon, but the link to UNR 9.04 is on http://www.ubuntu.com/getubuntu/download-netbook [01:01] Thanks StevenK. I've updated the page referencing the broken daily builds with this link. [01:01] https://wiki.ubuntu.com/UNR#preview [01:03] britton: I'll talk to a few people to get that page updated to reference Karmic properly, too. Thanks! [01:05] launchpad is giving me a "Cannot find your account" warning starting today. However it otherwise appears to be working ok. === hughhalf__ is now known as hughhalf [01:38] * calc beats ooo-l10n with a big stick [01:38] * calc wishes he had a fast enough system to actually build that pos instead of usually just uploading and praying it works [01:39] * calc is going to have to upload it again but this time not until after he has done a full build how ever many hours that ends up taking :-\ [01:39] calc: Does it take longer than OO itself? [01:39] TheMuso: yea [01:39] ...ouch. [01:39] TheMuso: ooo-l10n builds all of ooo then does langpack stuff on top of that [01:39] FAIL :-\ [01:39] Thats... painful. [01:40] and unfortunately it doesn't fail until the install stage now [01:40] and iirc the install stage can't be rerun due to how debian mangles it [01:40] Riiight. [01:40] so i can't just keep rerunning debian/rules install until i fix all the bugs :\ [01:41] and these bugs also would not occur if we didn't have it split into a separate source for the l10n stuff :\ [01:41] Yep. [01:42] * calc isn't sure if having it split actually helps anything, it does seem to cause a lot of pain though [01:44] I don't envy you. [01:44] it would help if the merge of the launchpad translations would be worked on [01:44] we talked about that a while back afaict we have no way to even send lp translations back to upstream, which aiui we can do for other things on lp? [01:45] if that is true we probably shouldn't be hosting translations for OOo until that works [01:45] * calc isn't sure if we could even do that anyway due to the licensing issues involved [01:45] and that hinders ubuntu to merge these in the l10n package? no. [01:46] well it was on the list of things we should we do for OOo l10n support in the email i got a while back [01:46] at 20% time i barely have time to do an OOo build and still be within time constraints [01:47] * calc has been spending way more than 20% the past couple weeks [01:50] of course that isn't to say other people can't fix those issues :) [01:50] doko: i don't see how you can manage to get all your foundations work done within 20% time either, heh === rickspencer3 is now known as rickspencer3-afk [02:27] calc: In the Kubuntu team we've discussed we might give better translation support to our users if we avoided LP hosted translations entirely. [02:38] ScottK: yea === nhandler_ is now known as nhandler [06:56] Good morning [06:56] good morning to you sir [07:13] hi pitti [07:13] calc: meh, oo.o-l10n FTBFSed with "no space left on device" [07:14] ouch [07:14] build oo.o in the cloud! [07:14] nixternal :) [07:14] nixternal: you'd need a mortgage to pay for the build time [07:15] Ouch! [07:15] ... how much space was originally left on device? [07:15] hehe [07:15] calc: trying again on vernadsky [07:15] meh, another ten hours of uninstallability [07:17] but at least the alternates should be buildable now === Tonio__ is now known as Tonio_ [07:52] good morning [07:53] good morning [07:53] why does everyone wake up when I am going to bed? you all need to get on a different routine already! [07:55] nixternal: because you are weird...? :D [07:56] that has nothing to do with you all waking up when I go to bed :p [07:57] good morning [07:58] nixternal: why are you working when everyone else is sleeping? :) [07:58] hey geser [08:00] Hi pitti [08:06] geser: because I am dedicated :) [08:06] which means meeting in like 8 hours right dholbach? [08:06] not 7 hours, hoping you figured out the time changes :p [08:07] nixternal: sounds good to me [08:08] * nixternal kicks kde svn in the pants - hurry up already! [08:09] geser: the truth to me working while everyone is sleeping, is because kde svn :p [08:11] soren: kvm performance in karmic for the d-i text mode is horrible -- did it change the defautl emulated graphics hardware? [08:12] sommer: in jaunty I noticed that only the default crappy graphics hardware worked well, all the "better" ones had utter performance problems [08:12] pitti: Not as far as I know. [08:12] soren: ^ (sorry, sommer) [08:12] pitti: Frankly, I think they've all sucked all the time. [08:12] well, the default worked well except for UNR [08:13] now you can see every single character block being updated [08:13] :( [08:15] (apart from kernel I/O performance becoming worse and worse from intrepid to karmic as well *sigh*) [08:21] pitti: The most recent hal upload makes my XKB layout fall back to "us" - how is this supposed to be configured in the new world of udev-extras? [08:23] maxb: not yet, X.org first needs to learn how to talk to udev [08:23] ah. might want to releasenote that for alpha 1 then :-) [08:23] well, or fix [08:24] maxb: can you please open a bug about it? first time I hear about it [08:24] let's debug it ther then [08:26] maxb: got some minutes for tracking this down? [08:26] Which package should it be on? I don't really understand how the current hal<->xorg magic works, just that it used and to and doesn't any more - let alone how things are supposed to work now? [08:26] maxb: hal, please [08:26] I can spare some time now yes, if that's good? [08:26] maxb: I think I'm 80% sure that I know how to fix it [08:27] maxb: yes, please [08:27] we can still fix it for the alpha [08:28] It seems someone has beaten me to reporting it: [08:28] https://bugs.launchpad.net/ubuntu/+source/hal/+bug/375618 [08:29] Ubuntu bug 375618 in hal "does not pass xkb* settings to xorg server" [Undecided,New] [08:29] pitti: weird that you didn't get the keyboard issue, Keybuk mentioned it yesterday as a gnome-keyring issue and it did the same on my desktop there, I expect it happens for everybody [08:29] seb128: well, I'm _using_ US [08:29] so I never noticed, sorry [08:30] ah right [08:30] we should force the platform team to use non english locales and keyboards ;-) [08:30] * TheMuso would like that if there was an .au layout. [08:30] Or if I could use dvorak. [08:30] Gah, I was about to say "for want of a .au layout" [08:31] * StevenK glares at TheMuso [08:31] seb128: I'm using de_DE.UTF-8 with langpacks, but using a non-US keyboard layout for a programmer is a royal pain :/ [08:31] lol [08:31] pitti: I was just jocking don't worry, in any case many people have the bug if you need testing or details [08:32] let's use bug 375618 then [08:32] Launchpad bug 375618 in hal "does not pass xkb* settings to xorg server" [Undecided,New] https://launchpad.net/bugs/375618 === Nafallo_ is now known as Nafallo [08:34] maxb, seb128: I attached a test FDI to the bug, could you please test? [08:36] It appears to hardcode "us"... is that really supposed to make my layout be "gb" ? [08:36] it sets the evdev property [08:37] 10-x11-keymap.fdi should set the real one later on [08:37] [08:37] debian-setup-keyboard [08:37] that didn't get triggered any more [08:38] ok, restarting X... [08:40] pitti: no change [08:41] ditto [08:41] can you please attach your lshal output to the bug? [08:41] (you did restart hal, didn't you?) [08:41] (even after a full reboot just to be sure) [08:42] ah, crap, my bad [08:42] I did reboot [08:42] xorg >> x11 [08:42] $ lshal | grep layout input.xkb.layout = 'us' (string) [08:42] sorry [08:42] seb128, maxb: can you please rename the file to "10-keymap.fdi"? [08:43] That works :-) [08:43] okay [08:43] now please delete that file again, it was just a test [08:44] Do you want lshal still, if so before or after deleting? [08:44] maxb: not necessary [08:44] I'm preparing a better solution [08:44] I just needed you to try this as a first test to rule out the hal-setup-keymap callout [08:46] pitti: that works now [08:47] pitti: Hmm indeed, the packaging of mpi-defaults was trivial, but not its deps -- on some arches -- sorry about that [08:47] seb128, maxb: ok, can you please try https://bugs.edge.launchpad.net/ubuntu/karmic/+source/hal/+bug/375618/comments/7 now? this is a better solution [08:47] Ubuntu bug 375618 in hal "does not pass xkb* settings to xorg server" [Undecided,New] [08:47] lool: I uploaded a new boost without MPI for now [08:48] pitti: is there a way better than rebooting every time, I just restarted all my applications [08:48] seb128: restart hal and gdmflexiserver -l should work [08:48] pitti: I think mpi-defaults can build without the heavy bdeps since it builds without them on some arches; perhaps we could simply avoid them on all arches [08:48] since that starts a new x [08:48] ok [08:49] lool: yeah, I didn't feel like really tracking down this last night; if you see a better solution, please go ahead [08:50] pitti: that one doesn't work [08:50] pitti: Oh! It's working here [08:50] wait [08:50] maxb: yay [08:50] pitti: That's good enough for A1 and I don't want to touch it before A1 :) [08:51] lool: right, I meant after A1 :) [08:51] seb128: if it doesn't work, can you please attach lshal to the bug? [08:51] pitti: sorry that works, this command line didn't have a sudo cookie and was waiting for my password [08:52] heh [08:52] seb128: glad to hear this [08:52] seb128, maxb: many thanks for your time [08:52] thank you for the quick fixing [08:52] * seb128 hugs pitti [08:52] and sorry for messing this up [08:52] * pitti uploads [08:52] karmic would be boring without some bugs ;-) [08:53] Hey, it's pre-A1, I'd be shocked if nothing broke [08:53] * directhex uploads some bugs to make seb128 feel better [08:59] that's true, karmic is far too stable for my taste :) [09:00] pitti, mono 2.4 packaging is due soon, which should break a few things. it'll shuffle packages on the CD at least, which will hopefully break something [09:00] pitti: if it cheers you up upgrading a couple of days okay hal wouldn't restart :) [09:01] s/okay/ago [09:01] davmor2: yeah, I heard about that one, but that was Scott's fault :) [09:02] pitti: and if you going to break something might aswell break it good right :D [09:04] just enable KMS and UXA, that should be enough breakage [09:04] * pitti has used that for about a week now [09:04] nicely breaks suspend [09:04] at least with my external monitor === tkamppeter_ is now known as tkamppeter [09:18] pitti: did you break the X hal callout script? :) [09:18] at least it's not run anymore [09:18] tjaalton: just uploaded a fix [09:18] pitti: oh cool [09:19] tjaalton: bug 375618 [09:19] Launchpad bug 375618 in hal "does not pass xkb* settings to xorg server" [High,Fix released] https://launchpad.net/bugs/375618 [09:19] yeah, read the changelog === Tonio__ is now known as Tonio_ [09:26] soren: also, in karmic kvm I just get 800x600; do you get the same? [09:29] c/c === quadrispro is now known as quadrispro-acero === quadrispro-acero is now known as quadrispro-acer1 [09:43] pitti: I don't test desktop stuff much, to be honest. [10:11] tjaalton: any idea why xvfb fails in the openjdk-6 build on sparc? [10:13] doko: not offhand, although it sounds familiar [10:15] hi [10:15] where can we find the source for evtest ? [10:17] pARAd0X85: apt-get source joystick [10:17] utils/evdev.c [10:18] or http://people.freedesktop.org/~whot/evtest [10:18] tjaalton, thanks === Keybuk_ is now known as Keybuk === fta_ is now known as fta [10:40] What's the proper way to put translation bugs on the radar of translators? === dpm_ is now known as dpm [10:42] lool: i think the triager is supposed to subscribe the proper translation team for that package [10:43] lool: I usually assign to language-pack-gnome- and ubuntu-l10n- [10:44] lool: alternatively, if it is a general i18n issue, it can be commented on ubuntu-translators, tagged as i18n or listed there -> https://wiki.ubuntu.com/TranslatingUbuntu/Issues [10:44] It's an issue specific to Spain's Spanish versus South-American Spanish variants [10:44] I sub-ed ubuntu-l10n-es and will reassign; thanks! [10:44] (375457 was the bug) [10:45] bug #375457 [10:45] Launchpad bug 375457 in language-pack-gnome-es "Incorrect translation in South-American Spanish for Video folder" [Medium,New] https://launchpad.net/bugs/375457 === SWAT_ is now known as SWAT [11:47] does apport-collect provide the same information as ubuntu-bug? with the distinction that collect csan can be used to add info on a already existing bug. [11:47] taavikko: pretty much, yes [11:47] thanks pitti. [11:49] pitti: you're running with DRI2/GEM/KMS/UXA right? [11:49] Keybuk: yes [11:50] pitti: what did you do to turn that on? [11:50] also, does this work correctly: apport-collect `pidof process` bugnumber ? [11:50] taavikko: apport-collect doesn't work with pids, sorry (that would be pointless) === danilo22 is now known as Danilo22 [11:51] Keybuk: Option "AccelMethod" "UXA" -> UXA/GEM [11:51] Keybuk: $ cat /etc/modprobe.d/i915-kms.conf [11:51] options i915 modeset=1 [11:51] ok, confusion sets in :) [11:52] Keybuk: see https://wiki.ubuntu.com/X/KernelModeSetting [11:53] pitti: does it make a difference? [11:54] davmor2: you can switch between X and VT in no time with no flicker [11:54] and the text consoles are awesomely big (160x50 for me) [11:54] davmor2: oh, and did I mention that it breaks suspend for me with external monitor? :-) [12:02] calc, "Closed, fixed in OOo 3.1 final release." [12:02] pitti: a little bit of video corruption on resume, but otherwise works [12:02] suspend/resume is *FAST* with this [12:02] Keybuk: haven't tested suspend with internal screen yet [12:02] I guess I'll start searchign workarounds for suspend problems on Sunday, when packing my stuff for allhands/uds [12:04] are you at somehands? [12:07] Keybuk: yes [12:07] Keybuk: I'm not sure how many hands I need to bring, though [12:07] ah [12:07] * Keybuk is not Special [12:11] pitti, the name indicates "more than one" :) [12:12] ogra: I think I can just about provide that [12:12] heh [12:15] so how's alpha-1 looking? [12:15] dholbach: we're about this -><- close to producing alternates which will actually give a reasonable isntall [12:16] apart from armel :( [12:16] hi guys! what is the policy for the packages sync'd from debian-multimedia? === DrPepperKid is now known as MacSlow [12:17] ogra: is somebody working on that kernel build failure? [12:17] cjwatson, yes, trying a build with the former binutils here atm [12:17] quadrispro-acer1: happy to resync from there on request (~ubuntu-archive subscribed to bug), anything more complicated I'm not sure [12:18] cjwatson: ok, and what about NEW packages? [12:18] i just did one with V=1 on the make command but that didnt get me very far apart from showing the actual cmd and ending with a segfault again [12:19] I uploaded a couple of pkgs to REVU, probably it's unnecessary but I don't know... [12:28] quadrispro-acer1: revu probably isn't very useful. file a bug and subscribe ubuntu-archive and we'll have a look [12:28] ah, ok [12:28] thanks cjwatson [12:30] Our notifications system uses D-BUS, right? [12:30] Exclusively? [13:10] soren: communication between the application and notify-osd happens over the session d-bus, yes [13:10] pitti: Thanks. [13:11] * soren ponders dbus-over-ssh [13:12] soren: the whole D-Bus when you're running a remote X program problem has never really been solved [13:13] * ogra would pay soren a box of beer [13:13] and you would get a trophy from the ltsp guys :) [13:13] It really shouldn't be that hard, should it? [13:13] it isn't hard at all [13:13] Keybuk, there is gabrial, but its odd [13:13] it's just manically insecure [13:13] *gabriel [13:14] Start a listening unix socket on the server, and just put whatever comes in into the client's dbus server. [13:14] as long as the remote machine is the same architecture, of course :p [13:14] soren: you don't even need to do that [13:14] just make your desktop D-Bus session listen on TCP [13:14] and tunnel that over ssh to the remote end, adjusting the DBUS_SESSION_BUS_ADDRESS envvar [13:15] http://www.eldemonionegro.com/wordpress/archivos/2008/05/22/howto-to-intercomunicate-processes-in-differentremote-machines-through-dbus [13:15] that'd work too [13:15] but then you'll hit a problem if the machines are different ;) [13:16] D-Bus kinda assumes the same byte sizes and endianness [13:16] much more interesting would be a way to mesh bus daemons together [13:16] so you could run a dbus-daemon on the remote machine [13:16] ltsp is looking into this since years and we havent found a safe answer yet ... [13:17] Keybuk: I see. Would it be possible to translate that or can you define arbitrary data types? [13:17] and have that and the dbus-daemon on the local intercommunicate [13:17] of course, then you still hit the activation problem [13:17] if Rhythmbox on the remote machine makes a method call that would activate a service [13:17] on which machine do you activate the service? [13:18] soren: the D-Bus data types are a fixed part of the specification [13:18] Keybuk: So it should totally be translatable by a proxy of some sort. [13:19] as Keybuk mentioned, thats not the main prob, the merging of the daemons is [13:19] and the priorization where to do what [13:19] for example, a client may activate a service and expect some non-dbus-bound communication as a result [13:19] the most trivial example being DeviceKit or HAL [13:20] right, thats the main focus of ltsp [13:20] if rhythmbox asks to mount something, it probably expects that mount to happen locally [13:20] stgraber: how do I change http://iso.qa.ubuntu.com/qatracker/ to not say "candidate images for the Ubuntu 9.04 release" any more? [13:20] ie. on the remote end [13:20] not on the server end [13:20] with network forwarding to the actual desktoip session so it can access it [13:20] a lot of the problem with ltsp is you actually want to mount on the server, but then somehow make that mount also available on the remote/client [13:20] no, the other way round [13:20] no [13:21] the way round *I* said [13:21] the HW is always on the client [13:21] remember that in the X architecture, the server is the machine the user is sitting on [13:21] and the client is the machine the application is running on [13:21] if i plug my ipod into the client i want a message to go to the server [13:21] you plug your ipod into the server ;) [13:21] and i want gvfs to initiate a network mount of the client HW to the desktop session [13:22] why would i go to the server room to do that ? [13:22] ogra: either you're being deliberately stupid, or deliberately confusing [13:22] please stop [13:22] oh, i missed your referral to X above ... thats not how we handle ltsp :) [13:23] X is the key component here [13:23] so we use its terminology [13:23] well ... if you use XDMCP which we dont [13:23] since ltsp5 exists [13:23] and since we're also talking about D-Bus, and its terminology happens to fit, then we can continue to use its terminology [13:23] the Server is the machine that the user sits on [13:23] the Client is the machine that the application runs from [13:23] the Server has the X Server and the D-Bus Bus Daemon (ie. server) [13:24] the Client has the X Client (application) and the D-Bus Client [13:24] the user sits at the Server [13:24] the user plugs their iPod into the Server [13:24] which is the machine also running the HAL Daemon (ie. server), etc. [13:26] stgraber: unping; it was too obvious :) [13:26] right, if you plug in your ipod, hald now needs to send a dbus message to the client that triggers an ltspfs mount of the ipod so it appears in the desktop sessiojn [13:27] exactly [13:27] we were largely saying the same, you just used ancient terminology :) [13:27] I use the *correct* terminology [13:27] so the problem is never really that D-Bus isn't tunneled from the Client to the Server then they are on different machines [13:27] the problem is that it's not as simple as tunnelling it at all! [13:28] pitti: ok if it fails again (i think it probably will, sigh) i know how to fix it this time, i had to run a full ooo-l10n build at home which takes over 8hr to see what was going on, it failed then i think i fixed it and have to run it for another 8 hours (gar) [13:28] if a remote client needs filesystem access to something on the server, you need to have special multi-seat software broker that [13:28] (true for any device access, in fact - e.g. mtp) [13:28] pitti: but i won't be uploading it again until i am certain it builds for me [13:28] calc: okay; we found a workaround for now, to make the alternates installable without -l10n [13:28] brb [13:28] pitti: ok [13:29] much more fun ensues when you talk about power management [13:29] well, and the tunnel wouldnt be any problem we have already various ssh tunnels established on ltsp [13:29] pitti: apparently the install target was reworked between 3.0 and 3.1 and i managed to miss it somehow [13:29] if the client and server both have batteries [13:29] which battery should you show on the panel? [13:29] should it matter whether the battery applet is on the same machine as the server or the client? [13:29] pitti: which causes build failures due to ooo-l10n being split out as a separate source [13:29] * calc will be glad when we can get rid of that mess [13:30] well, i would show both, the prob here is how to distinguish them visually [13:30] i want to know when my thin client runs out of battery as much as i want to know if the machine running the desktop session dies soon [13:31] but if the battery on one of them runs out [13:31] you need a policy that is multi-seat aware [13:31] it's all good fun :p [13:31] in case of batteries, both of them are equally important ... but batteries are definately not the typical HW :) [13:31] this is why the whole "D-Bus over SSH" problem has never been "solved" upstream [13:31] it's a much more difficult problem than it first appears [13:31] yeah [13:32] htough its not actually a dbus problem but rather the on top apps like hal/devkit [13:33] in case of a std. ltsp setup you can simply ignore the system daemon on one side [13:34] since all you want is diredct interaction with the thin client HW through the dbus connection [13:35] if i click shutdown in fusa i want that to power down my thin client, if i use a mic on a thin client i want that to be forwarded to the desktop session, real access to the ltsp server HW is rarely needed [13:36] Keybuk: You clearly thought much more than I did :) All I really wanted to do was to be able to run notify-send on my server and have it magically pop up on my laptop. [13:36] but if the desktop session machine is shutdown, or power goes out, etc. you need the thin-client machines to be notified [13:36] :) [13:36] yeah [13:37] if a removable device is plugged into the desktop session machine, or a CD, etc. you probably want to be able to access that from thin-clients logged in as an administrator [13:37] but i can do that with mounting it under /mnt ... thats really a corner case [13:37] i agree about the power down though [13:37] to solve things properly, you never leave a corner case undusted [13:38] right, but it wouldnt be in my main focus ... rather something lower on the TO=DO [13:38] *TODO [13:38] indeed its convenient ... [13:38] but not a must have [13:39] though if you add polkit to the picture that really gets messy :) [13:39] and consolekit [13:56] anyone here dealing with gnome-system-tools? [13:56] bug #214720 [13:56] Launchpad bug 214720 in nautilus-share "Cannot set LAN name without console" [Wishlist,Confirmed] https://launchpad.net/bugs/214720 [14:06] hyperair: nautilus-share != gst [14:06] seb128: yes i know. [14:06] seb128: i'm about to reassign the bug to gst [14:06] and "no" [14:06] nobody is working on it either upstream or in ubuntu [14:06] seb128: because simply put, nautilus-share is not meant to have any settings further than just configuring usershares [14:06] hi, do you know where i could get help on app development using uinput driver? [14:07] seb128: you mean gst is not being developed upstream or in ubuntu? [14:07] indeed [14:07] or rather nobody is working onit [14:07] on it [14:07] seb128: but the functionality is there, just hidden from view. [14:07] it's a GNOME software still but without an active team working on it [14:10] i see. [14:10] it would be awesome if this could be made to integrate with samba's usershares though === rickspencer3-afk is now known as rickspencer3 [14:34] ok, this is just the worlds most insane gcc syntax [14:34] do { === asac_ is now known as asac [14:34] __label__ enomem; [14:34] /* code that might goto enomem */ [14:34] enomem: __attribute__ ((unused)); [14:34] } while (0); [14:35] Keybuk: suspend with KMS> wow! [14:35] I mean WOOOWW! [14:35] bryce: that's awesome [14:36] pitti: one of the WHOLE POINTS of KMS is that is makes the whole suspend/resume milarky easier, isn't it? :p [14:36] Keybuk: now I just want that working with my external monitor, too, isntead of staying black :) [14:38] I guess usb-creator can't create USB images from alternate CDs, can it? [14:38] keybuk: What's the purpose of that code? [14:40] lool: should be able to [14:43] Cool, thanks [14:47] ion_: C99/GCC equivalent of "break from outer loop" === azeem_ is now known as azeem [14:55] ion_: the __attribute__ ((unused)) is there because this is generated code - so I don't know whether the code in the loop is actually going to use this facility [14:56] I found it odd that the attribute goes on the label itself, not the __label__ pre-declaration/localising [14:56] and that you need the ";" on the end of the label ;) [14:57] :-) [14:57] you've needed ";" on the end of labels at the end of blocks for a little while now - that strictness was added in gcc 3.something IIRC [14:57] or at any rate several releases ago [14:57] I remember tbm filing a bunch of bugs about it [14:57] yeah [14:57] though since that's the primary use of local labels, you'd've thought they wouldn't care about them [14:58] I assume the grammar says that label comes before a statement [14:58] though I guess it makes local-labels-combined-with-statement-expressions nice ;) [14:58] *my* primary use of local labels is: out: do_cleanup_work(); } [14:58] common idiom in the kernel too [14:58] ({ __label__ gotit; int ret; /* something complicated */ gotit: ret; }) [14:58] cjwatson: do you mean local labels, or just labels? [14:59]