=== akgraner_ is now known as akgraner === robbiew is now known as robbiew-afk [00:20] anyone used the gtk-vnc plugin at some point? [00:21] asac: what plugin? [00:21] pochu: firefox plugin [00:21] ah ok [00:21] not me then :) [00:22] mozilla-gtk-vnc === ds5 is now known as ds[de] === Amaranth_ is now known as Amaranth === MobileMyles6o7 is now known as TwoToneSpirit [06:29] good morning [06:39] hi al-maisan, hi glatzor [06:39] morning dholbach ! [06:40] moin dholbach :) [06:41] hmm. karmic has started to attempt to automount hard disk partitions as a user [06:41] non-removable hard disks, that is [06:44] yea that happens for me too [06:44] nellery, do you know of an existing bug? [06:45] which component does that, anyway? gvfs? [06:45] liw: not sure, haven't gotten to looking yet [06:46] hngh, and while trying to report that, X crashed [06:47] it crashed on me yesterday, too [06:47] liw: intel? [06:47] (killing a computation that had been running for about 6 hours out of the 8 it needed) [06:47] lifeless, ati [06:47] liw: 'screen' [06:47] lifeless, screen is not entirely useful for programs that require X [06:48] liw: oh; don't use those :P [06:48] har har :) [06:48] liw: or screen + xvnc [06:49] how long does it take for a package to go from built, published and then to the main archive.ubuntu.com multiverse repo? [06:49] anyone know? [06:55] nellery, https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/397288 -- fyi [06:55] Ubuntu bug 397288 in gvfs "karmic auto-mounts non-removable drives" [Undecided,New] [06:57] liw: thanks [06:57] Good morning [07:28] TheMuso: bug 396377> "Use the ubuntu-bug force, Luke!" :-) [07:28] Launchpad bug 396377 in hal "Touchpad not functioning on MacBook Pro 4.1" [Undecided,Incomplete] https://launchpad.net/bugs/396377 [07:28] TheMuso: (need lshal output at least) [07:29] is it just me, or did the "reading database..." dpkg step recently became much, much, much slower? [07:30] it took like 2 seconds in the past, and now it takes 20 [07:32] pitti: I thought that would have been included in the bug, but ok I'll attach it. [07:32] TheMuso: thanks [07:44] pitti: yea it's taking significantly longer for me too === tkamppeter_ is now known as tkamppeter [07:50] pitti: Finally got a chance to test my fix for bug #393376 [07:50] Launchpad bug 393376 in xen-3.3 "xen-3.3 3.3.0-1ubuntu10 FTBFS" [Undecided,Confirmed] https://launchpad.net/bugs/393376 [07:50] I could create a VM, but it didn't seem to be doing anything, but udev was walling me in at every turn, so I don't know what's working and what's broken [07:51] billybigrigger: once it's built, the next publisher run that starts at three minutes past each hour will process it, usually finishing towards the end of that hour [07:53] billybigrigger: (I've added a bit to https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Publishing about that) [08:25] cjwatson, thanks for the info [09:03] tjaalton: I just followed up on bug 272606; you have a better understanding of this, though, could you please have a look at the last three comments? [09:03] Launchpad bug 272606 in xkeyboard-config "ABNT2 Numpad Keyboard keys misbehaving" [High,Fix released] https://launchpad.net/bugs/272606 [09:03] pitti: yes, upstream broke it [09:03] tjaalton: the alias stuff doesn't work? [09:04] pitti: here's how it was fixed: http://cgit.freedesktop.org/xkeyboard-config/commit/?id=fd7fa190c4f817bacac23c98e43c61b60064bffd [09:05] the special models were all removed (ABNT2, jp106..) [09:05] that's why it broke [09:06] ok, thanks for confirming [09:08] stvo: hey [09:22] Does base-files absolutely have to dump yet another dotfile to ~? Why not put the timestamp to an XDG Base-Something compatible path? [09:26] XDG configuration-- [09:26] stupid idea [09:27] cjwatson, what's that? [09:27] ion: I also said that on a followup to ubuntu-devel@ [09:27] the dumb ~/.config/ thing [09:27] cjwatson: why is that dumb? [09:27] dotfiles are hidden for a reason; dumping them in a subdirectory achieves nothing and creates complexity [09:27] dotfiles are a pain [09:27] I wish they had used ~/.etc/ fourty years ago [09:28] cjwatson, and yet, having yet another dotfile is not good, either [09:28] for consistency, and not cluttering your home dir with a wild mix of cache, config, and data files [09:28] (.hush_login ftw) [09:28] moving cache and data, I agree. but it's silly for configuration. [09:28] ion: I proposed ~/.cache/motd/legal-shown , or something [09:28] (and, OK, this particular example is a cache) [09:29] the pain is things that inappropriately show dotfiles by default (e.g. file dialogs) [09:29] * liw stops being annoyed about dotfiles and continues being annoyed at pygtk, gtk, gnome, and default window sizes [09:33] heh :) seems i'm not alone with the nasty gdm bug :( === asac_ is now known as asac [10:33] Keybuk: just to avoid double work, did you do any getty investigations so far? Just starting to look at the code now [10:34] pitti: no, I don't think there's any possibility that way [10:34] I found lots of other bugs too [10:34] if you don't start with splash, you can end up with X on vt2 [10:34] so it just ends up going random [10:35] the fix really needs to go into X or gdm [10:35] okay [10:36] good to know, then I don't waste time on getty, and instead coerce gdm to start on vt7 [10:37] it does bring up interesting points about how we should deal with all this [10:37] if X is starting on the "first unused tty" [10:37] Keybuk: I don't think I'd like to fix it in X itself [10:37] while getty is starting on hardcoded ttys [10:37] you're always going to end up with X and getty trying to share in some corner case [10:37] especially with the racey async start [10:37] well, I thought about adding an option to gdm-binary [10:37] like --tty 7 [10:37] I think X's code is right [10:38] in that it can be passed a hardcoded vt, or looks for one itself [10:38] so that we can equally hardcode the gdm vt just as we hardcode the getty ttys [10:38] I was wondering whether getty shouldn't have the same code ;) [10:38] Keybuk: X rightX> I agree [10:38] why cant we hardcode getty to tty2 ? [10:38] ogra: because if you start from single-user mode, you'll have a shell on tty1 [10:38] and leave 1 untouched [10:38] ogra: so X will then pick tty2 as "the next unused", and thus conflict with getty again [10:38] buys us nothing over leaving it on tty7 [10:38] (putting it on tty2) [10:39] oh, sorry, you said getty on tty2 not X on tty2 [10:39] we either need to hardcode X's vt [10:39] ignore me [10:39] i meant pushing the gettys al to tty2 [10:39] or we need to stop hardcoding getty's [10:39] * ogra would vote for the latter [10:39] it occurred to me that it'd be kinda cute for desktops to start "a number of gettys" [10:39] and for it to just automatically find unused vts for them [10:39] servers would end up 1-6 [10:39] desktops may end up 2-7 [10:40] Keybuk: but wouldn't that be pretty much the same code than teaching getty to not use an already taken vt? [10:40] * ogra wonders whats so hard about fixing single user mode [10:41] does it really *need* to be on tty1 ? [10:41] pitti: except that there's no way to tell that a tty is "taken" or not, annoyingly [10:42] ogra: I'm trying to avoid a fix that involves us discovering yet more corner cases for the next hundred years [10:42] pitti: we can ask for the "next free vt", but that's it [10:43] Keybuk: ok [10:43] seems it'd be best to add that "vt" argument to gdm for the time being, since that bug is nasty [10:43] pitti: the more I think about it, the more I like having a simple "number of gettys" option [10:43] yeah [10:44] Keybuk: so, "/sbin/getty -8 38400 tty1" -> "tty-auto"? [10:44] and call that 6 times? [10:44] that would be great indeed, and avoid these races [10:45] pitti: exactly [10:49] exec openvt getty -8 38400 - [10:49] would do it ;) [10:50] might be better to patch getty though [10:50] so then a user who actually wants to use those gettys has to use trial and error to figure out which tty they're on? [10:51] slangasek: your login sessions will be on 1-7 [10:51] just X might be on 1 [10:51] in fact, X would be on 1 most likely [10:51] yes, so CTRL-ALT-F1 may or may not get you to a getty [10:51] slangasek: it won't [10:51] it already doesn't on Fedora and SuSE [10:52] no, it *may or may not*, the whole reason you're even discussing these changes is because it's racy... [10:52] slangasek: not racy, that it depends on what else you do on the way up [10:53] isnt X supposed to be up long before the gettys in the new model ? [10:53] if it's asynchronous, what guarantees that X has succeeded in being brought up yet? [10:54] and cant upstart handle them conditional based on runlevel and if X is up ? [10:54] what I, obviously, want to avoid is having a boot performance penalty for every system because a very small minority of desktop users expect there to be a getty on vt1 [10:54] ogra: because we can't predict which vt(s) X will take, you can't just have Upstart disable the right getty [10:54] thats not waht i meant [10:55] you just said above "exec openvt getty -8 38400 -" would make gettys start in first available tty [10:55] available vt, but yes [10:56] conflating vts and ttys is one of those "but they're the *same* ... well, ok, almost the same" issues [10:56] if you now make that depending on "if X was attempted to start" and "if not in sigle user" they would be guaranteed to start after X inits and on the first free one [10:56] ogra: that would be the case, yes [10:56] so X always owns tty1 [10:57] not necessarily ;) [10:57] boot into single-user mode [10:57] muck around a bit [10:57] right [10:57] then telinit 2 [10:57] your sulogin will be on tty1 [10:57] you may have (one of my favourite tricks) started other gettys while in single user mode [10:57] but thats a corner case where bootspeed doesnt matter [10:57] at least for X [10:57] that's not a speed issue, that's just showing that there's a case where X might end up on vt3 [10:57] and the further console gettys on vt4+ [10:58] boot with single, start another getty, telinit 2, now X is on vt3 (first available) [10:58] right but single user mode means something went wrong already or you are a evil hacker anyway [10:58] ogra: I usually assert that caring about getty means that too ;) [10:59] well, "fix" single user mode to always start its getty on tty2 ... hardcoded [10:59] so X will be on 1 [10:59] and subsequent ones on 3-7 [10:59] do not annoy the evil hackers, or they will replace your tty1 with a very small x [10:59] lol [11:00] ogra: that fix doesn't work, if you switch user, where does *that* X work [11:01] there's two options [11:01] where does it work if you are in a normal boot ? [11:01] 1) we hardcode all gettys, including X - that means that gdm is going to need to get all of its VT Allocation code back again and we'll have to maintain it [11:01] tty8 by default i'D guess [11:01] that's what we've always done before, since getty has been hardcoded since the DAWN OF TIME [11:01] and old gdm pretty much hardcoded X's VT allocation [11:01] or [11:02] right but today we only have one case where it *has to be* hardcoded [11:02] 2) we do all vt allocation on the fly [11:02] right 2 was what i proposed [11:02] ogra: no, we have some cases where it is hardcoded and some cases where it isn't, and that's causing us problems :) [11:02] but with the exception to handle it specislly in the special case of single user mode [11:02] slangasek: I'm going to guess you prefer #1 since then you know what C-A-F1...F7 all do? [11:03] ogra: if we just do it all on the fly, single user mode doesn't matter [11:03] it does [11:03] why? [11:03] you just explained it to me [11:03] because your tty will be 1 by default [11:03] so X starts on 2 [11:04] Keybuk: I think I'm in favor of 1) except for the "we'll have to maintain it" part ;) [11:04] if you hardcode it in single user to 2 your X is predictable on tty1 all the time [11:04] but yes, predictability is pretty important to me [11:04] and your subsequent gettys fill up until tty7 [11:04] if you switch user your gdm is predictable on tty8 [11:05] (if we even want 7 gettys at all that is) [11:14] yeah, felt pretty lonely for a moment [11:40] feature or a bug in ark. to extract multiarchive .r** rar needs to be installed, unrar is insufficient. but ark works with unrar if it is "ln -s" to /usr/bin/rar [11:56] how many of the developers live on x86-64? [11:57] updates to a release (hardy) go into hardy-proposed, and after they are accepted by the release managers, they get moved to hardy-updates; security updates to to hardy-security; nothing in hardy itself ever changes, is that correct? [11:57] liw: correct; the release pocket is pseudo-immutable once the release is done [11:58] so if I want to get all the post-release updates to hardy, I can just get everything in hardy-security and hardy-updates [11:58] yes [11:58] thanks [11:58] or simply hardy-updates, if you don't mind a little lag [11:59] oh, stuff in hardy-security gets moved to hardy-updates? [11:59] or copied? [11:59] copied [11:59] ok, thanks [12:00] so a) users can get by with only using -security if they don't want anything else, and b) users who enable the recommended -updates can make better use of bandwidth to the mirrors instead of exercising security.u.c [12:10] tests/test_initctl.c:3198: error: variable ‘reply’ might be clobbered by ‘longjmp’ or ‘vfork’ [12:10] now there's a new warning on me [12:12] I wonder what the hell it means [12:12] Keybuk, which one are you using? [12:13] liw: longjmp [12:14] and you gave it a club on its way, you evil guy :) [12:15] Keybuk, can I have a look at the code? [12:16] liw: you can, but it won't help very insightful :) [12:16] http://pastebin.ubuntu.com/213555/ is what the C99 standard has to say about variable values [12:17] http://bazaar.launchpad.net/%7Escott/upstart/trunk/annotate/head%3A/util/tests/test_initctl.c#L3327 [12:17] is one example [12:18] I think I had a lot more code in the signal handler once [12:18] in the sigsetjmp() if I mean [12:18] and now I can replace the whole thing with just calling _exit(0) in the signal handler :p [12:21] hmm. you modify reply in 3356; if my English is correct, that's bad (no using of variables whose values have been modified between the calls to sigjmp and longjmp) [12:23] your English? What does the spin on a cue ball have to do with anything? [12:23] my interpretation of the Englished used in C99, which, admittedly, makes my head spin luke a cue ball in billiards [12:23] ahh [12:25] er, s/shed/sh/ [12:40] * ogra wonders why he gets QA tracker mails [12:41] of course [12:41] * cjwatson guesses 8.04.3 [12:41] (tracker)0 [12:41] _if_ we use dynamic gettys, we finally have a reason for KDSIGACCEPT [12:41] Alt-UpArray = "give me another getty" [12:42] cjwatson, oh, right, forgot about hardy, thanks === ScriptRipper_ is now known as ScriptRipper [12:44] array? arrow! [12:44] would that work from a hung up terminal too ? (as long as the kernel isnt hung) [12:45] ogra: yes [12:45] neat [12:45] it's built into the kernel at the same layer as Alt-F1 [12:45] it just sends init SIGWINCH rather than any other processing [12:46] cool, lets add it :) [12:46] and go with a single getty ... saves ram as well :) [12:55] pitti, slangasek: the gvfs smb issue seems to be due to samba somewhat [12:55] pitti, slangasek: I rebuilt the glib and gvfs intrepid-updates versions on hardy and it still doesn't work [12:55] so I guess it's the hardy samba behaving differently but I've no clue about samba [12:57] oh, interesting === ogra_ is now known as ogra [12:58] seb128: well, hardy->intrepid is quite a jump for samba, but we can certainly put together something for testing - the package should build fine in a hardy ppa, at least... [12:58] seb128: are you sure it's samba, rather than nautilus, that is the added culprit? [12:59] slangasek, I'm testing with gvfs-ls smb: [12:59] slangasek, and it has the same issue [12:59] ok [13:00] hmmm, that sounds like a good non-GUI test case; perhaps I can do some useful chroot testing here [13:02] perhaps it would be worth building intrepid's samba on hardy and check if that fixes the regressin? [13:02] "Error: Operation not supported" [13:02] well, that's unhelpful [13:02] pitti: indeed [13:02] but either way, I guess we need to find a workaround in hardy's gvfs [13:02] since it's quite impossible to move intrepid's samba to hardy [13:03] if it turns out to be a samba bug, I have no problem hunting down the change [13:03] pitti, or find the samba change or fix required to make it work [13:03] seb128: right [13:03] would rebuilding the intrepid samba or hardy be useful in some way? [13:06] to confirm that it's a change in the samba source that's to blame, yes [13:06] seb128: any idea why I get this 'Operation not supported' from gvfs-ls smb://? [13:06] is that in a chroot? [13:06] yes [13:06] also outside of a chroot, though [13:07] hm, I get "this place isn't mounted" [13:08] slangasek, no, is gvfsd running? do you have a session dbus bus? [13:08] dbus-launch gvfs-ls smb: maybe? [13:08] pitti, gvfs-mount smb: [13:08] slangasek: does "gvfs-mount -l" work? [13:08] no gvfsd running, I'm in a chroot :) let me try the dbus-launch [13:08] pitti: yes [13:09] seb128: right, that seems to do stuff; "reception of share list from server failed" (quite naturally, I don't have a server running) [13:09] slangasek: gvfs-mount will autostart gvfsd usually [13:10] ps ux|grep gvfs|awk '{print $2}'|xargs kill [13:10] gvfs-mount -l [13:10] -> all monitors and gvfsd are back [13:13] slangasek, pitti: http://paste.ubuntu.com/213580/ [13:14] I've that error in the gvfs log [13:14] you can run GVFS_DEBUG_SMB= /usr/lib/gvfs/gvfsd -r [13:14] before starting gvfsd-smb-browser [13:14] with which combination of packages? [13:14] hardy + intrepid gvfs (and glib) [13:14] I'm trying intrepid smb next but building it takes a while [13:16] I still don't appear to have things working right in the chroot, so I have no baseline to compare it to [13:16] can't you boot an hardy livecd somewhere? [13:16] $ dbus-launch gvfs-ls smb:// [13:16] works for me [13:16] I don't have a spare machine, and I don't have virtualization [13:16] ok [13:16] slangasek: do you have gvfs-{bin,backends} dbus-x11 installed? [13:17] (in the chroot) [13:17] pitti: that command /runs/, but it's returning no results [13:17] that would be the bug? [13:17] ah, ok; I didn't get the "operation not supporte" error any more [13:17] seb128: I'm running the stock hardy-updates packages... [13:17] ah ok [13:17] hum [13:18] smb_tp: jaunty-proposed kernel NEWed FYI [13:18] pitti, Ah, ok. the lrm and lbm too? === smb_tp is now known as smb [13:18] smb: will do once built [13:18] pitti, Then I upload meta now, so you can accept as soon as they are ready [13:19] smb: cool, thanks [13:20] pitti: and repeated invocations of dbus-launch gvfs-ls smb:// give me more gvfsd-smb-browse running... do I want to just run dbus-launch bash, maybe? [13:20] * smb relaxes after seeing he is not being called [13:21] heh :) [13:21] [hardy] 0 martin@tick:~ [13:21] $ dbus-launch bash [13:21] [hardy] 0 martin@tick:~ [13:21] $ gvfs-ls smb: [13:21] WORKGROUP [13:22] ^ after installing samba on my "outside" karmic system [13:22] * slangasek nods [13:22] * ogra hands pitti an umbrelly so his karmic system doesnt get wet in the rain [13:22] *umbrella [13:22] * pitti installs gvfs from PPA [13:23] ogra: to protect it from the sun? [13:24] ah, you got sun over there ? [13:24] * ogra is envious [13:24] yes [13:25] seb128, slangasek: so I think I reproduced that in a chroot [13:26] * pitti adds to bug [13:28] pitti, slangasek: how can I browse a workground or available workgroups with smbclient? [13:31] seb128, slangasek: https://bugs.edge.launchpad.net/ubuntu/+source/gvfs/+bug/207072/comments/233 [13:31] I think that's the regression you mean, right? [13:31] Error: Could not parse data returned by Ubuntu: The read operation timed out (https://launchpad.net/bugs/207072/+text) [13:32] pitti, yes [13:35] hello [13:39] seb128: smbclient -L -N, where is any known server, will give you a list of workgroups [13:40] ok [13:41] slangasek, "### SMB-BROWSE: do_mount - [smb://; 0] dir = 0x80d43e0, cancelled = 0, errno =" is one difference between intrepid version on hardy and karmic [13:41] the do_mount fails on hardy [13:41] * slangasek nods [13:41] and the call before the failure is a smbc_opendir(smb_context, "smb://") one [13:41] ok [13:48] pitti, slangasek: the intrepid samba installed on hardy doesn't solve the issue ... [13:49] seb128: does it make a difference if you build the intrepid gvfs *against* the intrepid libsmbclient-dev? [13:50] slangasek, building, one minute [13:56] slangasek, works with gvfs intrepid built with the libsmbclient from intrepid [13:56] pitti, ^ [13:56] ie the gvfs from intrepid starts working once rebuilt with new samba [13:57] seb128: is that true for hardy PPA built against libsmb from intrepid? [13:57] that starts being complicated [13:58] hardy + intrepid-updates gvfs built with hardy samba + intrepid samba = breaks [13:58] hardy + intrepid-updates gvfs built with intrepid samba + intrepid samba = works [13:58] it could be that the newer libsmb versions allow calls which didn't work yet in the hardy samba version? [13:58] (client-side, I mean) [13:58] could be, ENOCLUEABOUTSAMBA [13:59] seb128: how about hardy + hardy-ppa gvfs built with intrepid samba? :) [13:59] right, what I meant [13:59] (sorry, *still* don't have the test case working here :( [13:59] ) [14:01] slangasek, trying that, building [14:04] pitti, slangasek: hardy-ppa version built on intrepid samba works [14:05] great! [14:05] so, so apparently the gvfs patch uses some feature from libsmb* which isn't available in hardy yet? [14:05] that means if I can just get a test case, I can take samba apart [14:05] slangasek: which step fails for you? [14:06] pitti: getting a workgroup list with the hardy-updates version still fails for me [14:06] so I don't have a baseline to compare with [14:07] strange [14:07] https://bugs.edge.launchpad.net/ubuntu/+source/gvfs/+bug/207072/comments/233 is missing a "$" in front of the gvfs-mount, but I guess you did that [14:07] Ubuntu bug 207072 in nautilus "nautilus does not display samba shares for machines inside an ADS network." [Low,Fix committed] [14:07] honestly, it's probably a network config problem at this point [14:08] I have /proc, /tmp/, /home, and /sys bind-mounted in my chroots [14:08] perhaps that's it [14:08] no, I have that too (standard schroot) [14:08] wow [14:08] sorry wron chan [14:09] slangasek: local samba server or remote? (I just tested with apt-get install samba locally) [14:09] pitti: remote [14:09] but I've got a bunch of other stuff on the same broadcast domain that's going to wreak havoc if it's not all configured right, and apparently it's not [14:09] (workgroup bit rot) [14:11] slangasek: so that also happens with doing nautilus or gvfs on your normal system, not just the chroto? [14:11] no [14:11] the chroot isn't on my desktop [14:11] ah [14:11] A chroto? I've always wanted a chroto. [14:12] soren: they are really cool [14:12] pitti: So I hear. [14:12] soren: you have to feed them well, thuogh [14:12] argh tpying is hrad [14:12] * pitti fixes finger ordering [14:13] did chrotos geat cheaper recently ? last time i looked they were still unaffodable [14:14] ogra: I borrowed a chroto from a friend once, but it accidentally my whole keybaord. [14:15] soren: and your verbs [14:15] lol [14:15] * ogra was about to type the same :) [14:16] What do you mean? It accidentally my *whole* keybaord. It was crazy! [14:17] pitti: it's important that your middle finger goes between your index and ring fingers [14:17] no ! really ? [14:17] if you get confused your hands look really weird [14:18] ogra: Yeah! You need to be careful. If you don't pay attention, it'll your mouse and maybe monitor too. [14:18] cjwatson: too late, with a crazy keyboard like mine (http://people.ubuntu.com/~pitti/photos/pitti-real-desktop.jpg) they started looking weird long ago.. [14:19] http://www.fohguild.org/forums/attachments/screenshots/87340d1220554030-funny-strange-random-pics-2db6wiw.png [14:19] soren, thats scary ... i'll reconsider one [14:19] I could never cope with those keyboards [14:19] oh, nice, on that photo I still had my good ol'd iBook G4 [14:20] cjwatson: takes a while to get used to, but I'd never give it away any more [14:20] there are fully equipped keyboards too http://upload.wikimedia.org/wikipedia/commons/7/71/200801191443_Japanische_Tastatur.jpeg [14:20] ... pretty much like vim [14:20] these 104/5 keys really dont cut it [14:20] c'mon bloddy gdm, work now === dholbach_ is now known as dholbach [14:33] which version gdm will be used .26 or .27 series? [14:33] praveen1, there is no .27 [14:34] seb128: oho [14:34] k [14:36] pitti, slangasek: ok, gvfs is trying to do some clever things on old samba and that code might be broken [14:37] seb128: ah [14:39]