[00:44] Looks like zirconium has wedged on sysvbanner translation stripping just like molybdenum did for the previous upload [00:46] i have chatzilla and can not connect to ubuntu. I get another window#ubuntu-read-topic [00:51] billisnice: Well, perhaps you should, uh, read the topic? [00:51] i do not understand how to set another port with chatzilla [00:53] billisnice: google for it or ask in #ubuntu [00:53] billisnice: I think its "/server irc.example.org 6667" [00:53] i can get to ubuntu to ask [00:53] billisnice: just type "/join #ubuntu" [00:54] when i type that i get === #ubuntu #ubuntu-read-topic Forwarding to another channel [00:54] i am not very computer literate for sure [00:54] lol [00:56] billisnice: ok sry you have some weird router problem.. im not sure why its not letting you join.. [00:56] billisnice: the topic in that channel says: [00:56] Your router is buggy 1) Please follow these instructions: https://help.ubuntu.com/community/FixDCCExploit to FIX it (yes, it can be fixed) 2) after carrying out those instructions please type « test me » and wait few minutes | if this fails, type « /join #ubuntu-ops » to be tested manually [00:56] i was in for yrs until a few days ago [00:58] billisnice: maybe they added a check for this recently or something.. not sure [00:59] billisnice: anyway, what you need to do is to start connecting to freenode using port 8001 instead of 6667 [00:59] billisnice: the command to do that is: "/server irc.ubuntu.com 8001" [00:59] let me try [01:01] this is what i get NickServ * This nickname is registered. Please choose a different nickname, or identify via /msg NickServ identify . " =-= User mode for Administrator_ is now +i [01:02] billisnice: just choose another nickname, type: "/nick billisnice2" or whatever [01:03] billisnice: anyway, you should probably talk to the folks in the #ubuntu-ops channel, they seem to have added this router check thingie [01:03] it says =-= YOU are now known as billisnice2 but there is no one in the room buy me lol === StooJ|Away is now known as StooJ === DaIRC34444 is now known as randomnic === randomnic is now known as DaIRC82633 === DaIRC82633 is now known as sea4ever [02:11] anyone know why wacoms create so many XInput devices? [02:11] in jaunty [02:16] wow the buildds are way behind [02:19] ianm_: how many? [02:20] pwnguin: I think 4 per physical device [02:20] sounds about right [02:21] stylus, cursor, erasor and? [02:21] pwnguin: and one without any suffix [02:22] I don't get it, they all claim to have the same axes and buttons [02:23] it's "Wacom Bamboo", "Wacom Bamboo eraser", "Wacom Bamboo cursor", and "Wacom Bamboo pad" [02:23] ah [02:23] the pads sometimes have buttons on themp [02:23] them [02:24] but why don't those just show up in "Wacom Bamboo" ? [02:24] probably the better question is what "Wacom Bamboo" is about [02:24] ? [02:25] Wacom Bamboo = a pad and a pen, and both have buttons on them [02:25] whats the pen have on it? just an erasor and right click button? [02:27] the pen has two side buttons [02:28] plus cursor tip + eraser tip [02:28] i only have 1 wacom device, so the other stuff is foriegn to me [02:29] pwnguin: in Jaunty? [02:29] i mean [02:29] physical device [02:30] one laptop [02:38] Right, so wacoms are special. [02:38] ? [02:38] Different ways of using them are supposed to have different results. [02:39] A common case is that where someone has multiple pens, say a pen, a pencil, and an airbrush. [02:40] So, to support using lots of different devices with a wacom, the input layer has to be able to differentiate different pens. [02:40] (it doesn't really matter what comes in the box with a given set: the facilities are in the hardware, and expansion is supported). [02:40] so i can buy a super duper pen? [02:40] Right. [02:41] or steal one from the graphic design program [02:41] And you can have the different pens serve different purposes, or act differently. [02:42] persia: ok. do you know if this current model (4 XInput devices) is going to change soon? (the way wacoms work seem to be changing a lot) [02:42] Of course, this requires application support, and will be able to support even cooler effects with full MPX. [02:43] of course it's going to change? [02:43] ianm_, Well, there's actually that many devices. You have a pen that contains both a nib and eraser, and a pad that also has buttons. [02:44] If you add another pad, and no more pens, you'd get six. If you added an airbrush, you'd get seven. [02:44] thats only three [02:45] nib, eraser and pad is three by my count [02:45] persia: so why 4? I mean why both "Wacom Bamboo" and "Wacom Bamboo cursor" ? [02:45] Erm, I'd have to look at the events generated by them to answer that. Send me one? [02:46] heh [02:46] (or fiddle with input-utils yourself to achieve faster results) [02:46] i think the bamboo's are ~100 dollars [02:46] persia: a wacom? but I only have 5 :( [02:46] shows nothing: xinput test "Wacom Bamboo cursor" [02:46] ianm_, I'm mostly joking. Inspect the input-events streams from each device. [02:47] how? [02:47] maybe cursor is for the mouse that some come with? [02:48] cursor is for the nib [02:48] nib? the normal tip? [02:48] yes [02:48] hm? but it has no input events [02:49] ==> shows nothing: xinput test "Wacom Bamboo cursor" [02:49] and you shouldn't get a device showing for a physical device you don't own. [02:50] you mean, if I steal a usb stick it should not show up :) [02:51] ianm, my question would be was there any difference with previous versions when you are specific about jaunty? [02:53] it's not clear from this discussion if you ask 'should this really have 4 input devices?' or 'it used to have only n now it has 4, what changed?' [02:54] my #1 question is, is this right/normal and likely to remain this way in the next ubuntu version [02:54] I guess this is not a decision for ubuntu devels, it comes from the kernel drivers [02:55] hm OK [02:55] ianm_, It's at least explicable, and not entirely unexpected from discussions on tablet support during the jaunty cycle. I would expect future solutions to also identify individual devices (although perhaps not with that level of specificity: I would only have expected 2 guessing entirely based on the packing description for the device) [02:56] of course I don't know anything about wacoms, but it might simply show in hardware level as four devices in same usb cable to system [02:56] hile, No, that's not the issue. wacoms are special. [02:56] ah, ok [03:00] ianm, my guess is based on this discussion (remember, not really familiar with these devices) the driver shows all things which this tablet might support, if you had them, and maybe should be hiding things which are not connected [03:01] I guess it really _is_ good idea to have multiple devices for different parts, of course it's not fun if the names and IDs change between releases though [03:01] No. It *doesn't* show the set of possible devices. It shows the set of devices required to process the set of input events the hardware generates. [03:03] I was just wondering about the 'extra' device myself here, but maybe I'll shut up if I don't know tablets anyway :) [03:12] persia: when did this happen? [03:13] last i knew the HAL detection gave you one device and you just got to deal [03:13] pwnguin: HAL was fixed fairly late in Jaunty to provide lots of devices. [03:13] this is what i get for not paying attention [03:14] and for working around the whole autodetection with xorg.conf [03:17] persia: do you know if the device IDs show up in the same order for all wacoms? "Wacom Bamboo eraser", "Wacom Bamboo cursor", "Wacom Bamboo pad", "Wacom Bamboo" as 9,10,11,12 respectively in this case (NOT asking if they'll be the same numbers, of course) [03:18] ianm_, I don't,. [03:18] presumably, you could write a script to resolve the deviceID from the string [03:19] pwnguin: yes, but I use multiple wacoms at once :D [03:19] pwnguin: so several have the name "Wacom Bamboo" [03:19] heh [03:20] i would imagine usb connected pads are not detected deterministically [03:20] ianm_: I'm fairly sure that's not guaranteed. [03:20] I'm certain it's guaranteed *not* to be deterministic. [03:21] so how do I (as programmer) know which eraser goes with which cursor and which pad? [03:21] The X server could quite reasonably one day start to randomly assign numbers. [03:21] ianm_: You check the properties on the input device, which probably don't exist yet. [03:21] ianm_, It doesn't work that way: you can use any eraser on any pad. [03:21] Ideally something like the device's serial number would be exposed in the device. [03:21] every time i think wacom is nearly solved [03:21] And beause of the identity of the eraser, it will be the same device. [03:21] Device *properties*, that is. [03:22] someone comes up with a crazier "but, but.." scheme [03:22] persia: Oh, it works like that, does it? [03:22] wgrant, That's actually sensible. [03:22] wgrant, That's my understanding, to support different (physically identical) devices. [03:22] ianm_: what exactly is the purpose of having multiple pads? [03:22] But including the serial numbers, or some other UUID would be a way to resolve it. [03:22] persia: I was under the impression that the tablet just thought "ooh look, an eraser! I'm going to report events to my eraser device now" [03:23] competitive crayon physics? [03:23] pwnguin: to have multiple people drawing [03:23] ianm_: You could check the HAL device name, although that might not be visible to normal apps. [03:24] pwnguin: or just two super high res x/y/pressure inputs. I'm a VJ [03:24] wgrant, From a which search, I believe that it's not per-class, but per-device. [03:24] s/which/quick/ [03:25] a VJ? [03:25] do you do parties? [03:25] persia: That doesn't seem likely, as that would mean it would have to grow a new XI device when it saw a new pen. That's doable, but doesn't seem likely. [03:25] yeah [03:26] so in an app that just knows the id of a wacom device (the one called "Wacom Bamboo") which reports the pen tip x/y/pressure and the pen buttons, how do I connect to the eraser? [03:26] i thought video jockies were an MTV invention [03:27] pwnguin: don't get caught up on the name, it's fun interactive light shows [03:27] wgrant, Hrm. I don't know how else to do the "automatic per-pen profile selection" I see in the data sheets, and without the ability to grow new devices, how does one support an airbrush, mouse, etc. [03:27] persia: It sounds like you might be right, then, although it seems a little strange. [03:28] But I suspect I should stop participating in this conversation before I end up adding a collection of wacom stuff to my shopping list (when I don't really have a use case for owning them beyond comprehension) [03:28] Heh. [03:28] wgrant, Right. wacoms are special. (which is where I came in) [03:28] persia: do you have a projector? [03:29] ianm_, No. [03:29] persia: I knew they had lots of heads, but I didn't know they grew new ones at will. [03:30] wgrant, At least the shops sell a variety of heads for use. I'm not sure about the *any pen* bit: there seem to be several different color-coded options for pens. [03:30] So, rather than pen+UUUD it might just be pen+color [03:30] (limiting one to 5-6 devices per-pad) [03:30] How confusing. [03:31] Indeed. It's a really cool solution for the intended purpose, but not a close fit to our model of handling input events. [03:33] hm [03:33] maybe I should remodel this [03:33] More complication: according to wacom(4), wacom protocol IV doesn't support the pen-profile bit, and wacom protocol V does, and both are used in currently-shipping hardware. [03:34] http://www.penny-arcade.com/comic/2009/1/9/ [03:34] (and also according to that it is based on serial number, so exposing that as a UUID to HAL would make sense) [03:34] wgrant: so are you saying there's no way to determine which eraser is on which pen? [03:35] ianm_, If you set your X debug level to 6, the driver will show the serial number, but it's apparently not used by HAL. [03:35] For your use case, I would have recommended a couple of USB synaptics touchpads. [03:36] HAL doesn't really need to know about it - the driver or evdev needs to expose it as an XI property. [03:36] persia: touchpads are pretty awkward for drawing though (I also have a driver for touchpads as X/Y pads) [03:37] wgrant, So, it's just a driver issue? [03:37] ianm_, Hrm. That's certainly true. [03:38] persia: If the driver is able to spew it into the log, it is also able to put it into a property. [03:38] persia: So it looks like it's just down to the driver now, yes. [03:38] Right. So that's the bug. Someone with a wacom should track that down and fix it. [03:38] persia: http://photos-d.ak.fbcdn.net/hphotos-ak-snc1/hs004.snc1/4155_72565298156_531288156_1844763_3590172_n.jpg [03:38] And then we have eraser-7a8d8c9e9f9b9a [03:39] Which can then be used sensibly in userspace. For extra points, the UUID should probably also encode which pad is being used, as well as which device. [03:40] for the highest difficulty, convince Ping to do this before the heat death of the universe [03:40] persia: You could either put it in the device name, or hide it away in a property so users don't see the ugliness. [03:40] wgrant, hiding it in a property is better. I just don't know how to express that as a noun effectively. [03:41] Actually two properties: one for the pointer device UUID and one for the tablet UUID. [03:54] wgrant: so currently there's no way to know which eraser goes with which pen? that's rough... :) [03:56] ianm_, As an accident of device enumeration, it's likely that adjacent devices belong to the same physical device. [03:56] persia: yes that does seem to be the case, that's why I asked if that's consistent [03:56] ianm_: It's a lot less rough than having only one device show up, like Intrepid and earlier. [03:56] It's not guaranteed. [03:57] wgrant: yeah! and I would imagine no one uses more wacoms simultaneously than me, so I appreciate that ;) [03:58] so what magic am i missing [03:58] that my tabletPC only has one apparent device [03:58] ianm_: No, no, previously only one of the heads of each device would show up. [03:58] pwnguin: Do you have wacom-tools? [03:58] i do [03:58] wgrant: you mean multiple wacoms worked before, even though you had to set it up manually in xorg.conf? [03:59] ive also moved xorg.conf out of the way to see this in action [03:59] ianm_: I'm not sure. [04:00] if so, I did a lot of upgrading, including running into new intel graphics bugs, for nothing, but oh well :D [04:01] actually, it seems to be finding my cursor and erasor [04:01] but i have no right click [04:01] so maybe I'll hardcode it to use ID-1, ID-2, and ID-3, and see how far that gets me [04:04] i guess its time to go read those bugs ive been ignoring about wacom [04:17] wgrant, I can't seem to find the bit that sets the properties. Do you have any suggestions for function names I should be seeking? [04:20] hm the buttons on the Wacom Bamboo pad don't seem to show up anywhere [04:21] ianm_: i have a similar problem with my right click [04:25] I'm now very confused. There's a changelog entry in xf86Wacom "2005-11-17 47-pc0.7.1-1 - Report tool serial number and ID to Xinput". [04:25] pwnguin, Can you double check the xinput properties for your device? There should be useful information available. [04:26] persia: any tips on what commands do that? [04:26] persia: http://pastebin.com/d6cf59844 ? [04:28] pwnguin, xinput list? [04:28] ianm_, Thanks. [04:28] ianm_, Could I have list-props for the other three as well? [04:28] persia: all identical [04:29] http://pastebin.com/f72f6d546 [04:29] * persia is all sorts of confused. [04:29] probably [04:29] i grepped too much out [04:29] You guys have xserver-xorg-input-wacom loaded? [04:31] http://pastebin.com/m4016b702 [04:31] there's the full entry [04:31] persia: installed yes [04:32] Does Xorg.log report it being used? [04:32] (II) Loading /usr/lib/xorg/modules/input//wacom_drv.so [04:33] I'd expect list-props to provide a serial number or something. There's a bug in here. [04:34] mmhmm [04:34] (II) LoadModule: "wacom" [04:34] (II) Loading /usr/lib/xorg/modules/input//wacom_drv.so [04:41] anyone know why openjdk-6-jre is not installable on hardy? [04:41] openjdk-6-jdk: Depends: openjdk-6-jre (= 6b09-0ubuntu2) but it is not going to be installed [04:42] calc, what happens when you try to install openjdk-6-jre? [04:42] hmm i think the problem may be with my chroot not havint the security/updates uncommented [04:43] hmm actually they are [04:43] openjdk-6-jre: Depends: openjdk-6-jre-headless (= 6b09-0ubuntu2) but it is not going to be installed [04:43] openjdk-6-jre-headless: Depends: tzdata-java but it is not going to be installed [04:43] tzdata-java: Depends: tzdata (= 2008b-1ubuntu1) but 2009f-0ubuntu0.8.04 is to be installed [04:44] pwnguin, ianm_ My apologies, but I think I've gotten as far as I can without a device, and want to delay getting one by at least a few more months. I'd recommend looking at the VCS for the driver, specifically xf86Wacom.c, and review the changes made to "add hotplug support". I believe the passing of the tool and pad serial numbers to Xinput was dropped at that point. [04:44] persia: well, im not interested so much in crazy multi pen / pad maddness [04:45] i'm confused these versions seem to be old versions even though i have security/updates available [04:45] 4 pads is the minimum for any reasonable person [04:45] doh [04:45] cody-somerville: nm i figured out what i did wrong [04:45] calc: no universe -updates? [04:45] cody-somerville: i forgot to add universe to those [04:45] ianm_: thats far too many to carry around [04:45] ajmitch: yea, doh ;-( [04:46] * cody-somerville goes to watch the newest episode of house! :) [04:48] pwnguin, re: multiple pads, I agree. re: multiple tools, I think it's a nice use case to be able to physcially switch between pen and airbrush without worrying about fiddling with software. [04:57] persia: Input properties only appeared in 2008; that 2005 thing must be talkin about some other interface. [04:58] Aha! [04:59] persia: multiple pads sure is useful when you have multiple humans :) [05:01] ianm_, So are multiple computers :) But yes. [05:02] persia: it's quite fun to draw on the same canvas! [05:04] how does that even work without MPX? [05:05] pwnguin, rapid switching on absoute coordinates. === j_ack_ is now known as j_ack [05:28] pwnguin: was that Q for me? [05:29] if so, it works by reading from the xinput devices directly [05:29] not using them as mice === sea4ever is now known as wumpus_2 === wumpus_2 is now known as sea4ever === sea4ever is now known as _4ever [07:07] good morning [07:33] Good morning [07:33] tkamppeter__: hi === tkamppeter__ is now known as tkamppeter [07:45] pitti, hi [07:48] tkamppeter: good morning === StooJ is now known as StooJ|Away [08:04] pitti, I have re-uploaded s-c-p yesterday night, with the missing bits in the debian/changelog missing. [08:05] pitti, now I see you have passed it through. Thanks. [08:05] tkamppeter: no problem, sorry for the hassle === azeem_ is now known as azeem [08:35] pitti: There's a sysvbanner build stuck in dbgsym processing on i386 and lpia again [08:36] wasn't me, i didn't break it === mkorn is now known as thekorn_ [08:44] maxb: weird [08:44] maxb: I'll try to reproduce it locally [08:49] pitti, in the mood to sponsor an upload? (I'm just finishing off an FTBFS fix for apr) [08:51] NCommander: sure [08:52] Let me just finish the bug. [08:53] Oops, hold on, forgot to fill out the dpatch header [08:55] pitti, https://bugs.edge.launchpad.net/ubuntu/+source/apr/+bug/372068 [08:55] Launchpad bug 372068 in apr "FTBFS fix for APR" [Undecided,New] [08:56] kirkland: section 7 of RFC 4252 describes the messages used in SSH publickey auth [08:56] NCommander: please send this to Debian as well, it should hit them as well? [08:57] pitti, I'll test to see if APR if it still breaks [08:58] NCommander: if it breaks for us, why doesn't it break for Debian? [08:58] pitti, I stopped trying to make sense of libtool breakage along time ago [08:58] * NCommander is just waiting for his sid chroot to update [08:59] it built just fine in Debian [08:59] NCommander: anyway, upload prepared, tell me when to fire [09:00] pitti, fire when ready [09:00] NCommander: *boom* [09:01] * NCommander watches karmic die [09:01] * NCommander is somewhat amazed at the level of breakage this cycle [09:02] NCommander: really? except for the new intel driver, karmic didn't break at all yet [09:02] pitti, are we looking at the same FTBFS counts :-) [09:02] oh, those [09:03] NCommander: just talking about stuff that actually reaches my machine [09:03] pitti, you already upgraded to karmic? [09:03] sure [09:03] and speaking about autof*** breakage, /me goes back to that gthumb merge [09:03] pitti, which merge? [09:03] (didn't I just say? gthumb) [09:04] pitti, er, I mean whats broken about the merge :-P [09:04] pitti: we still have some changes ubuntu specific in this one? ideally it should go to universe and be a direct sync [09:04] seb128: yes, lpi and a gvfs fix to unmount when using libgphoto [09:04] ah ok [09:04] the lpi one is sticky [09:04] I guess lpi could be dropped [09:05] but if we have diff anyway we can as well keep it [09:05] I sent the gvfs one upstream months ago, it wasn't applied yet :( [09:05] pitti, Debian already has a fix pending (slightly different from the one they used), and its fixed upstream [09:05] so once Debian has an upload its just a sync [09:05] NCommander: in apr? nice [09:05] is it now some magic for packages with python modules to compile nicely with python2.6 without modification? [09:05] pitti, yeah, someone backported the SVN fix for APR [09:06] seb128: if we drop it to universe, we could drop two changes (libopenrawgnome-dev build dep and POT building) [09:06] but it's one of the packages which call autoconf at runtime, and it just falls apart [09:06] * pitti renews his deep hate towards autotools [09:06] bigon: if you have the site-packages directory coded in rules on install I don't think so [09:07] on -> or [09:07] pitti: so basically once the gvfs fix is upstream or in debian we could move to universe and sync [09:07] yes [09:07] if we don't care about lpi any more [09:08] * NCommander takes out a machine gun and shoots gstreamer0.10 [09:09] seb128: http://pastebin.com/d1b39b68 << because I get that and the module is correctly installed [09:09] NCommander: what is the issue? [09:09] seb128, libtool breakage [09:09] NCommander: you don't try to fix the karmic build do you? [09:10] seb128, huh? [09:10] pitti, do I need to files bugs to get NBS packages with no rdepends removed? (file size 0) [09:10] NCommander: no [09:10] those are autocleaned when somebody have a go at this list [09:10] seb128, which list? (I'm trying to fix outstanding FTBFSes in main and universe) [09:11] NBS [09:11] oh [09:11] NCommander: and gstreamer0.10 is already fix commited [09:11] Oh [09:11] Handy :_) [09:11] it's early to fight karmic ftbfs issues [09:12] NCommander: http://paste.ubuntu.com/164757/ [09:12] I have NFC what libtool wants to tell me [09:13] Oh that fun. [09:13] yeah, I had that issue [09:13] Looks like the package is setup in a way that there are multiple libtool instances [09:13] * NCommander grabs the source [09:13] pitti: run autoreconf [09:14] pitti, autoreconf -if [09:14] pitti: you are using different versions than the one used for the tarball and don't run all the auto* or not in the right order [09:14] pitti: running "autoreconf" should fix it [09:15] pitti: that's a mismatched ltmain.sh/aclocal.m4 [09:15] in fact, the Makefiles themselves run autoconf [09:15] so apparently they don't run libtool (neither the external nor the internal copy) [09:16] seb128, if its too early to start fighting FTBFS, when do you recommend doing so? Alpha 1 is in a week and a half :-/ [09:16] NCommander: no need to clean universe for alpha1 [09:16] seb128, I'm just focusing on main ATM [09:16] (apr is in main) [09:16] NCommander: most of those issues will be fixed along the way with autosyncs, etc [09:16] seb128, there is enough breakage in main to be afraid :-P [09:16] " seb128, which list? (I'm trying to fix outstanding FTBFSes in main and universe)" [09:16] you listed universe [09:17] pitti, I'll do universe ones when I run out of main :-P [09:17] er [09:17] seb128, [09:17] I've nothing against you spending your time on that [09:17] but that's often a waste of time [09:17] * NCommander usually goes right down the list [09:17] don't create extra diff for things which are on sync and that debian will fix though [09:17] NCommander: the archive doesn't need to be buildable for alpha1, just installable [09:17] they're quite different things [09:17] ie gstreamer ;-) [09:18] and it's probable that most FTBFS can be fixed by doing an outstanding merge [09:18] * pitti flushes an autosync run [09:18] seb128, Keybuk: thanks, that helped; I'll add it to debian/rules [09:18] it now FTBFSes in a different way at least [09:18] Keybuk, then what do you recommend I do? [09:18] NCommander: http://merges.ubuntu.com/main.html#] [09:18] intltool-update looking at .pc/04-fix-gvfs-umount.patch/data/gthumb-import.desktop.in [09:19] NCommander: 293 to do there [09:19] pitti: can't you just comment the autotools call there? ;-) [09:19] urg [09:19] seb128: no, the upstream makefiles themselves are set up to call autoconf etc. [09:19] apparently in an insufficient way [09:20] pitti: sounds like something ran aclocal or similar by accident? [09:20] ordinary automake makefiles won't do that [09:21] debian/rules doesn't call any auto* so far; I added an autoreconf -fvi now [09:21] we have it in bzr-buildpackage, so screw an unclean diff.gz after binary build [09:22] Keybuk: we do patch some Makefile.am, so in principle it is right in automake'ing [09:29] pitti: right, but calling automake itself should be harmless [09:29] likewise autoconf [09:30] that won't cause the error you saw [09:31] calling aclocal is what tends to cause that brekage [09:33] probably just need "libtoolize" ran === thekorn_ is now known as thekorn === StooJ|Away is now known as StooJ [09:39] directhex: here? [09:39] directhex: ah, nevermind; unping [09:45] hello, how to let sshd start before desktop? i can't login to ubuntu by ssh at gdm time [09:45] zhxk`: by default that should work; ssh is started at S16, gdm at S30 [09:47] how to troubleshoot? sshd stops as soon as out to gdm from gnome [09:47] (on a sidenote that belongs to #ubuntu) === zhxk` is now known as zhxk [09:52] * directhex smells n-m [09:52] pitti, you can still ping me if you like [10:05] seb128: why are you "rebasing" the gnome packages? [10:05] dholbach: you probably call that merging, why not? [10:06] dholbach: to lower delta, send changes back to debian, etc? [10:06] dholbach: why do we do it for all the non GNOME packages? [10:06] merging and sending stuff upstream is definitely fine - you're dropping history [10:06] we do that since warty [10:06] I was a bit confused by the wiki page and the stuff in the sponsoring queue [10:06] if you are speaking about changelog entries [10:06] yeah [10:07] we do that for ages [10:07] a lot of packages have history since warty [10:07] no point to have hundred of NEWS summaries [10:07] pitti, when you get a free moment, can you please sync https://bugs.edge.launchpad.net/ubuntu/+source/libxfcegui4/+bug/372098 for me? (I have a bunch of outstanding merges that are dep-wait until that goes through :-)) [10:07] and I don't see the point, it's extra work [10:07] Launchpad bug 372098 in libxfcegui4 "Sync libxfcegui4 4.6.1-1 (universe) from Debian unstable (main)." [Wishlist,Confirmed] [10:08] NCommander: you know there is a process to request syncs and several archive admins [10:08] seb128: OK, I was confused - if we do it we should make sure though that we still have pointers to all the bugs that were fixed by patches that we ship [10:08] NCommander: karmic is not such an hurry now that you need to ping people on IRC [10:08] seb128, we're uploading to karmic so we can do a SRU of 4.6.1 [10:08] seb128, (of Xfce) [10:08] which has quite a few bug fixes [10:08] dholbach: we summarize changes in the current changelog entry and try to tag patches [10:09] seb128: that's good - just wanted to make sure I knew what you guys were doing [10:09] NCommander: that doesn't seem urgent enough to IRC ping to speed up things, syncs are processed daily [10:09] (when doing sponsoring) [10:09]