| maxb | Is there a discussion anywhere of how the change of keymap support away from hal to udev-extras is supposed to work? | 00:03 |
|---|---|---|
| maxb | (I find that my keymap has spuriously reverted to US layout in current karmic) | 00:04 |
| DarkRavin | ok i need help i installed the supybot and now i cant find it can someone help | 00:05 |
| === rickspencer3-afk is now known as rickspencer3 | ||
| britton | Has anyone noticed that the daily UNR build link is broken? | 00:51 |
| britton | http://cdimage.ubuntu.com/ubuntu-netbook-remix/daily-live/current/jaunty-netbook-remix-i386.img | 00:51 |
| StevenK | That's because Jaunty is released | 00:53 |
| StevenK | And because the dailies are broken ... | 00:54 |
| britton | What image is suggested for UNR users? The Download link on the UNR maing page points to the broken link. | 00:55 |
| britton | https://wiki.ubuntu.com/UNR#Downloading%20the%20Image | 00:55 |
| britton | I'll update the link if someone can point me to an alternative to the daily builds. | 00:55 |
| StevenK | 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 | 00:57 |
| britton | Thanks StevenK. I've updated the page referencing the broken daily builds with this link. | 01:01 |
| britton | https://wiki.ubuntu.com/UNR#preview | 01:01 |
| StevenK | britton: I'll talk to a few people to get that page updated to reference Karmic properly, too. Thanks! | 01:03 |
| bryce | launchpad is giving me a "Cannot find your account" warning starting today. However it otherwise appears to be working ok. | 01:05 |
| === hughhalf__ is now known as hughhalf | ||
| * 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:38 | |
| * 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 | |
| TheMuso | calc: Does it take longer than OO itself? | 01:39 |
| calc | TheMuso: yea | 01:39 |
| TheMuso | ...ouch. | 01:39 |
| calc | TheMuso: ooo-l10n builds all of ooo then does langpack stuff on top of that | 01:39 |
| calc | FAIL :-\ | 01:39 |
| TheMuso | Thats... painful. | 01:39 |
| calc | and unfortunately it doesn't fail until the install stage now | 01:40 |
| calc | and iirc the install stage can't be rerun due to how debian mangles it | 01:40 |
| TheMuso | Riiight. | 01:40 |
| calc | so i can't just keep rerunning debian/rules install until i fix all the bugs :\ | 01:40 |
| calc | and these bugs also would not occur if we didn't have it split into a separate source for the l10n stuff :\ | 01:41 |
| TheMuso | Yep. | 01:41 |
| * calc isn't sure if having it split actually helps anything, it does seem to cause a lot of pain though | 01:42 | |
| TheMuso | I don't envy you. | 01:44 |
| doko | it would help if the merge of the launchpad translations would be worked on | 01:44 |
| calc | 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:44 |
| calc | 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 | |
| doko | and that hinders ubuntu to merge these in the l10n package? no. | 01:45 |
| calc | 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 |
| calc | at 20% time i barely have time to do an OOo build and still be within time constraints | 01:46 |
| * calc has been spending way more than 20% the past couple weeks | 01:47 | |
| calc | of course that isn't to say other people can't fix those issues :) | 01:50 |
| calc | doko: i don't see how you can manage to get all your foundations work done within 20% time either, heh | 01:50 |
| === rickspencer3 is now known as rickspencer3-afk | ||
| ScottK | 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:27 |
| calc | ScottK: yea | 02:38 |
| === nhandler_ is now known as nhandler | ||
| pitti | Good morning | 06:56 |
| nixternal | good morning to you sir | 06:56 |
| ajmitch | hi pitti | 07:13 |
| pitti | calc: meh, oo.o-l10n FTBFSed with "no space left on device" | 07:13 |
| ajmitch | ouch | 07:14 |
| nixternal | build oo.o in the cloud! | 07:14 |
| ttx | nixternal :) | 07:14 |
| ajmitch | nixternal: you'd need a mortgage to pay for the build time | 07:14 |
| StevenK | Ouch! | 07:15 |
| geofft | ... how much space was originally left on device? | 07:15 |
| nixternal | hehe | 07:15 |
| pitti | calc: trying again on vernadsky | 07:15 |
| pitti | meh, another ten hours of uninstallability | 07:15 |
| pitti | but at least the alternates should be buildable now | 07:17 |
| === Tonio__ is now known as Tonio_ | ||
| dholbach | good morning | 07:52 |
| nixternal | good morning | 07:53 |
| nixternal | why does everyone wake up when I am going to bed? you all need to get on a different routine already! | 07:53 |
| jussi01 | nixternal: because you are weird...? :D | 07:55 |
| nixternal | that has nothing to do with you all waking up when I go to bed :p | 07:56 |
| geser | good morning | 07:57 |
| geser | nixternal: why are you working when everyone else is sleeping? :) | 07:58 |
| pitti | hey geser | 07:58 |
| geser | Hi pitti | 08:00 |
| nixternal | geser: because I am dedicated :) | 08:06 |
| nixternal | which means meeting in like 8 hours right dholbach? | 08:06 |
| nixternal | not 7 hours, hoping you figured out the time changes :p | 08:06 |
| dholbach | nixternal: sounds good to me | 08:07 |
| * nixternal kicks kde svn in the pants - hurry up already! | 08:08 | |
| nixternal | geser: the truth to me working while everyone is sleeping, is because kde svn :p | 08:09 |
| pitti | soren: kvm performance in karmic for the d-i text mode is horrible -- did it change the defautl emulated graphics hardware? | 08:11 |
| pitti | sommer: in jaunty I noticed that only the default crappy graphics hardware worked well, all the "better" ones had utter performance problems | 08:12 |
| soren | pitti: Not as far as I know. | 08:12 |
| pitti | soren: ^ (sorry, sommer) | 08:12 |
| soren | pitti: Frankly, I think they've all sucked all the time. | 08:12 |
| pitti | well, the default worked well except for UNR | 08:12 |
| pitti | now you can see every single character block being updated | 08:13 |
| soren | :( | 08:13 |
| pitti | (apart from kernel I/O performance becoming worse and worse from intrepid to karmic as well *sigh*) | 08:15 |
| maxb | 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:21 |
| pitti | maxb: not yet, X.org first needs to learn how to talk to udev | 08:23 |
| maxb | ah. might want to releasenote that for alpha 1 then :-) | 08:23 |
| pitti | well, or fix | 08:23 |
| pitti | maxb: can you please open a bug about it? first time I hear about it | 08:24 |
| pitti | let's debug it ther then | 08:24 |
| pitti | maxb: got some minutes for tracking this down? | 08:26 |
| maxb | 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 |
| pitti | maxb: hal, please | 08:26 |
| maxb | I can spare some time now yes, if that's good? | 08:26 |
| pitti | maxb: I think I'm 80% sure that I know how to fix it | 08:26 |
| pitti | maxb: yes, please | 08:27 |
| pitti | we can still fix it for the alpha | 08:27 |
| maxb | It seems someone has beaten me to reporting it: | 08:28 |
| maxb | https://bugs.launchpad.net/ubuntu/+source/hal/+bug/375618 | 08:28 |
| ubottu | Ubuntu bug 375618 in hal "does not pass xkb* settings to xorg server" [Undecided,New] | 08:29 |
| seb128 | 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 |
| pitti | seb128: well, I'm _using_ US | 08:29 |
| pitti | so I never noticed, sorry | 08:29 |
| seb128 | ah right | 08:30 |
| seb128 | 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 | |
| TheMuso | Or if I could use dvorak. | 08:30 |
| StevenK | Gah, I was about to say "for want of a .au layout" | 08:30 |
| * StevenK glares at TheMuso | 08:31 | |
| pitti | 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 |
| TheMuso | lol | 08:31 |
| seb128 | pitti: I was just jocking don't worry, in any case many people have the bug if you need testing or details | 08:31 |
| pitti | let's use bug 375618 then | 08:32 |
| ubottu | Launchpad bug 375618 in hal "does not pass xkb* settings to xorg server" [Undecided,New] https://launchpad.net/bugs/375618 | 08:32 |
| === Nafallo_ is now known as Nafallo | ||
| pitti | maxb, seb128: I attached a test FDI to the bug, could you please test? | 08:34 |
| maxb | It appears to hardcode "us"... is that really supposed to make my layout be "gb" ? | 08:36 |
| pitti | it sets the evdev property | 08:36 |
| pitti | 10-x11-keymap.fdi should set the real one later on | 08:37 |
| pitti | <match key="input.xkb.layout" exists="true"> | 08:37 |
| pitti | <append key="info.callouts.add" type="strlist">debian-setup-keyboard</append> | 08:37 |
| pitti | that didn't get triggered any more | 08:37 |
| maxb | ok, restarting X... | 08:38 |
| seb128 | pitti: no change | 08:40 |
| maxb | ditto | 08:41 |
| pitti | can you please attach your lshal output to the bug? | 08:41 |
| pitti | (you did restart hal, didn't you?) | 08:41 |
| maxb | (even after a full reboot just to be sure) | 08:41 |
| pitti | ah, crap, my bad | 08:42 |
| seb128 | I did reboot | 08:42 |
| pitti | xorg >> x11 | 08:42 |
| seb128 | $ lshal | grep layout input.xkb.layout = 'us' (string) | 08:42 |
| pitti | sorry | 08:42 |
| pitti | seb128, maxb: can you please rename the file to "10-keymap.fdi"? | 08:42 |
| maxb | That works :-) | 08:43 |
| pitti | okay | 08:43 |
| pitti | now please delete that file again, it was just a test | 08:43 |
| maxb | Do you want lshal still, if so before or after deleting? | 08:44 |
| pitti | maxb: not necessary | 08:44 |
| pitti | I'm preparing a better solution | 08:44 |
| pitti | I just needed you to try this as a first test to rule out the hal-setup-keymap callout | 08:44 |
| seb128 | pitti: that works now | 08:46 |
| lool | pitti: Hmm indeed, the packaging of mpi-defaults was trivial, but not its deps -- on some arches -- sorry about that | 08:47 |
| pitti | 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 |
| ubottu | Ubuntu bug 375618 in hal "does not pass xkb* settings to xorg server" [Undecided,New] | 08:47 |
| pitti | lool: I uploaded a new boost without MPI for now | 08:47 |
| seb128 | pitti: is there a way better than rebooting every time, I just restarted all my applications | 08:48 |
| pitti | seb128: restart hal and gdmflexiserver -l should work | 08:48 |
| lool | 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 |
| pitti | since that starts a new x | 08:48 |
| seb128 | ok | 08:48 |
| pitti | lool: yeah, I didn't feel like really tracking down this last night; if you see a better solution, please go ahead | 08:49 |
| seb128 | pitti: that one doesn't work | 08:50 |
| maxb | pitti: Oh! It's working here | 08:50 |
| seb128 | wait | 08:50 |
| pitti | maxb: yay | 08:50 |
| lool | pitti: That's good enough for A1 and I don't want to touch it before A1 :) | 08:50 |
| pitti | lool: right, I meant after A1 :) | 08:51 |
| pitti | seb128: if it doesn't work, can you please attach lshal to the bug? | 08:51 |
| seb128 | pitti: sorry that works, this command line didn't have a sudo cookie and was waiting for my password | 08:51 |
| pitti | heh | 08:52 |
| pitti | seb128: glad to hear this | 08:52 |
| pitti | seb128, maxb: many thanks for your time | 08:52 |
| seb128 | thank you for the quick fixing | 08:52 |
| * seb128 hugs pitti | 08:52 | |
| pitti | and sorry for messing this up | 08:52 |
| * pitti uploads | 08:52 | |
| seb128 | karmic would be boring without some bugs ;-) | 08:52 |
| maxb | Hey, it's pre-A1, I'd be shocked if nothing broke | 08:53 |
| * directhex uploads some bugs to make seb128 feel better | 08:53 | |
| pitti | that's true, karmic is far too stable for my taste :) | 08:59 |
| directhex | 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 |
| davmor2 | pitti: if it cheers you up upgrading a couple of days okay hal wouldn't restart :) | 09:00 |
| davmor2 | s/okay/ago | 09:01 |
| pitti | davmor2: yeah, I heard about that one, but that was Scott's fault :) | 09:01 |
| davmor2 | pitti: and if you going to break something might aswell break it good right :D | 09:02 |
| pitti | just enable KMS and UXA, that should be enough breakage | 09:04 |
| * pitti has used that for about a week now | 09:04 | |
| pitti | nicely breaks suspend | 09:04 |
| pitti | at least with my external monitor | 09:04 |
| === tkamppeter_ is now known as tkamppeter | ||
| tjaalton | pitti: did you break the X hal callout script? :) | 09:18 |
| tjaalton | at least it's not run anymore | 09:18 |
| pitti | tjaalton: just uploaded a fix | 09:18 |
| tjaalton | pitti: oh cool | 09:18 |
| pitti | tjaalton: bug 375618 | 09:19 |
| ubottu | Launchpad bug 375618 in hal "does not pass xkb* settings to xorg server" [High,Fix released] https://launchpad.net/bugs/375618 | 09:19 |
| tjaalton | yeah, read the changelog | 09:19 |
| === Tonio__ is now known as Tonio_ | ||
| pitti | soren: also, in karmic kvm I just get 800x600; do you get the same? | 09:26 |
| TheMuso | c/c | 09:29 |
| === quadrispro is now known as quadrispro-acero | ||
| === quadrispro-acero is now known as quadrispro-acer1 | ||
| soren | pitti: I don't test desktop stuff much, to be honest. | 09:43 |
| doko | tjaalton: any idea why xvfb fails in the openjdk-6 build on sparc? | 10:11 |
| tjaalton | doko: not offhand, although it sounds familiar | 10:13 |
| pARAd0X85 | hi | 10:15 |
| pARAd0X85 | where can we find the source for evtest ? | 10:15 |
| tjaalton | pARAd0X85: apt-get source joystick | 10:17 |
| tjaalton | utils/evdev.c | 10:17 |
| tjaalton | or http://people.freedesktop.org/~whot/evtest | 10:18 |
| pARAd0X85 | tjaalton, thanks | 10:18 |
| === Keybuk_ is now known as Keybuk | ||
| === fta_ is now known as fta | ||
| lool | What's the proper way to put translation bugs on the radar of translators? | 10:40 |
| === dpm_ is now known as dpm | ||
| LordKow | lool: i think the triager is supposed to subscribe the proper translation team for that package | 10:42 |
| seb128 | lool: I usually assign to language-pack-gnome-<locale> and ubuntu-l10n-<locale> | 10:43 |
| dpm | 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 |
| lool | It's an issue specific to Spain's Spanish versus South-American Spanish variants | 10:44 |
| lool | I sub-ed ubuntu-l10n-es and will reassign; thanks! | 10:44 |
| lool | (375457 was the bug) | 10:44 |
| seb128 | bug #375457 | 10:45 |
| ubottu | Launchpad bug 375457 in language-pack-gnome-es "Incorrect translation in South-American Spanish for Video folder" [Medium,New] https://launchpad.net/bugs/375457 | 10:45 |
| === SWAT_ is now known as SWAT | ||
| taavikko | 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 |
| pitti | taavikko: pretty much, yes | 11:47 |
| taavikko | thanks pitti. | 11:47 |
| Keybuk | pitti: you're running with DRI2/GEM/KMS/UXA right? | 11:49 |
| pitti | Keybuk: yes | 11:49 |
| Keybuk | pitti: what did you do to turn that on? | 11:50 |
| taavikko | also, does this work correctly: apport-collect `pidof process` bugnumber ? | 11:50 |
| pitti | taavikko: apport-collect doesn't work with pids, sorry (that would be pointless) | 11:50 |
| === danilo22 is now known as Danilo22 | ||
| pitti | Keybuk: Option "AccelMethod" "UXA" -> UXA/GEM | 11:51 |
| pitti | Keybuk: $ cat /etc/modprobe.d/i915-kms.conf | 11:51 |
| pitti | options i915 modeset=1 | 11:51 |
| taavikko | ok, confusion sets in :) | 11:51 |
| pitti | Keybuk: see https://wiki.ubuntu.com/X/KernelModeSetting | 11:52 |
| davmor2 | pitti: does it make a difference? | 11:53 |
| pitti | davmor2: you can switch between X and VT in no time with no flicker | 11:54 |
| pitti | and the text consoles are awesomely big (160x50 for me) | 11:54 |
| pitti | davmor2: oh, and did I mention that it breaks suspend for me with external monitor? :-) | 11:54 |
| directhex | calc, "Closed, fixed in OOo 3.1 final release." | 12:02 |
| Keybuk | pitti: a little bit of video corruption on resume, but otherwise works | 12:02 |
| Keybuk | suspend/resume is *FAST* with this | 12:02 |
| pitti | Keybuk: haven't tested suspend with internal screen yet | 12:02 |
| pitti | I guess I'll start searchign workarounds for suspend problems on Sunday, when packing my stuff for allhands/uds | 12:02 |
| Keybuk | are you at somehands? | 12:04 |
| pitti | Keybuk: yes | 12:07 |
| pitti | Keybuk: I'm not sure how many hands I need to bring, though | 12:07 |
| Keybuk | ah | 12:07 |
| * Keybuk is not Special | 12:07 | |
| ogra | pitti, the name indicates "more than one" :) | 12:11 |
| pitti | ogra: I think I can just about provide that | 12:12 |
| ogra | heh | 12:12 |
| dholbach | so how's alpha-1 looking? | 12:15 |
| pitti | dholbach: we're about this -><- close to producing alternates which will actually give a reasonable isntall | 12:15 |
| ogra | apart from armel :( | 12:16 |
| quadrispro-acer1 | hi guys! what is the policy for the packages sync'd from debian-multimedia? | 12:16 |
| === DrPepperKid is now known as MacSlow | ||
| cjwatson | ogra: is somebody working on that kernel build failure? | 12:17 |
| ogra | cjwatson, yes, trying a build with the former binutils here atm | 12:17 |
| cjwatson | quadrispro-acer1: happy to resync from there on request (~ubuntu-archive subscribed to bug), anything more complicated I'm not sure | 12:17 |
| quadrispro-acer1 | cjwatson: ok, and what about NEW packages? | 12:18 |
| ogra | 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:18 |
| quadrispro-acer1 | I uploaded a couple of pkgs to REVU, probably it's unnecessary but I don't know... | 12:19 |
| cjwatson | quadrispro-acer1: revu probably isn't very useful. file a bug and subscribe ubuntu-archive and we'll have a look | 12:28 |
| quadrispro-acer1 | ah, ok | 12:28 |
| quadrispro-acer1 | thanks cjwatson | 12:28 |
| soren | Our notifications system uses D-BUS, right? | 12:30 |
| soren | Exclusively? | 12:30 |
| pitti | soren: communication between the application and notify-osd happens over the session d-bus, yes | 13:10 |
| soren | pitti: Thanks. | 13:10 |
| * soren ponders dbus-over-ssh | 13:11 | |
| Keybuk | soren: the whole D-Bus when you're running a remote X program problem has never really been solved | 13:12 |
| * ogra would pay soren a box of beer | 13:13 | |
| ogra | and you would get a trophy from the ltsp guys :) | 13:13 |
| soren | It really shouldn't be that hard, should it? | 13:13 |
| Keybuk | it isn't hard at all | 13:13 |
| ogra | Keybuk, there is gabrial, but its odd | 13:13 |
| Keybuk | it's just manically insecure | 13:13 |
| ogra | *gabriel | 13:13 |
| soren | Start a listening unix socket on the server, and just put whatever comes in into the client's dbus server. | 13:14 |
| Keybuk | as long as the remote machine is the same architecture, of course :p | 13:14 |
| Keybuk | soren: you don't even need to do that | 13:14 |
| Keybuk | just make your desktop D-Bus session listen on TCP | 13:14 |
| Keybuk | and tunnel that over ssh to the remote end, adjusting the DBUS_SESSION_BUS_ADDRESS envvar | 13:14 |
| ogra | http://www.eldemonionegro.com/wordpress/archivos/2008/05/22/howto-to-intercomunicate-processes-in-differentremote-machines-through-dbus | 13:15 |
| Keybuk | that'd work too | 13:15 |
| Keybuk | but then you'll hit a problem if the machines are different ;) | 13:15 |
| Keybuk | D-Bus kinda assumes the same byte sizes and endianness | 13:16 |
| Keybuk | much more interesting would be a way to mesh bus daemons together | 13:16 |
| Keybuk | so you could run a dbus-daemon on the remote machine | 13:16 |
| ogra | ltsp is looking into this since years and we havent found a safe answer yet ... | 13:16 |
| soren | Keybuk: I see. Would it be possible to translate that or can you define arbitrary data types? | 13:17 |
| Keybuk | and have that and the dbus-daemon on the local intercommunicate | 13:17 |
| Keybuk | of course, then you still hit the activation problem | 13:17 |
| Keybuk | if Rhythmbox on the remote machine makes a method call that would activate a service | 13:17 |
| Keybuk | on which machine do you activate the service? | 13:17 |
| Keybuk | soren: the D-Bus data types are a fixed part of the specification | 13:18 |
| soren | Keybuk: So it should totally be translatable by a proxy of some sort. | 13:18 |
| ogra | as Keybuk mentioned, thats not the main prob, the merging of the daemons is | 13:19 |
| ogra | and the priorization where to do what | 13:19 |
| Keybuk | for example, a client may activate a service and expect some non-dbus-bound communication as a result | 13:19 |
| Keybuk | the most trivial example being DeviceKit or HAL | 13:19 |
| ogra | right, thats the main focus of ltsp | 13:20 |
| Keybuk | if rhythmbox asks to mount something, it probably expects that mount to happen locally | 13:20 |
| pitti | 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 |
| Keybuk | ie. on the remote end | 13:20 |
| Keybuk | not on the server end | 13:20 |
| ogra | with network forwarding to the actual desktoip session so it can access it | 13:20 |
| Keybuk | 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 |
| ogra | no, the other way round | 13:20 |
| Keybuk | no | 13:20 |
| Keybuk | the way round *I* said | 13:21 |
| ogra | the HW is always on the client | 13:21 |
| Keybuk | remember that in the X architecture, the server is the machine the user is sitting on | 13:21 |
| Keybuk | and the client is the machine the application is running on | 13:21 |
| ogra | if i plug my ipod into the client i want a message to go to the server | 13:21 |
| Keybuk | you plug your ipod into the server ;) | 13:21 |
| ogra | and i want gvfs to initiate a network mount of the client HW to the desktop session | 13:21 |
| ogra | why would i go to the server room to do that ? | 13:22 |
| Keybuk | ogra: either you're being deliberately stupid, or deliberately confusing | 13:22 |
| Keybuk | please stop | 13:22 |
| ogra | oh, i missed your referral to X above ... thats not how we handle ltsp :) | 13:22 |
| Keybuk | X is the key component here | 13:23 |
| Keybuk | so we use its terminology | 13:23 |
| ogra | well ... if you use XDMCP which we dont | 13:23 |
| ogra | since ltsp5 exists | 13:23 |
| Keybuk | 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 |
| Keybuk | the Server is the machine that the user sits on | 13:23 |
| Keybuk | the Client is the machine that the application runs from | 13:23 |
| Keybuk | the Server has the X Server and the D-Bus Bus Daemon (ie. server) | 13:23 |
| Keybuk | the Client has the X Client (application) and the D-Bus Client | 13:24 |
| Keybuk | the user sits at the Server | 13:24 |
| Keybuk | the user plugs their iPod into the Server | 13:24 |
| Keybuk | which is the machine also running the HAL Daemon (ie. server), etc. | 13:24 |
| pitti | stgraber: unping; it was too obvious :) | 13:26 |
| ogra | 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:26 |
| Keybuk | exactly | 13:27 |
| ogra | we were largely saying the same, you just used ancient terminology :) | 13:27 |
| Keybuk | I use the *correct* terminology | 13:27 |
| Keybuk | 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 |
| Keybuk | the problem is that it's not as simple as tunnelling it at all! | 13:27 |
| calc | 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 |
| Keybuk | if a remote client needs filesystem access to something on the server, you need to have special multi-seat software broker that | 13:28 |
| Keybuk | (true for any device access, in fact - e.g. mtp) | 13:28 |
| calc | pitti: but i won't be uploading it again until i am certain it builds for me | 13:28 |
| pitti | calc: okay; we found a workaround for now, to make the alternates installable without -l10n | 13:28 |
| pitti | brb | 13:28 |
| calc | pitti: ok | 13:28 |
| Keybuk | much more fun ensues when you talk about power management <g> | 13:29 |
| ogra | well, and the tunnel wouldnt be any problem we have already various ssh tunnels established on ltsp | 13:29 |
| calc | pitti: apparently the install target was reworked between 3.0 and 3.1 and i managed to miss it somehow | 13:29 |
| Keybuk | if the client and server both have batteries | 13:29 |
| Keybuk | which battery should you show on the panel? | 13:29 |
| Keybuk | should it matter whether the battery applet is on the same machine as the server or the client? | 13:29 |
| calc | 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:29 | |
| ogra | well, i would show both, the prob here is how to distinguish them visually | 13:30 |
| ogra | 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:30 |
| Keybuk | but if the battery on one of them runs out | 13:31 |
| Keybuk | you need a policy that is multi-seat aware | 13:31 |
| Keybuk | it's all good fun :p | 13:31 |
| ogra | in case of batteries, both of them are equally important ... but batteries are definately not the typical HW :) | 13:31 |
| Keybuk | this is why the whole "D-Bus over SSH" problem has never been "solved" upstream | 13:31 |
| Keybuk | it's a much more difficult problem than it first appears | 13:31 |
| ogra | yeah | 13:31 |
| ogra | htough its not actually a dbus problem but rather the on top apps like hal/devkit | 13:32 |
| ogra | in case of a std. ltsp setup you can simply ignore the system daemon on one side | 13:33 |
| ogra | since all you want is diredct interaction with the thin client HW through the dbus connection | 13:34 |
| ogra | 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:35 |
| soren | 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 |
| Keybuk | but if the desktop session machine is shutdown, or power goes out, etc. you need the thin-client machines to be notified | 13:36 |
| soren | :) | 13:36 |
| ogra | yeah | 13:36 |
| Keybuk | 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 |
| ogra | but i can do that with mounting it under /mnt ... thats really a corner case | 13:37 |
| ogra | i agree about the power down though | 13:37 |
| Keybuk | to solve things properly, you never leave a corner case undusted | 13:37 |
| ogra | right, but it wouldnt be in my main focus ... rather something lower on the TO=DO | 13:38 |
| ogra | *TODO | 13:38 |
| ogra | indeed its convenient ... | 13:38 |
| ogra | but not a must have | 13:38 |
| ogra | though if you add polkit to the picture that really gets messy :) | 13:39 |
| ogra | and consolekit | 13:39 |
| hyperair | anyone here dealing with gnome-system-tools? | 13:56 |
| hyperair | bug #214720 | 13:56 |
| ubottu | Launchpad bug 214720 in nautilus-share "Cannot set LAN name without console" [Wishlist,Confirmed] https://launchpad.net/bugs/214720 | 13:56 |
| seb128 | hyperair: nautilus-share != gst | 14:06 |
| hyperair | seb128: yes i know. | 14:06 |
| hyperair | seb128: i'm about to reassign the bug to gst | 14:06 |
| seb128 | and "no" | 14:06 |
| seb128 | nobody is working on it either upstream or in ubuntu | 14:06 |
| hyperair | seb128: because simply put, nautilus-share is not meant to have any settings further than just configuring usershares | 14:06 |
| mercidia | hi, do you know where i could get help on app development using uinput driver? | 14:06 |
| hyperair | seb128: you mean gst is not being developed upstream or in ubuntu? | 14:07 |
| seb128 | indeed | 14:07 |
| seb128 | or rather nobody is working onit | 14:07 |
| seb128 | on it | 14:07 |
| hyperair | seb128: but the functionality is there, just hidden from view. | 14:07 |
| seb128 | it's a GNOME software still but without an active team working on it | 14:07 |
| hyperair | i see. | 14:10 |
| hyperair | it would be awesome if this could be made to integrate with samba's usershares though | 14:10 |
| === rickspencer3-afk is now known as rickspencer3 | ||
| Keybuk | ok, this is just the worlds most insane gcc syntax | 14:34 |
| Keybuk | do { | 14:34 |
| === asac_ is now known as asac | ||
| Keybuk | __label__ enomem; | 14:34 |
| Keybuk | /* code that might goto enomem */ | 14:34 |
| Keybuk | enomem: __attribute__ ((unused)); | 14:34 |
| Keybuk | } while (0); | 14:34 |
| pitti | Keybuk: suspend with KMS> wow! | 14:35 |
| pitti | I mean WOOOWW! | 14:35 |
| pitti | bryce: that's awesome | 14:35 |
| Keybuk | pitti: one of the WHOLE POINTS of KMS is that is makes the whole suspend/resume milarky easier, isn't it? :p | 14:36 |
| pitti | Keybuk: now I just want that working with my external monitor, too, isntead of staying black :) | 14:36 |
| lool | I guess usb-creator can't create USB images from alternate CDs, can it? | 14:38 |
| ion_ | keybuk: What's the purpose of that code? | 14:38 |
| cjwatson | lool: should be able to | 14:40 |
| lool | Cool, thanks | 14:43 |
| Keybuk | ion_: C99/GCC equivalent of "break from outer loop" | 14:47 |
| === azeem_ is now known as azeem | ||
| Keybuk | 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:55 |
| Keybuk | I found it odd that the attribute goes on the label itself, not the __label__ pre-declaration/localising | 14:56 |
| Keybuk | and that you need the ";" on the end of the label ;) | 14:56 |
| ion_ | :-) | 14:57 |
| cjwatson | 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 |
| cjwatson | or at any rate several releases ago | 14:57 |
| cjwatson | I remember tbm filing a bunch of bugs about it | 14:57 |
| Keybuk | yeah | 14:57 |
| Keybuk | though since that's the primary use of local labels, you'd've thought they wouldn't care about them | 14:57 |
| cjwatson | I assume the grammar says that label comes before a statement | 14:58 |
| Keybuk | though I guess it makes local-labels-combined-with-statement-expressions nice ;) | 14:58 |
| cjwatson | *my* primary use of local labels is: out: do_cleanup_work(); } | 14:58 |
| cjwatson | common idiom in the kernel too | 14:58 |
| Keybuk | ({ __label__ gotit; int ret; /* something complicated */ gotit: ret; }) | 14:58 |
| Keybuk | cjwatson: do you mean local labels, or just labels? | 14:58 |
| cjwatson | oh, what's a local label? | 14:59 |
| Keybuk | local labels are labels with block scope | 14:59 |
| cjwatson | block-local or what? | 14:59 |
| cjwatson | ah, didn't know about those, ok | 14:59 |
| Keybuk | things to fix if we ever got to drop backwards compatibility for C/POSIX/etc. | 15:11 |
| Keybuk | the fact that somebody couldn't spell "signalled" | 15:11 |
| ogra | cjwatson, since you expressed interest before ... bug 375991 is about the segfault | 15:22 |
| ubottu | Launchpad bug 375991 in binutils "ld segfaults building a kernel image on armel" [Undecided,New] https://launchpad.net/bugs/375991 | 15:22 |
| joaopinto | where can I find the latest definition for a debian control file format ? The debian policy manual documentation referes format 1.5, .changes files generated on jaunty use format 1.8 | 15:23 |
| directhex | yay, dell's new 10" laptop has ditched poulsbo | 15:23 |
| cjwatson | joaopinto: the .changes format is not the same as the control file format | 15:24 |
| cjwatson | joaopinto: the Debian policy manual (or I suppose here the Ubuntu policy manual, but there are no significant changes to the control file format in that) is authoritative | 15:25 |
| joaopinto | cjwatson, I am reading the .changes description, it links to http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Format for the Format field | 15:25 |
| joaopinto | the ubuntu policy manual mentions the same 1.5 version | 15:26 |
| cjwatson | policy probably shouldn't claim those are in sync; they aren't necessarily | 15:26 |
| cjwatson | .changes format 1.6 was roughly dawn-of-time (May 1999) and I'm not sure what it did; .changes 1.7 added Changed-By and adjusted Maintainer to be the actual maintainer rather than the changer; .changes 1.8 added SHA1 and SHA256 checksums | 15:27 |
| joaopinto | I am writing a class to work with debian control files, and I want to be sure it can be sone with a single generic class able to cope with .dsc and .changes | 15:28 |
| cjwatson | joaopinto: the syntax is the same; the semantics differ | 15:29 |
| cjwatson | you'll have to have variations on that class to cope with the different semantics *anyway* | 15:29 |
| cjwatson | you should probably just read dpkg-genchanges etc. | 15:29 |
| liw | "Sorry, there was a problem connecting to the Launchpad server." -- I keep getting this today, did I miss a Launchpad maint announcement? | 15:39 |
| Keybuk | it's been doing that for the past few weeks | 15:40 |
| Keybuk | I think they've reduced the timeout for page returns in an attempt to improve performance | 15:40 |
| liw | ok | 15:40 |
| Keybuk | (ie. if they reduce the timeout, then they get the errors so know what to fix) | 15:41 |
| jdong | wouldn't it be even more effective if they just served an ErrorDocument to everyone anyway? *ducks* | 15:41 |
| liw | they've certainly improved the time from "click" to "annoyed", but I'm willing to suffer that if they'll make it better in the end | 15:41 |
| jdong | well IMO "reducing the timeout and resorting to error" still doesn't sound like a necessary solution to the problem. | 15:41 |
| ogra | jdong, and use the DB servers as backporter machines instead ? | 15:41 |
| jdong | surely they can time render response and quietly generate alerts without messing with the userbase, right? | 15:42 |
| Keybuk | jdong: it only effects edge | 15:42 |
| jdong | ah | 15:42 |
| liw | I'm not using edge | 15:42 |
| Keybuk | oh | 15:42 |
| Keybuk | maybe it doesn't then ;) | 15:42 |
| jdong | :) | 15:42 |
| seb128 | the performance thing is only edge I think | 15:44 |
| apw | i think there is a general bug with some of the backends, does the page work when you reload each time? | 15:44 |
| seb128 | other issues should be signaled on #launchpad so they can look at the bug | 15:44 |
| jdong | it seems to work for me after 1-2 reloads. | 15:45 |
| liw | apw, reload's worked every time I've tried, but it's only been a handful of times today | 15:45 |
| apw | worth mentioning on #luaunchpads, but if it oops the first time, and works the second it is likely the ongoing 'backend broke' bug which is still being chased | 15:45 |
| jdong | alright, I'll holler the next time I come across it again | 15:47 |
| jelmer | liw: hi | 15:47 |
| jelmer | liw: are you by any chance aware of HTML-pretty printers for python coverage output? | 15:47 |
| liw | jelmer, greetings and salutations! | 15:47 |
| liw | jelmer, I have never even heard of them; I mainly use coverage.py via python-coverage-test-runner which calls me names if my test suite is not 100% | 15:48 |
| liw | (well, 100% minus the parts I've explicitly marked outside coverage testing) | 15:48 |
| tjaalton | ogra: hey, where did you get the evtouch 0.8.8 tarball? upstream homepage doesn't have it | 15:48 |
| ogra | it should | 15:49 |
| jelmer | liw: ah, I probably should give that a try too :-) | 15:49 |
| tjaalton | ogra: oh right, wrong page | 15:49 |
| jelmer | liw: Thanks, I'll keep looking | 15:49 |
| ogra | tjaalton, yeah al always fall into that trap too :) | 15:50 |
| ogra | s/al/i/ | 15:50 |
| liw | jelmer, have you tried the -r and -m options to coverage.py (or python-coverage)? depending on what you want to do | 15:50 |
| tjaalton | ogra: it'll probably be corrected now :) | 15:50 |
| ogra | tjaalton, hopefully :) btw Bug 317094 has quite a lot of data now ... we'll need to get that in ;) | 15:52 |
| ubottu | Launchpad bug 317094 in xf86-input-evtouch "evtouch meta bug to collect lshal info" [Undecided,Confirmed] https://launchpad.net/bugs/317094 | 15:52 |
| tjaalton | ogra: also, I noticed that evdev failing to calibrate was a bug | 15:53 |
| === beuno_ is now known as beuno | ||
| ogra | tjaalton, we'll have a session about it again at uds ... tseliot is working on something wrt xinput and we should merge efforts | 15:54 |
| tjaalton | ogra: ok, good | 15:54 |
| jelmer | liw: yep | 15:54 |
| tseliot | ogra, tjaalton: yes, and it's almost complete, at least as regards touchpads | 15:54 |
| jelmer | liw: for Samba we currently generate HTML reports for our C and Perl code coverage in our buildfarm, I'd like to do the same for Python which is why I'm looking for HTML specifically | 15:55 |
| ogra | right, touchscreens are a bit different, but we should be able to share the backend server | 15:55 |
| Keybuk | depends on the touchscreen, of course | 15:58 |
| Keybuk | some show up as wacom tablets ;) | 15:58 |
| ogra | thats not qa touchscreen then :) | 15:58 |
| Keybuk | qa? | 15:58 |
| ogra | since it needs an additional device | 15:58 |
| ogra | s/qa/a/ | 15:58 |
| Keybuk | it is a touchscreen though | 15:59 |
| ogra | you can tap it with your finger ? | 15:59 |
| Keybuk | it's just a dual-mode one | 15:59 |
| ogra | ah | 15:59 |
| Keybuk | yes, in Windows at least anyway - Linux you can only use the stylus | 15:59 |
| ogra | yeah, thats a bad one | 15:59 |
| ogra | but i guess it has two /dev/input/event files you could use | 16:00 |
| Keybuk | not sure | 16:00 |
| ogra | so you could attach two different drivers and make both modes work | 16:00 |
| ogra | just getting calibration consistent might be painful :) | 16:00 |
| Keybuk | I appear to have foolishly overwritten the USB key with the only filesystem this can boot from | 16:01 |
| ogra | well, bring it next week and we can take a look :) | 16:01 |
| Keybuk | :-) | 16:02 |
| Keybuk | that's the hardest part about Allhands/UDS | 16:02 |
| Keybuk | deciding which hardware to pack | 16:02 |
| tjaalton | ogra: so, looking at the bug it seems that the kernel lists wrong capabilities, so either it should be fixed in the kernel or by a udev quirk? | 16:02 |
| tjaalton | I see input.touchpad/input.mouse for the models listed on that bug | 16:03 |
| ogra | Keybuk, come by train or car ;) | 16:03 |
| ogra | tjaalton, yes and the current driver changes that with the .fdi file | 16:03 |
| ogra | tjaalton, the thing is that many of the evtouch devices dont have any special kernel drivers ... they are just USB HID devices, not sure you can generally apply patches on a kernel level for them ... | 16:05 |
| ogra | i surely know usbtouchscrees fails for 90% | 16:05 |
| ogra | *usbtouchscreen | 16:05 |
| tjaalton | it just _seems_ systematic | 16:05 |
| tjaalton | ie. like a bug | 16:05 |
| ogra | depends :) ... we should make sure to have some kernel guys in the room at UDS :) | 16:06 |
| Keybuk | ogra: I thought the kernel ev layer had quirks | 16:06 |
| ogra | but that requires the HW to tell it the right thing, no ? | 16:07 |
| Keybuk | indeed, drivers/input/touchscreen is *full* of quirks | 16:07 |
| tjaalton | so that's the place to hide them ;) | 16:07 |
| Keybuk | ogra: if the hardware lies, how do you quirk it in userspace? | 16:07 |
| Keybuk | it's no harder to quirk in the kernel than in userspace, in fact, it's often easier since the kernel already has tables of them | 16:08 |
| ogra | Keybuk, currently through an .fdi file | 16:08 |
| Keybuk | ogra: what does the fdi match on? | 16:08 |
| ogra | name model etc | 16:08 |
| ogra | i'd like to overcome the whole tabel thing if possible though | 16:09 |
| ogra | *table | 16:09 |
| Keybuk | there you go then | 16:09 |
| Keybuk | the kernel can quirk that | 16:09 |
| === cjwatson_ is now known as cjwatson | ||
| JordiGH | I was under the impression that for making a package for Ubuntu, making the package for Debian would suffice. Is there a case when Ubuntu doesn't just automatically grab Debian packages? | 16:22 |
| ogra | only some corner cases | 16:23 |
| JordiGH | Like what? This is for a family of packages (Octave) currently in Ubuntu's universe. | 16:23 |
| JordiGH | (iirc) | 16:23 |
| directhex | assuming there's no release freeze? | 16:23 |
| ScottK | JordiGH: We do have those generally. | 16:24 |
| JordiGH | directhex: Yeah, assuming the package will eventually trickle down into Ubuntu. I don't care if Debian gets the package first in its unstable branch. | 16:24 |
| ogra | JordiGH, ltsp for example uses the same upstream but different packaging | 16:24 |
| ogra | so we dont sync that but collaborate on the upstream code across the distros | 16:24 |
| directhex | JordiGH, the typical block is "package has been modified in ubuntu" which requires manual intervention | 16:25 |
| JordiGH | directhex: So I should be cool with packages currently in Universe, right? That's untainted Debian? | 16:25 |
| directhex | JordiGH, which seems to be the case here | 16:25 |
| JordiGH | Okay, good. | 16:25 |
| directhex | JordiGH, check the changelog for the package in universe, which has been modified in some way - if none of the changes are relevant any more, file a sync request, and it'll be pulled in "untainted" as you say | 16:26 |
| JordiGH | Uhm, "unmodified". I don't *really* want to say that Ubuntu "taints" packages. ;-) | 16:26 |
| directhex | looks like 2 patches, suitesparse_3.2.0_fix.dpatch and 51_fix_desktop_entry.dpatch | 16:27 |
| directhex | as per http://changelogs.ubuntu.com/changelogs/pool/universe/o/octave3.0/octave3.0_3.0.1-6ubuntu2/changelog | 16:27 |
| JordiGH | Yeah, this is for a new package for Octave. | 16:29 |
| JordiGH | I wonder if those patches have been pushed back to Debian... | 16:29 |
| cjwatson | Larhzu: squashfs, yes | 16:30 |
| cjwatson | (from #ubuntu-meeting:) | 16:30 |
| cjwatson | 16:29 <Larhzu> liw mentioned something about compressing live-CD with LZMA and keeping small changes rsyncable. Is the live-CD compressed with Squashfs or are there normal compressed .deb files or what? | 16:30 |
| cjwatson | Larhzu: well, mostly squashfs; there are some .debs on there too, but it's the squashfs component that gets independently compressed | 16:30 |
| directhex | if not, then in the general case, administer spankings - however, sometimes there are policy differences which force some patches between distros. sometimes it's possible to convince a DD to include ubuntuisms directly in the debian debian/rules file | 16:31 |
| cjwatson | Larhzu: however, that's only right now | 16:31 |
| cjwatson | Larhzu: one of the reasons we're looking at lzma for this is that the squashfs/unionfs approach is problematic right now | 16:31 |
| Larhzu | cjwatson: Squashfs compresses data in blocks of 64 KiB to 1 MiB. I don't know much more about Squashfs myself. For rsyncability, you want to make sure that unchanged data gets put into same blocks. It's mostly a Squashfs issue, not LZMA or XZ. | 16:31 |
| cjwatson | Larhzu: unionfs and aufs are both looking pretty shaky upstream and it's rather difficult to get them working with a current kernel | 16:31 |
| cjwatson | Larhzu: so we're looking at Fedora's approach, which involves device-mapper and so the source read-only filesystem has to be a more normal filesystem, e.g. ext3 | 16:32 |
| cjwatson | (sorry, I should probably have just said that up-front rather than being confusing about squashfs) | 16:32 |
| cjwatson | Larhzu: we tried lzmaing an ext3 filesystem with a tiny change (small change to /etc/issue or something) and rsync reckoned that the resulting compressed image had absolutely nothing in common with the original | 16:33 |
| Larhzu | cjwatson: How do you use LZMA with ext3? Compress the whole file system image at once? | 16:33 |
| liw | cjwatson, so if I understand correctly: we are looking at completely dropping squashfs and replacing that with an ext3 image that gets lzma compressed? | 16:33 |
| cjwatson | Larhzu: yes | 16:33 |
| cjwatson | liw: it's one of the possibilities | 16:33 |
| cjwatson | I'm actually looking at something different right now since it isn't looking terribly viable | 16:34 |
| cjwatson | but you asked :-) | 16:34 |
| Larhzu | Do you plan to uncompress the whole image to RAM before using it, or uncompressing on the fly when stuff is needed from it? | 16:34 |
| cjwatson | Larhzu: TBH I'm not sure :-) this was just an experimental thing | 16:35 |
| cjwatson | none of this is near the "do you plan" status | 16:35 |
| ogra | phew ... | 16:35 |
| cjwatson | it's "we're playing around with stuff to figure out what could replace squashfs/aufs" | 16:35 |
| ogra | but squashfs is upstream now, no ? | 16:35 |
| ogra | is there any reason to move away from it ? | 16:36 |
| cjwatson | ogra: unionfs/aufs aren't | 16:36 |
| cjwatson | that's the problem | 16:36 |
| cjwatson | squashfs being upstream is great | 16:37 |
| ogra | right, but you only look into replacing the union parts for now ... | 16:37 |
| ogra | ? | 16:37 |
| cjwatson | yes | 16:37 |
| Larhzu | If you make a 500 MiB compressed ext3 image which has to be uncompressed to RAM first, you need many gigabytes of RAM and booting will take 15 minutes. | 16:37 |
| ogra | good | 16:37 |
| cjwatson | hmm, I wonder if I have been maligning clicfs | 16:37 |
| cjwatson | it seems to split the image into blocks and lzma each block separately | 16:38 |
| Larhzu | That's what Squashfs does. | 16:38 |
| cjwatson | Larhzu: ^- would that approach be likely to be rsyncable, then? | 16:38 |
| cjwatson | (as a guess, I'm not holding you to it ...) | 16:38 |
| Larhzu | It's a Squashfs issue, you need to make sure that when recreating a Squashfs image, non-changed parts get into same compressed blocks. | 16:38 |
| cjwatson | we don't have this issue with squashfs | 16:39 |
| cjwatson | indeed, what we're trying to avoid is a *regression* from our current squashfs setup | 16:39 |
| Larhzu | Oh sorry | 16:39 |
| cjwatson | sorry, I was very confusing in my description above | 16:39 |
| Larhzu | So ext3 splitted in small pieces, each piece compressed separately, then make the uncompressed image available to ext3 driver via device mapper decompressor or something? | 16:39 |
| Larhzu | I'm still quite unsure if I'm following at all. | 16:41 |
| cjwatson | so, right now, we have squashfs+aufs, and this is all lovely and rsyncable, although perhaps not as small as it could be (though small enough) | 16:41 |
| cjwatson | aufs is having serious problems getting accepted upstream, and there's nothing available for 2.6.30 that we know of, so we're forced to look into alternatives | 16:42 |
| cjwatson | one possible alternative is something along the lines of the approach taken by Fedora: make an ext3 filesystem, compress it *somehow* (I'd assume block-by-block), and layer a writable piece on top of that using device-mapper | 16:43 |
| Larhzu | Does the device mapper hack make it writable too by keeping changed blocks in RAM or storing them to hard disk? | 16:44 |
| cjwatson | now, we actually used to do something like this with cloop, but found that it tended not to be all that rsyncable, and this was a major problem for our developers; we managed to make it somewhat rsyncable by keeping the old uncompressed directory around from build to build but this was very inconvenient | 16:44 |
| cjwatson | RAM | 16:44 |
| cjwatson | or USB stick if you're booting from that | 16:44 |
| cjwatson | at least, I think that's how we'd do it in Ubuntu; I don't know the specifics of the Fedora approach | 16:44 |
| Larhzu | With my minimal understanding about file systems, Squashfs + something make it writable sounds much better, since Squashfs will very probably handle the decompression better (at least faster). | 16:46 |
| cjwatson | OK. Our problem right now is that most of the candidates for "something" just evaporated. That's not your problem though, I suppose :-) | 16:47 |
| Larhzu | If you modify an ext3 image, there will probably be changed blocks in many places. With Squashfs, that's probably not so big problem. | 16:47 |
| cjwatson | Hmm, right. | 16:47 |
| cjwatson | I'm looking into unionfs-fuse at the moment, which shows some promise of being a candidate for "something", although writing may end up being rather slow due to having to bounce through userspace | 16:48 |
| ogra | cjwatson, dod you know that nbd has a COW mode ? | 16:48 |
| Larhzu | Making such an ext3 image rsyncable would probably give bigger size than Squashfs. | 16:48 |
| ogra | *did | 16:48 |
| cjwatson | ogra: no - that's block-level though, isn't it? | 16:48 |
| ogra | i know the debian ltsp guys played with it | 16:48 |
| ogra | using a squashfs image | 16:48 |
| cjwatson | Larhzu: thanks, that's very useful information | 16:48 |
| ogra | no idea, i havend dug deep into it | 16:48 |
| ogra | i just know it works and i used loopback nbd setups before ... its not beautiful but works | 16:49 |
| Keybuk | cjwatson: except we can't use squashfs | 16:49 |
| cjwatson | right, nbd is block-level | 16:50 |
| cjwatson | ogra: the problem with anything block-level is that it means that the target device has to be the same filesystem type as the source device | 16:50 |
| Larhzu | cjwatson: I have written XZ Embedded for Linux, which is XZ decompressor with LZMA2 and BCJ filters. That should be useful for Squashfs, so there could be LZMA-based (more correctly, XZ and its LZMA2 -based) Squashfs in vanilla Linux some day. I haven't posted about it to LKML yet, but there was some minimal discussion on linux-embedded. | 16:50 |
| ogra | cjwatson, hmm, i know they used ext3 rw images alongside squashfs ro images | 16:51 |
| cjwatson | ogra: interesting - google finds no reference to it and the documentation isn't exactly clear, but if you can dig up something concrete I'd be interested in looking at it | 16:51 |
| ogra | but indeed its ugly and you need a running loopback device at least for it | 16:52 |
| cjwatson | Larhzu: if we find a workable union implementation, we might well end up using that once it gets into mainline and assuming that it's reasonably rsyncable | 16:52 |
| Larhzu | cjwatson: About making compressed ext3 image rsyncable, there's one easy way, which is possible because the image size is fixed: Just compress the data in blocks of a few megabytes. That way most blocks won't change. | 16:52 |
| cjwatson | mainlininess has been one of the traditional blockers there - our kernel team would far prefer to avoid out-of-tree drivers where they can (and aufs has been a headache for them) | 16:52 |
| Larhzu | cjwatson: It's Squashfs whose rsyncability matters with Squashfs + something. And I understood you didn't have rsyncability issues with Squashfs. | 16:53 |
| Keybuk | Larhzu: how do you specify the block size to lzma? | 16:53 |
| * vagrantc waves to ogra | 16:53 | |
| ogra | cjwatson, vagrantc played with nbd COW on debian ltsp | 16:53 |
| cjwatson | Larhzu: ok, I think we'd need to experiment to find out whether that would work well in an environment where the source filesystem is built from scratch on every build :-) | 16:53 |
| Larhzu | Keybuk: Current you don't. There will be such option in xz (the command line tool from XZ Utils), it's needed for multithreading. I haven't implemented it yet. | 16:54 |
| ogra | vagrantc, we are looking for a poissibility to replace aufs/unionfs in ubuntu with a COW method | 16:54 |
| cjwatson | I think one problem we had is that things like packages being unpacked in different orders resulted in stuff moving around a lot on the filesystem - essentially spuriously but it broke rsyncability | 16:54 |
| cjwatson | mksquashfs has a -sort option that lets us avoid that class of problem | 16:55 |
| ogra | vagrantc, and i remembered you played with that possibility on ltsp ... you did use a squashfs with ext3 writable bits, right ? | 16:55 |
| vagrantc | ogra: NBD's cow support? or something else? | 16:55 |
| vagrantc | ogra: i've used all manner of combinations :) | 16:55 |
| sabdfl | hi folks, is there a coontact address for SRU discussions? have a question in my inbox from sebastian hilbert re gnumed | 16:55 |
| ogra | vagrantc, well, cjwatson looks into unionfs via fuse ... i just remembered you did something through nbd | 16:55 |
| vagrantc | ogra: i've used ext2/ext3 with aufs | 16:56 |
| vagrantc | ogra: no squashfs at all | 16:56 |
| ogra | what did you use for your readonly nbd images ? | 16:56 |
| vagrantc | ogra: ext[23] | 16:56 |
| ogra | oh, ok | 16:56 |
| ogra | then i was likely misremembering | 16:57 |
| vagrantc | ogra: i also looked at using server-side cow files, but there's a few bugs that prevented it from working | 16:57 |
| ogra | i thought it was squashfs with a writable ext2/3 alongside | 16:57 |
| cjwatson | sabdfl: it's very sparsely used but we do have an ubuntu-release list - perhaps send it there, but realistically it might be a good idea to CC the individual members of the ubuntu-sru team since I'm not sure how everyone's mail filters handle that list | 16:57 |
| ogra | sabdfl, does https://wiki.ubuntu.com/StableReleaseUpdates help you ? | 16:57 |
| vagrantc | ogra: as NBD supports cow files, but it isn't flexible about where it writes the temporary cow files. | 16:58 |
| ogra | right, but thats could be fixed/patched | 16:58 |
| cjwatson | sabdfl: normally we're working with bug reports (as the wiki page ogra cites discusses) and in that case it's easy just to subscribe the ubuntu-sru team | 16:58 |
| vagrantc | ogra: sure. i reported bugs in the debian BTS | 16:58 |
| sabdfl | ok, i'll advise sebastian accordingly | 16:59 |
| sabdfl | thanks! | 16:59 |
| cjwatson | sabdfl: actually, gnumed's probably in universe - so the motu-sru team should be subscribed instead | 16:59 |
| cjwatson | sorry, forgot about that | 16:59 |
| ogra | vagrantc, we're looking actively for something to replace aufs/unionfs on the livecds ... | 16:59 |
| sabdfl | looking forward to UDS (and AllHands beforehand after somehands ;-)) | 16:59 |
| cjwatson | handhands | 16:59 |
| vagrantc | ogra: ah, then NBD support wouldn't help much. | 16:59 |
| cjwatson | wavehands | 16:59 |
| ogra | sabdfl, dont forget to wash your hands between them :) | 16:59 |
| ogra | vagrantc, yeah, if it cant do squash alongside with tmpfs it wouldnt ... i thought about a local loopback nbd setup | 17:00 |
| ogra | with enabled COW in tmpfs | 17:00 |
| cjwatson | nbd would have to operate at the filesystem layer in order to make that work | 17:00 |
| ogra | yes | 17:00 |
| cjwatson | but it operates at the block layer, as far as I know | 17:01 |
| cjwatson | kind of a big change :-) | 17:01 |
| ogra | well, apparently i misremembered what vagrantc was doing | 17:01 |
| vagrantc | ogra: the main NBD bug that's a blocker for LTSP using NBD's built-in cow support is: http://bugs.debian.org/470963 | 17:01 |
| ogra | vagrantc, seems trivial | 17:02 |
| Larhzu | cjwatson: I hope things become a little bit clearer now. Like I wrote in the forum post, there probably will be rsyncability option in xz some day, but it won't be there soon. I cannot promise to add block-size option very soon either; my primary worry with this subject is to get XZ Utils 5.0.0 finally out. | 17:02 |
| vagrantc | ogra: but it would be bizzarre to use on a CD :) | 17:02 |
| ogra | vagrantc, yeah, that was what i said initially :) but it could work around the problem | 17:03 |
| Keybuk | Larhzu: what's the difference between XZ and LZMA? | 17:03 |
| Larhzu | cjwatson: If there's something else, just ask. I'll idle here a few hours. Later just PM or visit #tukaani. | 17:03 |
| ogra | vagrantc, i used nbd loopback before, its very convenient if you want userspace loop mounting of image files ... you can run nbd-server as a user and dont need access to /dev/loopX | 17:03 |
| Larhzu | Keybuk: The .lzma format is becoming legacy, same with LZMA Utils. XZ Utils and .xz format support LZMA2 (fixes some issues of LZMA, practically no compression ratio changes) and other algorithms (filters). .xz also has proper magic bytes and integrity checks which .lzma lacks. | 17:04 |
| ogra | vagrantc, thanks for coming over though ... | 17:05 |
| Larhzu | Keybuk: .xz also has an index of independently compressed blocks, which makes it possible to do limited random access reading. | 17:05 |
| cjwatson | Larhzu: right, thanks a lot for your clarifications; I don't think there's any rush from the lzma point of view, as we're likely to need at least a stopgap measure that exists today, so we'll keep researching | 17:06 |
| ogra | vagrantc, if we really dont find a pretty alternative in ubuntu i might invest some hours into fixing the nbd side for ltsp | 17:06 |
| Larhzu | Keybuk: The .lzma format was meant to be replaced in 2006 already, but things progressed very slowly. | 17:06 |
| vagrantc | ogra: using a writeable filesystem (ext3) for the nbd.img file means you can mount the loopback image and tweak the chroot just like in the "good" old days of NFS. :) | 17:08 |
| vagrantc | ogra: i didn't notice a significant speed improvement using nbd + squashfs vs. nbd + ext[23] | 17:09 |
| ogra | vagrantc, yeah, and we could finally get back to doing the same thing on both distros :) | 17:09 |
| vagrantc | heh. | 17:09 |
| ogra | no, the speed improvement is NFS vs nbd+squashfs | 17:10 |
| vagrantc | ogra: debian's got support for all the various incarnations. | 17:10 |
| ogra | and i dont think the squashfs ever played a significant role | 17:10 |
| vagrantc | ogra: right, but you pretty much get the same speed improvement by using NBD + *fs | 17:10 |
| ogra | right | 17:10 |
| ogra | its the nfs overhead that slows down | 17:11 |
| ion_ | ogra: Would any of this be helpful for LTSP? http://kernelnewbies.org/Linux_2_6_30#head-d2d7e82afe6019227c8d6f661608550a2ca917f1 | 17:13 |
| ogra | ion_, well, we would have used iscsi if it would have looked sane :) but indeed its a possibility | 17:15 |
| ion_ | I meant POHMELFS | 17:15 |
| ion_ | I didn't really take a good look at it, just noticed the phrase “beats NFS by a big margin in most, if not all, operations” | 17:16 |
| ogra | that sound intresting but would have to prove it works on low power HW | 17:16 |
| ogra | "...with a local writeback cache of data and metadata, which greatly speeds up every IO operation..." | 17:16 |
| ogra | that sounds ram hungry to me | 17:16 |
| ion_ | True | 17:16 |
| ogra | but would be worth a test for sure if someone finds the time to do an initramfs hook for ltsp | 17:17 |
| kees | Keybuk: what are you saying in the whiteboard status for security-karmic-apport-abort ? will apport actually run sanely if upstart aborts? | 17:28 |
| Keybuk | kees: well, I think right now, apport doesn't run at all | 17:34 |
| Keybuk | from what Martin was saying | 17:34 |
| kees | Keybuk: well, I meant from a technical perspective. can apport execute if pid 1 has died? | 17:36 |
| Keybuk | pid 1 doesn't die | 17:36 |
| Keybuk | but it does generate a core file | 17:36 |
| kees | Keybuk: apport ignores ABRT, but this would seek to change that in the case of assert() failures | 17:37 |
| kees | okay, if the kernel attempts to launch apport, then it should work okay | 17:37 |
| Keybuk | kees: right, thus my "figlet ++" | 17:37 |
| Keybuk | if apport could catch SIGABRT and file bugs - that would be a big win for me | 17:37 |
| * apw wonders if there are any main-sponsors about to look at a hibernate related upload on bug #350491, avoids potential corruption due to failed hibernate resume on kernel update | 17:37 | |
| ubottu | Launchpad bug 350491 in linux "hibernation should be disallowed from the desktop when the installed kernel does not match the running kernel" [High,In progress] https://launchpad.net/bugs/350491 | 17:37 |
| kees | Keybuk: yeah, though there are a lot of gotchas, though, which is why I scheduled the UDS thingy | 17:38 |
| kees | Keybuk: can you come to that discussion if you're not already sub'd to it? | 17:38 |
| Keybuk | kees: I didn't think the discussion was even scheduled | 17:38 |
| Keybuk | no, it is, I just can't find it ;) | 17:39 |
| kees | heh | 17:39 |
| * kees hopes pitti doesn't mind me making him a drafter on it. :) | 17:39 | |
| rickspencer3 | lol | 17:40 |
| Keybuk | kees: actually, it would be an interesting experiment to see how the kernel deals with apport | 17:42 |
| Keybuk | whether it lets apport continue before doing the PANIC or not | 17:42 |
| kees | Keybuk: right, that was what I was curious about. | 17:44 |
| Keybuk | I have a note that I thought the kernel ran apport as part of the process of dumping core | 17:44 |
| Keybuk | so the parent didn't get to wait() on the child until apport had done | 17:44 |
| Keybuk | since it needs to know for WCOREDUMP() | 17:44 |
| Keybuk | but I should check that | 17:45 |
| Keybuk | kees -> the abort() handler discussion conflicts with the upstart tutorial :-( | 17:46 |
| kees | Keybuk: just subscribe yourself and re-shuffle! | 17:47 |
| Keybuk | I'm not touching the schedule ;) | 17:47 |
| kees | dang it | 17:47 |
| kees | ah well | 17:47 |
| Keybuk | dendrobates will have to reorganise <g> | 17:47 |
| dendrobates | AAAAAAAHHHHHHHHHHHHHHHHHHHH | 17:47 |
| pitti | Keybuk: drafter on what? | 17:48 |
| rtg | doko: do you think the ARM binutils fix will help the kernel FTBS https://edge.launchpad.net/ubuntu/+source/linux/2.6.30-5.6/+build/998876/+files/buildlog_ubuntu-karmic-armel.linux_2.6.30-5.6_FAILEDTOBUILD.txt.gz ? | 17:48 |
| dendrobates | I sugest dividing Keybuk into two idenically sized pieces. | 17:48 |
| ogra | rtg, yes | 17:48 |
| rtg | ok, I'll restart it | 17:48 |
| doko | rtg: yes | 17:48 |
| doko | rtg: it's not yet built | 17:49 |
| Keybuk | dendrobates, pitti, kees: I don't _really_ need to be there - other than to say I'd like apport to catch Upstart's abort() calls ;) | 17:49 |
| rtg | doko: oh, I might have jumped the gun | 17:49 |
| rtg | though, it should be behine binutils in the build queue (I hope) | 17:50 |
| doko | rtg: just set the score to 1 for now | 17:51 |
| rtg | doko: hmm, easier said then done. | 17:52 |
| cjwatson | rtg: retries are automatically set to 0 | 17:53 |
| cjwatson | of course that doesn't guarantee that a publisher run will happen between binutils building and linux building | 17:53 |
| rtg | as long as the armel build takes, I'm sure an hour will elapse between | 17:53 |
| cjwatson | maybe | 17:54 |
| kees | pitti: security-karmic-apport-abort blueprint | 17:54 |
| kees | Keybuk: okay cool | 17:55 |
| kees | pitti: now, with URL: https://blueprints.edge.launchpad.net/ubuntu/+spec/security-karmic-apport-abort | 17:55 |
| pitti | kees: ah, that sounds fine | 17:56 |
| kees | cool | 17:56 |
| doko | rtg: rescored to 1. needs the rescore once binutils is in the archive | 17:57 |
| rtg | doko: thanks | 17:58 |
| Keybuk | kees: it *looks* like the kernel waits for apport to finish ;) | 18:01 |
| kees | neato | 18:03 |
| kees | Keybuk: how do you call abort currently? via assert() or only as abort()? | 18:04 |
| kees | Keybuk: the primary trouble with handling abort() is that there is no one place that applications report errors before calling abort(), excepting through assert() and the internal *_chk() aborts. | 18:04 |
| pitti | bryce: I added a snippet about UXA/KMS testing to https://wiki.ubuntu.com/KarmicKoala/TechnicalOverview; would you mind proofreading? | 18:15 |
| pitti | bryce: also, https://wiki.ubuntu.com/X/KernelModeSetting still mentions the xorg-edgers PPA for karmic; I'll delete that, since 2.7.0 is in karmic proper | 18:16 |
| bryce | ok | 18:16 |
| pitti | bryce: or would you rather not have these mentioned in the tech notes? | 18:17 |
| bryce | wow, people are amazingly ungrateful on that X freeze bug | 18:17 |
| d1b | bryce: it is their gui | 18:17 |
| bryce | pitti: it's fine to mention x-updates on the technical overview | 18:17 |
| pitti | bryce: isn't x-updates for jaunty? | 18:17 |
| pitti | bryce: I mean the karmic alpha-1 release notes (call for testing) | 18:18 |
| bryce | pitti: oh karmic | 18:18 |
| pitti | bryce: ungrateful> yes, only to freak out in joy when testing 2.7.1 :) | 18:18 |
| d1b | pitti: is it that much better / fixed? | 18:19 |
| bryce | pitti: yes this text looks good | 18:19 |
| pitti | d1b: I can only parrot what they said in the bug report; karmic has 2.7.0 still, running that | 18:19 |
| pitti | I have a number of problems with it (glitches and suspend), looking forward to trying 2.7.1 | 18:20 |
| d1b | pitti: intel on ubuntu .. since 8.04 has had problems on my laptop :( | 18:20 |
| d1b | what about fglrx in jaunty... is that getting fixed soon... | 18:21 |
| pitti | bryce: what's driving me crazy is that people keep posting UXA and other unrelated feedback to it | 18:21 |
| Keybuk | kees: only as abort() | 18:21 |
| Keybuk | #define nih_assert(expr) \ | 18:22 |
| Keybuk | if (! NIH_LIKELY(expr)) { \ | 18:22 |
| Keybuk | nih_fatal ("%s:%d: Assertion failed in %s: %s", \ | 18:22 |
| Keybuk | __FILE__, __LINE__, __FUNCTION__, #expr); \ | 18:22 |
| Keybuk | abort (); \ | 18:22 |
| Keybuk | } | 18:22 |
| kees | Keybuk: ah, but you call nih_fatal() first. what does that do? | 18:22 |
| kees | Keybuk: a lot of applications will do stuff like fprintf(stderr,"Zomg: pwnd\n"); abort(); | 18:23 |
| bryce | pitti: yeah I know | 18:23 |
| kees | Keybuk: so we'd be toying with ways to capture that stderr line. | 18:23 |
| Keybuk | kees: logs to kmsg | 18:24 |
| Keybuk | (ie. it ends up in dmesg) | 18:24 |
| bryce | pitti: ok so I count 1 comment on bug 359392 that indicates it fixes problems, and 5 that complain but don't seem to have tested | 18:24 |
| ubottu | Launchpad bug 359392 in compiz "[i965] X freezes starting on April 3rd" [Undecided,In progress] https://launchpad.net/bugs/359392 | 18:24 |
| pitti | bryce: from what I saw, there seem to be people with the proposed packages who still experience freezes, and some for whom it works | 18:26 |
| pitti | I think by and large it greatly reduces the freezes | 18:26 |
| pitti | so the -intel part isn't any worse than the jaunty final one | 18:26 |
| kees | Keybuk: I wish there was an "abort with message" function. closest seems to be assert()... which isn't really. bleh. | 18:35 |
| kees | Keybuk: but still, catching abort() would be nice. | 18:35 |
| bryce | pitti: sometimes I wish there was a minimum karma requirement before you can comment onto someone's bug other than your own | 18:35 |
| bryce | pitti: I think that would help cut down on the drive-by-ranting ;-) | 18:35 |
| pitti | heh, yes | 18:35 |
| pitti | bryce: and rants would decrease your karma | 18:36 |
| bryce | I got excited when I saw launchpadlib added a "hide comment" feature, but then I found it is only available to launchpad admins | 18:36 |
| mrooney | oh yeah, if you could vote up or down comments and the points there affected that users karma, haha | 18:36 |
| ogra | become one ! | 18:37 |
| d1b | bryce: well the admins have to have something to make the site useable ^^ | 18:40 |
| bryce | d1b: are you a launchpad admin? | 18:40 |
| d1b | veloc1tybrno way. | 18:41 |
| d1b | bryce: no way * | 18:41 |
| d1b | i just have a hate of the launchpad interface | 18:41 |
| geiseri | cjwatson: ping? | 18:41 |
| bryce | d1b: ah so you were just ranting, gotcha | 18:41 |
| mneptok | d1b: well, with such insightful and productive input as yours, i see no reason it should not improve. | 18:42 |
| d1b | bryce: yes, well i prefer drawing attention to it. + there are things they can fix easily + they are working on it i know | 18:42 |
| d1b | mneptok: yes i know. i have some helpful comments / filed bugs already thank you. | 18:43 |
| bryce | first, I think this is the wrong channel to draw attention to it | 18:43 |
| geiseri | cjwatson: i have a problem (someday i will just say hi and ask how your day was), i added an extra component to my install CD with extra packages. The component is called custom, but i keep seeing the following error: "Invalid Release file: no entry for custom/binary-i386/Packages" but i see the file there. | 18:43 |
| bryce | second, I know sometimes people think that voicing complaints about something will motivate people to work to fixing it, but actually the reverse can often be the case. | 18:43 |
| geiseri | cjwatson: and from what i can tell the md5sums match from the Release file and the actual packages file. | 18:43 |
| bryce | anyway, nuff said | 18:43 |
| ogra | .oO( third: ranting at someone about something unrelated who just complained about unrelated rants on his bugs will surely help ) | 18:45 |
| ogra | :P | 18:45 |
| mneptok | OGRA SUX PLZ FIX KTHXBAI | 18:48 |
| ogra | YEAH, ALL YOU SLACKERS ! | 18:48 |
| ogra | :) | 18:48 |
| === CarlFK2 is now known as CarlFK | ||
| * d1b suggests vim + wiki editing and runs | 18:54 | |
| geiseri | any one else an expert at the ubuntu/debian installer and making a custom CD? | 18:56 |
| ogra | geiseri, #ubuntu-installer probably :) | 18:57 |
| === yofel_ is now known as yofel | ||
| === rickspencer3 is now known as rickspencer3-afk | ||
| === jldugger is now known as pwnguin | ||
| === guest23323r_ is now known as mgunes | ||
| LordKow | i have a problem: karmic is not broken and boots just fine... what package should i submit the bug report under? :-) perhaps gcc so we can build against 4.5 and break something/everything ? :-) | 22:03 |
| === rickspencer3-afk is now known as rickspencer3 | ||
| === dmb_ is now known as dmb | ||
| === yofel__ is now known as yofel | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!