[00:20] <asac> anyone used the gtk-vnc plugin at some point?
[00:21] <pochu> asac: what plugin?
[00:21] <asac> pochu: firefox plugin
[00:21] <pochu> ah ok
[00:21] <pochu> not me then :)
[00:22] <asac> mozilla-gtk-vnc
[06:29] <dholbach> good morning
[06:39] <dholbach> hi al-maisan, hi glatzor
[06:39] <glatzor> morning dholbach !
[06:40] <al-maisan> moin dholbach :)
[06:41] <liw> hmm. karmic has started to attempt to automount hard disk partitions as a user
[06:41] <liw> non-removable hard disks, that is
[06:44] <nellery> yea that happens for me too
[06:44] <liw> nellery, do you know of an existing bug?
[06:45] <liw> which component does that, anyway? gvfs?
[06:45] <nellery> liw: not sure, haven't gotten to looking yet
[06:46] <liw> hngh, and while trying to report that, X crashed
[06:47] <liw> it crashed on me yesterday, too
[06:47] <lifeless> liw: intel?
[06:47] <liw> (killing a computation that had been running for about 6 hours out of the 8 it needed)
[06:47] <liw> lifeless, ati
[06:47] <lifeless> liw: 'screen'
[06:47] <liw> lifeless, screen is not entirely useful for programs that require X
[06:48] <lifeless> liw: oh; don't use those :P
[06:48] <liw> har har :)
[06:48] <lifeless> liw: or screen + xvnc
[06:49] <billybigrigger> 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] <billybigrigger> anyone know?
[06:55] <liw> nellery, https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/397288 -- fyi
[06:57] <nellery> liw: thanks
[06:57] <pitti> Good morning
[07:28] <pitti> TheMuso: bug 396377> "Use the ubuntu-bug force, Luke!" :-)
[07:28] <pitti> TheMuso: (need lshal output at least)
[07:29] <pitti> is it just me, or did the "reading database..." dpkg step recently became much, much, much slower?
[07:30] <pitti> it took like 2 seconds in the past, and now it takes 20
[07:32] <TheMuso> pitti: I thought that would have been included in the bug, but ok I'll attach it.
[07:32] <pitti> TheMuso: thanks
[07:44] <nellery> pitti: yea it's taking significantly longer for me too
[07:50] <ebroder> pitti: Finally got a chance to test my fix for bug #393376
[07:50] <ebroder> 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] <cjwatson> 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] <cjwatson> billybigrigger: (I've added a bit to https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Publishing about that)
[08:25] <billybigrigger> cjwatson, thanks for the info
[09:03] <pitti> 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] <tjaalton> pitti: yes, upstream broke it
[09:03] <pitti> tjaalton: the alias stuff doesn't work?
[09:04] <tjaalton> pitti: here's how it was fixed: http://cgit.freedesktop.org/xkeyboard-config/commit/?id=fd7fa190c4f817bacac23c98e43c61b60064bffd
[09:05] <tjaalton> the special models were all removed (ABNT2, jp106..)
[09:05] <tjaalton> that's why it broke
[09:06] <pitti> ok, thanks for confirming
[09:08] <pitti> stvo: hey
[09:22] <ion> 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] <cjwatson> XDG configuration--
[09:26] <cjwatson> stupid idea
[09:27] <liw> cjwatson, what's that?
[09:27] <pitti> ion: I also said that on a followup to ubuntu-devel@
[09:27] <cjwatson> the dumb ~/.config/ thing
[09:27] <pitti> cjwatson: why is that dumb?
[09:27] <cjwatson> dotfiles are hidden for a reason; dumping them in a subdirectory achieves nothing and creates complexity
[09:27] <pitti> dotfiles are a pain
[09:27] <pitti> I wish they had used ~/.etc/ fourty years ago
[09:28] <liw> cjwatson, and yet, having yet another dotfile is not good, either
[09:28] <pitti> for consistency, and not cluttering your home dir with a wild mix of cache, config, and data files
[09:28] <liw> (.hush_login ftw)
[09:28] <cjwatson> moving cache and data, I agree. but it's silly for configuration.
[09:28] <pitti> ion: I proposed ~/.cache/motd/legal-shown , or something
[09:28] <cjwatson> (and, OK, this particular example is a cache)
[09:29] <cjwatson> 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] <dupondje> heh :) seems i'm not alone with the nasty gdm bug :(
[10:33] <pitti> Keybuk: just to avoid double work, did you do any getty investigations so far? Just starting to look at the code now
[10:34] <Keybuk> pitti: no, I don't think there's any possibility that way
[10:34] <Keybuk> I found lots of other bugs too
[10:34] <Keybuk> if you don't start with splash, you can end up with X on vt2
[10:34] <Keybuk> so it just ends up going random
[10:35] <Keybuk> the fix really needs to go into X or gdm
[10:35] <pitti> okay
[10:36] <pitti> good to know, then I don't waste time on getty, and instead coerce gdm to start on vt7
[10:37] <Keybuk> it does bring up interesting points about how we should deal with all this
[10:37] <Keybuk> if X is starting on the "first unused tty"
[10:37] <pitti> Keybuk: I don't think I'd like to fix it in X itself
[10:37] <Keybuk> while getty is starting on hardcoded ttys
[10:37] <Keybuk> you're always going to end up with X and getty trying to share in some corner case
[10:37] <Keybuk> especially with the racey async start
[10:37] <pitti> well, I thought about adding an option to gdm-binary
[10:37] <pitti> like --tty 7
[10:37] <Keybuk> I think X's code is right
[10:38] <Keybuk> in that it can be passed a hardcoded vt, or looks for one itself
[10:38] <pitti> so that we can equally hardcode the gdm vt just as we hardcode the getty ttys
[10:38] <Keybuk> I was wondering whether getty shouldn't have the same code ;)
[10:38] <pitti> Keybuk: X rightX> I agree
[10:38] <ogra> why cant we hardcode getty to tty2 ?
[10:38] <Keybuk> ogra: because if you start from single-user mode, you'll have a shell on tty1
[10:38] <ogra> and leave 1 untouched
[10:38] <Keybuk> ogra: so X will then pick tty2 as "the next unused", and thus conflict with getty again
[10:38] <cjwatson> buys us nothing over leaving it on tty7
[10:38] <cjwatson> (putting it on tty2)
[10:39] <cjwatson> oh, sorry, you said getty on tty2 not X on tty2
[10:39] <Keybuk> we either need to hardcode X's vt
[10:39] <cjwatson> ignore me
[10:39] <ogra> i meant pushing the gettys al to tty2
[10:39] <Keybuk> or we need to stop hardcoding getty's
[10:39]  * ogra would vote for the latter
[10:39] <Keybuk> it occurred to me that it'd be kinda cute for desktops to start "a number of gettys"
[10:39] <Keybuk> and for it to just automatically find unused vts for them
[10:39] <Keybuk> servers would end up 1-6
[10:39] <Keybuk> desktops may end up 2-7
[10:40] <pitti> 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] <ogra> does it really *need* to be on tty1 ?
[10:41] <Keybuk> pitti: except that there's no way to tell that a tty is "taken" or not, annoyingly
[10:42] <Keybuk> ogra: I'm trying to avoid a fix that involves us discovering yet more corner cases for the next hundred years
[10:42] <Keybuk> pitti: we can ask for the "next free vt", but that's it
[10:43] <pitti> Keybuk: ok
[10:43] <pitti> seems it'd be best to add that "vt" argument to gdm for the time being, since that bug is nasty
[10:43] <Keybuk> pitti: the more I think about it, the more I like having a simple "number of gettys" option
[10:43] <Keybuk> yeah
[10:44] <pitti> Keybuk: so, "/sbin/getty -8 38400 tty1" -> "tty-auto"?
[10:44] <pitti> and call that 6 times?
[10:44] <pitti> that would be great indeed, and avoid these races
[10:45] <Keybuk> pitti: exactly
[10:49] <Keybuk> exec openvt getty -8 38400 -
[10:49] <Keybuk> would do it ;)
[10:50] <Keybuk> might be better to patch getty though
[10:50] <slangasek> 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] <Keybuk> slangasek: your login sessions will be on 1-7
[10:51] <Keybuk> just X might be on 1
[10:51] <Keybuk> in fact, X would be on 1 most likely
[10:51] <slangasek> yes, so CTRL-ALT-F1 may or may not get you to a getty
[10:51] <Keybuk> slangasek: it won't
[10:51] <Keybuk> it already doesn't on Fedora and SuSE
[10:52] <slangasek> no, it *may or may not*, the whole reason you're even discussing these changes is because it's racy...
[10:52] <Keybuk> slangasek: not racy, that it depends on what else you do on the way up
[10:53] <ogra> isnt X supposed to be up long before the gettys in the new model ?
[10:53] <slangasek> if it's asynchronous, what guarantees that X has succeeded in being brought up yet?
[10:54] <ogra> and cant upstart handle them conditional based on runlevel and if X is up ?
[10:54] <Keybuk> 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] <Keybuk> ogra: because we can't predict which vt(s) X will take, you can't just have Upstart disable the right getty
[10:54] <ogra> thats not waht i meant
[10:55] <ogra> you just said above "exec openvt getty -8 38400 -" would make gettys start in first available tty
[10:55] <Keybuk> available vt, but yes
[10:56] <Keybuk> conflating vts and ttys is one of those "but they're the *same* ... well, ok, almost the same" issues
[10:56] <ogra> 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] <Keybuk> ogra: that would be the case, yes
[10:56] <ogra> so X always owns tty1
[10:57] <Keybuk> not necessarily ;)
[10:57] <Keybuk> boot into single-user mode
[10:57] <Keybuk> muck around a bit
[10:57] <ogra> right
[10:57] <Keybuk> then telinit 2
[10:57] <Keybuk> your sulogin will be on tty1
[10:57] <Keybuk> you may have (one of my favourite tricks) started other gettys while in single user mode
[10:57] <ogra> but thats a corner case where bootspeed doesnt matter
[10:57] <ogra> at least for X
[10:57] <Keybuk> that's not a speed issue, that's just showing that there's a case where X might end up on vt3
[10:57] <Keybuk> and the further console gettys on vt4+
[10:58] <Keybuk> boot with single, start another getty, telinit 2, now X is on vt3 (first available)
[10:58] <ogra> right but single user mode means something went wrong already or you are a evil hacker anyway
[10:58] <Keybuk> ogra: I usually assert that caring about getty means that too ;)
[10:59] <ogra> well, "fix" single user mode to always start its getty on tty2 ... hardcoded
[10:59] <ogra> so X will be on 1
[10:59] <ogra> and subsequent ones on 3-7
[10:59] <liw> do not annoy the evil hackers, or they will replace your tty1 with a very small x
[10:59] <ogra> lol
[11:00] <Keybuk> ogra: that fix doesn't work, if you switch user, where does *that* X work
[11:01] <Keybuk> there's two options
[11:01] <ogra> where does it work if you are in a normal boot ?
[11:01] <Keybuk> 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] <ogra> tty8 by default i'D guess
[11:01] <Keybuk> that's what we've always done before, since getty has been hardcoded since the DAWN OF TIME
[11:01] <Keybuk> and old gdm pretty much hardcoded X's VT allocation
[11:01] <Keybuk> or
[11:02] <ogra> right but today we only have one case where it *has to be* hardcoded
[11:02] <Keybuk> 2) we do all vt allocation on the fly
[11:02] <ogra> right 2 was what i proposed
[11:02] <Keybuk> 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] <ogra> but with the exception to handle it specislly in the special case of single user mode
[11:02] <Keybuk> slangasek: I'm going to guess you prefer #1 since then you know what C-A-F1...F7 all do?
[11:03] <Keybuk> ogra: if we just do it all on the fly, single user mode doesn't matter
[11:03] <ogra> it does
[11:03] <Keybuk> why?
[11:03] <ogra> you just explained it to me
[11:03] <ogra> because your tty will be 1 by default
[11:03] <ogra> so X starts on 2
[11:04] <slangasek> Keybuk: I think I'm in favor of 1) except for the "we'll have to maintain it" part ;)
[11:04] <ogra> if you hardcode it in single user to 2 your X is predictable on tty1 all the time
[11:04] <slangasek> but yes, predictability is pretty important to me
[11:04] <ogra> and your subsequent gettys fill up until tty7
[11:04] <ogra> if you switch user your gdm is predictable on tty8
[11:05] <ogra> (if we even want 7 gettys at all that is)
[11:14] <ogra> yeah, felt pretty lonely for a moment
[11:40] <taavikko> 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] <bluefoxicy> how many of the developers live on x86-64?
[11:57] <liw> 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] <slangasek> liw: correct; the release pocket is pseudo-immutable once the release is done
[11:58] <liw> 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] <slangasek> yes
[11:58] <liw> thanks
[11:58] <slangasek> or simply hardy-updates, if you don't mind a little lag
[11:59] <liw> oh, stuff in hardy-security gets moved to hardy-updates?
[11:59] <liw> or copied?
[11:59] <slangasek> copied
[11:59] <liw> ok, thanks
[12:00] <slangasek> 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] <Keybuk> tests/test_initctl.c:3198: error: variable ‘reply’ might be clobbered by ‘longjmp’ or ‘vfork’
[12:10] <Keybuk> now there's a new warning on me
[12:12] <Keybuk> I wonder what the hell it means
[12:12] <liw> Keybuk, which one are you using?
[12:13] <Keybuk> liw: longjmp
[12:14] <ogra> and you gave it a club on its way, you evil guy :)
[12:15] <liw> Keybuk, can I have a look at the code?
[12:16] <Keybuk> liw: you can, but it won't help very insightful :)
[12:16] <liw> http://pastebin.ubuntu.com/213555/ is what the C99 standard has to say about variable values
[12:17] <Keybuk> http://bazaar.launchpad.net/%7Escott/upstart/trunk/annotate/head%3A/util/tests/test_initctl.c#L3327
[12:17] <Keybuk> is one example
[12:18] <Keybuk> I think I had a lot more code in the signal handler once
[12:18] <Keybuk> in the sigsetjmp() if I mean
[12:18] <Keybuk> and now I can replace the whole thing with just calling _exit(0) in the signal handler :p
[12:21] <liw> 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] <slangasek> your English?  What does the spin on a cue ball have to do with anything?
[12:23] <liw> my interpretation of the Englished used in C99, which, admittedly, makes my head spin luke a cue ball in billiards
[12:23] <slangasek> ahh
[12:25] <liw> er, s/shed/sh/
[12:40]  * ogra wonders why he gets QA tracker mails
[12:41] <Keybuk> of course
[12:41]  * cjwatson guesses 8.04.3
[12:41] <cjwatson> (tracker)0
[12:41] <Keybuk> _if_ we use dynamic gettys, we finally have a reason for KDSIGACCEPT
[12:41] <Keybuk> Alt-UpArray = "give me another getty"
[12:42] <ogra> cjwatson, oh, right, forgot about hardy, thanks
[12:44] <Keybuk> array? arrow!
[12:44] <ogra> would that work from a hung up terminal too ? (as long as the kernel isnt hung)
[12:45] <Keybuk> ogra: yes
[12:45] <ogra> neat
[12:45] <Keybuk> it's built into the kernel at the same layer as Alt-F1
[12:45] <Keybuk> it just sends init SIGWINCH rather than any other processing
[12:46] <ogra> cool, lets add it :)
[12:46] <ogra> and go with a single getty ... saves ram as well :)
[12:55] <seb128> pitti, slangasek: the gvfs smb issue seems to be due to samba somewhat
[12:55] <seb128> pitti, slangasek: I rebuilt the glib and gvfs intrepid-updates versions on hardy and it still doesn't work
[12:55] <seb128> so I guess it's the hardy samba behaving differently but I've no clue about samba
[12:57] <slangasek> oh, interesting
[12:58] <slangasek> 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] <slangasek> seb128: are you sure it's samba, rather than nautilus, that is the added culprit?
[12:59] <seb128> slangasek, I'm testing with gvfs-ls smb:
[12:59] <seb128> slangasek, and it has the same issue
[12:59] <slangasek> ok
[13:00] <slangasek> hmmm, that sounds like a good non-GUI test case; perhaps I can do some useful chroot testing here
[13:02] <pitti> perhaps it would be worth building intrepid's samba on hardy and check if that fixes the regressin?
[13:02] <slangasek> "Error: Operation not supported"
[13:02] <slangasek> well, that's unhelpful
[13:02] <slangasek> pitti: indeed
[13:02] <pitti> but either way, I guess we need to find a workaround in hardy's gvfs
[13:02] <pitti> since it's quite impossible to move intrepid's samba to hardy
[13:03] <slangasek> if it turns out to be a samba bug, I have no problem hunting down the change
[13:03] <seb128> pitti, or find the samba change or fix required to make it work
[13:03] <pitti> seb128: right
[13:03] <seb128> would rebuilding the intrepid samba or hardy be useful in some way?
[13:06] <slangasek> to confirm that it's a change in the samba source that's to blame, yes
[13:06] <slangasek> seb128: any idea why I get this 'Operation not supported' from gvfs-ls smb://?
[13:06] <pitti> is that in a chroot?
[13:06] <slangasek> yes
[13:06] <slangasek> also outside of a chroot, though
[13:07] <pitti> hm, I get "this place isn't mounted"
[13:08] <seb128> slangasek, no, is gvfsd running? do you have a session dbus bus?
[13:08] <seb128> dbus-launch gvfs-ls smb: maybe?
[13:08] <seb128> pitti, gvfs-mount smb:
[13:08] <pitti> slangasek: does "gvfs-mount -l" work?
[13:08] <slangasek> no gvfsd running, I'm in a chroot :)  let me try the dbus-launch
[13:08] <slangasek> pitti: yes
[13:09] <pitti> 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] <pitti> slangasek: gvfs-mount will autostart gvfsd usually
[13:10] <pitti> ps ux|grep gvfs|awk '{print $2}'|xargs kill
[13:10] <pitti> gvfs-mount -l
[13:10] <pitti> -> all monitors and gvfsd are back
[13:13] <seb128> slangasek, pitti: http://paste.ubuntu.com/213580/
[13:14] <seb128> I've that error in the gvfs log
[13:14] <seb128> you can run GVFS_DEBUG_SMB=<level> /usr/lib/gvfs/gvfsd -r
[13:14] <seb128> before starting gvfsd-smb-browser
[13:14] <slangasek> with which combination of packages?
[13:14] <seb128> hardy + intrepid gvfs (and glib)
[13:14] <seb128> I'm trying intrepid smb next but building it takes a while
[13:16] <slangasek> I still don't appear to have things working right in the chroot, so I have no baseline to compare it to
[13:16] <seb128> can't you boot an hardy livecd somewhere?
[13:16] <pitti> $ dbus-launch gvfs-ls smb://
[13:16] <pitti> works for me
[13:16] <slangasek> I don't have a spare machine, and I don't have virtualization
[13:16] <seb128> ok
[13:16] <pitti> slangasek: do you have gvfs-{bin,backends} dbus-x11 installed?
[13:17] <pitti> (in the chroot)
[13:17] <slangasek> pitti: that command /runs/, but it's returning no results
[13:17] <seb128> that would be the bug?
[13:17] <pitti> ah, ok; I didn't get the "operation not supporte" error any more
[13:17] <slangasek> seb128: I'm running the stock hardy-updates packages...
[13:17] <seb128> ah ok
[13:17] <seb128> hum
[13:18] <pitti> smb_tp: jaunty-proposed kernel NEWed FYI
[13:18] <smb_tp> pitti, Ah, ok. the lrm and lbm too?
[13:18] <pitti> smb: will do once built
[13:18] <smb> pitti, Then I upload meta now, so you can accept as soon as they are ready
[13:19] <pitti> smb: cool, thanks
[13:20] <slangasek> 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] <slangasek> heh :)
[13:21] <pitti> [hardy] 0 martin@tick:~
[13:21] <pitti> $ dbus-launch bash
[13:21] <pitti> [hardy] 0 martin@tick:~
[13:21] <pitti> $ gvfs-ls smb:
[13:21] <pitti> WORKGROUP
[13:22] <pitti> ^ 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] <ogra> *umbrella
[13:22]  * pitti installs gvfs from PPA
[13:23] <pitti> ogra: to protect it from the sun?
[13:24] <ogra> ah, you got sun over there ?
[13:24]  * ogra is envious
[13:24] <pitti> yes
[13:25] <pitti> seb128, slangasek: so I think I reproduced that in a chroot
[13:26]  * pitti adds to bug
[13:28] <seb128> pitti, slangasek: how can I browse a workground or available workgroups with smbclient?
[13:31] <pitti> seb128, slangasek: https://bugs.edge.launchpad.net/ubuntu/+source/gvfs/+bug/207072/comments/233
[13:31] <pitti> I think that's the regression you mean, right?
[13:32] <seb128> pitti, yes
[13:35] <hansolo669> hello
[13:39] <slangasek> seb128: smbclient -L <host> -N, where <host> is any known server, will give you a list of workgroups
[13:40] <seb128> ok
[13:41] <seb128> slangasek, "### SMB-BROWSE: do_mount - [smb://; 0] dir = 0x80d43e0, cancelled = 0, errno =" is one difference between intrepid version on hardy and karmic
[13:41] <seb128> the do_mount fails on hardy
[13:41]  * slangasek nods
[13:41] <seb128> and the call before the failure is a smbc_opendir(smb_context, "smb://") one
[13:41] <slangasek> ok
[13:48] <seb128> pitti, slangasek: the intrepid samba installed on hardy doesn't solve the issue ...
[13:49] <slangasek> seb128: does it make a difference if you build the intrepid gvfs *against* the intrepid libsmbclient-dev?
[13:50] <seb128> slangasek, building, one minute
[13:56] <seb128> slangasek, works with gvfs intrepid built with the libsmbclient from intrepid
[13:56] <seb128> pitti, ^
[13:56] <seb128> ie the gvfs from intrepid starts working once rebuilt with new samba
[13:57] <pitti> seb128: is that true for hardy PPA built against libsmb from intrepid?
[13:57] <seb128> that starts being complicated
[13:58] <seb128> hardy + intrepid-updates gvfs built with hardy samba + intrepid samba = breaks
[13:58] <seb128> hardy + intrepid-updates gvfs built with intrepid samba + intrepid samba = works
[13:58] <pitti> it could be that the newer libsmb versions allow calls which didn't work yet in the hardy samba version?
[13:58] <pitti> (client-side, I mean)
[13:58] <seb128> could be, ENOCLUEABOUTSAMBA
[13:59] <slangasek> seb128: how about hardy + hardy-ppa gvfs built with intrepid samba? :)
[13:59] <pitti> right, what I meant
[13:59] <slangasek> (sorry, *still* don't have the test case working here :(
[13:59] <slangasek> )
[14:01] <seb128> slangasek, trying that, building
[14:04] <seb128> pitti, slangasek: hardy-ppa version built on intrepid samba works
[14:05] <slangasek> great!
[14:05] <pitti> so, so apparently the gvfs patch uses some feature from libsmb* which isn't available in hardy yet?
[14:05] <slangasek> that means if I can just get a test case, I can take samba apart
[14:05] <pitti> slangasek: which step fails for you?
[14:06] <slangasek> pitti: getting a workgroup list with the hardy-updates version still fails for me
[14:06] <slangasek> so I don't have a baseline to compare with
[14:07] <pitti> strange
[14:07] <pitti> 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] <slangasek> honestly, it's probably a network config problem at this point
[14:08] <pitti> I have /proc, /tmp/, /home, and /sys bind-mounted in my chroots
[14:08] <pitti> perhaps that's it
[14:08] <slangasek> no, I have that too (standard schroot)
[14:08] <praveen1>  wow
[14:08] <praveen1> sorry wron chan
[14:09] <pitti> slangasek: local samba server or remote? (I just tested with apt-get install samba locally)
[14:09] <slangasek> pitti: remote
[14:09] <slangasek> 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] <slangasek> (workgroup bit rot)
[14:11] <pitti> slangasek: so that also happens with doing nautilus or gvfs on your normal system, not just the chroto?
[14:11] <slangasek> no
[14:11] <slangasek> the chroot isn't on my desktop
[14:11] <pitti> ah
[14:11] <soren> A chroto? I've always wanted a chroto.
[14:12] <pitti> soren: they are really cool
[14:12] <soren> pitti: So I hear.
[14:12] <pitti> soren: you have to feed them well, thuogh
[14:12] <pitti> argh tpying is hrad
[14:12]  * pitti fixes finger ordering
[14:13] <ogra> did chrotos geat cheaper recently ? last time i looked they were still unaffodable
[14:14] <soren> ogra: I borrowed a chroto from a friend once, but it accidentally my whole keybaord.
[14:15] <pitti> soren: and your verbs
[14:15] <ogra> lol
[14:15]  * ogra was about to type the same :)
[14:16] <soren> What do you mean? It accidentally my *whole* keybaord. It was crazy!
[14:17] <cjwatson> pitti: it's important that your middle finger goes between your index and ring fingers
[14:17] <ogra> no ! really ?
[14:17] <cjwatson> if you get confused your hands look really weird
[14:18] <soren> ogra: Yeah! You need to be careful. If you don't pay attention, it'll your mouse and maybe monitor too.
[14:18] <pitti> 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] <soren> http://www.fohguild.org/forums/attachments/screenshots/87340d1220554030-funny-strange-random-pics-2db6wiw.png
[14:19] <ogra> soren, thats scary ... i'll reconsider one
[14:19] <cjwatson> I could never cope with those keyboards
[14:19] <pitti> oh, nice, on that photo I still had my good ol'd iBook G4
[14:20] <pitti> cjwatson: takes a while to get used to, but I'd never give it away any more
[14:20] <ogra> there are fully equipped keyboards too http://upload.wikimedia.org/wikipedia/commons/7/71/200801191443_Japanische_Tastatur.jpeg
[14:20] <pitti> ... pretty much like vim
[14:20] <ogra> these 104/5 keys really dont cut it
[14:20] <pitti> c'mon bloddy gdm, work now
[14:33] <praveen1> which version gdm will be used .26 or .27 series?
[14:33] <seb128> praveen1, there is no .27
[14:34] <praveen1> seb128: oho
[14:34] <praveen1> k
[14:36] <seb128> pitti, slangasek: ok, gvfs is trying to do some clever things on old samba and that code might be broken
[14:37] <slangasek> seb128: ah
[14:39] <seb128> pitti, slangasek: there is a libsmb-compat.h
[14:39]  * slangasek nods
[14:39] <seb128> typedef SMBCFILE * (*smbc_opendir_fn)(SMBCCTX *c,
[14:39] <seb128>                                       const char *fname);
[14:40] <seb128> it tries to do some mapping of functions for old samba versions
[14:41] <seb128> not sure if that's buggy somewhere, I guess nobody really used that
[14:41] <seb128> fedora already had the new samba by this time
[14:45] <slangasek> right; got my test case sorted finally
[14:45] <hile> this is one very funny mod for that keyboard: http://samchillian.com/aboutsam.html
[14:45] <hile> (a midi controller)
[14:45] <slangasek> (it was a network problem, and an annoying one; NAT+WINS == FAIL)
[15:02] <praveen1>  is there any blueprint or list of things being done to reduce power consumption in karmic?
[15:04] <mterry> cjwatson, evand, I'm looking at the oem-config spec, and thinking about the 'translated timezones' item.  This strikes me as something upstream tzsetup wouldn't be excited about, since they have their own 'translated timezone' method that involves picking the country first.  Would we be willing to carry such a large translation delta?
[15:05] <cjwatson> IMO only if it isn't actually a source delta - that is, the translations are all automatically sourced from somewhere else
[15:05] <cjwatson> might be worth giving a bit of consideration to memory consumption as well
[15:06] <mterry> cjwatson, hrmm..  last time I looked at this, I don't believe I found a source of translations for these already.  I'll search again to see if there's an existing body of translation work we could steal
[15:06] <mterry> cjwatson, yeah, hopefully we could only load the translations we need
[15:09] <mterry> cjwatson, what if we changed the drop down from 'Region'/'City' to 'Country'/'Timezone'.  Then we could use the upstream method of showing translated timezones in the second combo if available, else all timezones
[15:10] <mterry> There'd be a bit of disconnect between the map and the bottom then.  in one you pick city, in the other timezone.  But I think picking timezone is more intuitive (and translated), so maybe it's a usability wash
[15:20] <seb128> pitti, slangasek: not sure if that's useful: http://people.ubuntu.com/~seb128/smb.c
[15:21] <seb128> that's a tentative testcase to do a similar to gvfs opendir
[15:22] <seb128> gcc smb.c -o smb -lsmbclient to build
[15:22]  * mvo libudev == ❤
[15:22] <seb128> the call does success on samba intrepid but not on hardy
[15:23] <seb128> the testcase might be buggy though since I don't really understand all those smbc_* are working
[15:23] <seb128> mvo, oh? ;-)
[15:23] <mvo> seb128: I'm playing with it for more dynamic cdrom support in libapt and its pretty cool
[15:26] <kees> pitti: hi! is the apport-handles-assert feature still on your schedule for karmic? do you need anything from me for it?
[15:30] <cjwatson> mterry: only works if you can select both country and timezone; timezone alone doesn't imply country
[15:30] <cjwatson> mterry: I think I'd prefer to continue to say "region" rather than "country"; avoids disputes about exactly what counts as a country
[15:36] <mterry> cjwatson, I agree about name of 'region'.  But I'm saying, replace the 'Region' dropdown with a new 'Region' dropdown that actually shows Countries.  Then the City drop down shows Timezones (ideally a translated list of only the timezones in that country)
[15:37] <mterry> cjwatson, This would dovetail beautifully with the request to add country highlighting to the map
[15:37] <mterry> cjwatson, We can drop the city concept altogether, which has caused no end of bug reports
[15:37] <mterry> cjwatson, and we pick up translation to boot
[15:38]  * mterry is excited about this idea
[15:53] <cjwatson> mterry: yes, although I think we should probably display all timezones in the drop-down, just with the ones in the region you selected sorted to the top, and maybe a separator
[15:53] <cjwatson> mterry: and then have that feed back into the region drop-down if it doesn't match ...
[15:54] <cjwatson> it's a little more complex that way but I think it'll work better
[15:54] <mterry> cjwatson, I could buy that.
[15:54] <cjwatson> mterry: the timezone does need to come out under the hood as the city identifier, though
[15:54] <cjwatson> otherwise we won't get daylight savings right
[15:55] <mterry> cjwatson, right, which is actually why what you said above is difficult
[15:55] <cjwatson> it is?
[15:55] <mterry> cjwatson, if they pick non-recommended timezone, we don't know region
[15:55] <cjwatson> well, no, that's why I said it should feed back into the region drop-down
[15:55] <mterry> cjwatson, and thus we can't map to a city
[15:55] <mterry> cjwatson, Right, but I'm saying we *can't* feed back into region
[15:55] <cjwatson> why not?
[15:55] <cjwatson> we know the set of regions that overlap a given timezone
[15:56] <mterry> cjwatson, Because picking a different timezone doesn't imply region
[15:56] <cjwatson> it doesn't imply *one* region, but it implies a small number
[15:56] <mterry> cjwatson, ah, and just pick one?
[15:56] <cjwatson> pick one and let them choose if that's wrong
[15:56] <cjwatson> again, sorting the ones that match to the top, perhaps
[15:56] <cjwatson> not denying this'll be a bit tricky
[15:56] <cjwatson> but I'd rather have that than end up with inaccurate DST on people's systems, which is a lot harder to put right later
[15:57] <mterry> cjwatson, Right, definitely we want to end up with a city, just don't tell user that
[15:57] <cjwatson> in some cases the city is going to be better-known than the timezone name, of course
[15:57] <cjwatson> I wonder how many people in central Europe know that their timezone is called Central European Time
[15:57] <mterry> cjwatson, well, that's the beauty of translation.  It uses local names for the timezones, which may be cities
[15:58] <cjwatson> *blink* no!
[15:58] <cjwatson> GMT =/> London
[15:58] <mterry> cjwatson, I haven't looked at all the translations
[15:58] <cjwatson> you can't do this with translation
[15:58] <cjwatson> the point is that some fairly significant group of people will not actually have a clue what timezone they're in and cities may actually be more familiar; which is why it's important to allow selecting those on the map
[15:59] <cjwatson> if you can still select from the map, I'm fine with the drop-down just being actual timezone names
[15:59] <cjwatson> but we should never attempt to translate timezone to city in a gettexty kind of way
[15:59] <mterry> cjwatson, well, you can select region, but the number of people whose city happens to appear in the map is small, eh?  Don't we get bunches of bugs about that?
[15:59] <cjwatson> it's a US thing
[15:59] <cjwatson> IME
[15:59] <cjwatson> people in the US get confused about this, everyone else has no clue what timezone they're in :)
[16:00] <mterry> cjwatson, I wasn't saying timezone->city necessarily.  But tzsetup lists country-specific timezones in a regional way
[16:00] <cjwatson> I've got bug reports claiming that we were presenting the wrong timezone for (say) Bulgaria - actually the submitter was *wrong*
[16:00] <mterry> cjwatson, let me find some examples, though I assume you know them
[16:00] <cjwatson> they knew what city they should select but they were dead wrong about the timezone it was in
[16:01] <cjwatson> I'm aware of how tzsetup does it, yes
[16:01] <cjwatson> translating those is obviously fine
[16:01] <cjwatson> though remember, those timezones are (with the exception of the US) cities
[16:01] <mterry> cjwatson, OK, I assume you have good experience with it.  So map doesn't change, just a drop down change
[16:02] <cjwatson> when you talked about a timezone drop-down, I thought you meant a west/east of GMT kind of thing
[16:02] <mterry> cjwatson, I was talking about whatever tzsetup says
[16:02] <cjwatson> that's pretty much what we present today - cities. Again, with the notable exception of the US
[16:02] <mterry> cjwatson, OK.  But with added lovely advantages of both translation and a smaller list to choose from
[16:03] <cjwatson> of course we got bug reports about needing to select something outside the shortlist for some reason
[16:03] <cjwatson> which is why it now offers "other" as well, and why ubiquity should still offer everything, just with some degree of sorting
[16:03] <mterry> cjwatson, hence your separator suggestion.  So if I go and implement this as we discussed above, it's a Good Thing?
[16:03] <cjwatson> I think so, yeah
[16:04]  * mterry loves it
[16:04] <cjwatson> we'll need to get feedback from people in various locations though
[16:04] <cjwatson> it's a horrifically complicated field :-/
[16:04] <mterry> cjwatson, yeah, I'm definitely too US-centric :)
[16:04] <pitti> kees: oh, I sort of forgot; is there a bug report for it?
[16:05]  * cjwatson is too European-centric, which is why the current overall design doesn't serve the US very well
[16:05] <cjwatson> don't want it to swing too far the other way though ... :-)
[16:05] <pitti> mvo: if you like libudev, you'll love libgudev :)
[16:05] <cjwatson> mterry: it all definitely sounds more sensible than the giant lists we have at the moment, certainly
[16:06] <slangasek> seb128: that test case doesn't seem to behave the same as the gvfs backend, here
[16:06] <slangasek> seb128: e.g., no debugging output...
[16:08] <seb128> slangasek, right, I don't understand why, it does debug on samba3.2
[16:08] <seb128> slangasek, anyway when building with the intrepid samba it print a success
[16:08] <seb128> and on hardy it prints an error
[16:08] <seb128> could be a start point
[16:09] <slangasek> well, I think the test case has a bug in addition to the debugging output
[16:09] <slangasek> gdb'ing gvfsd-smb-browse, I don't see smbc_opendir() returning NULL
[16:09] <slangasek> empty list, yes, but not NULL
[16:09] <seb128> ok
[16:10] <seb128> "### SMB-BROWSE: do_mount - [smb://; 0] dir = 0x8097170, cancelled = 0, errno = [1]"
[16:10] <seb128> the gvfs log shows it fail on a not allowed error
[16:10] <slangasek> no; it's printing the errno on something that's not an error condition
[16:10] <slangasek> dir = 0x8097170
[16:10] <seb128> ok
[16:10] <slangasek> non-null return
[16:17] <mvo> pitti: yeah, that is even cooler, but not suitable for libapt (gobject)
[16:27] <slangasek> seb128: that errno value means the context initialization failed; still working on getting to the bottom of it
[16:27] <seb128> ok
[16:27] <seb128> slangasek, thanks for your help on that my samba knowledge is very limited
[16:28] <ogra> its bigger now :)
[16:28] <slangasek> seb128: well, it's mostly me traipsing through the libsmbclient code at this point :)
[16:29] <slangasek> apparently the problem is that the auth_fn callback is not optional
[16:33] <slangasek> seb128: http://people.ubuntu.com/~vorlon/smb.c
[16:34] <slangasek> but I don't think the auth callback is emulated correctly
[16:34] <tkamppeter> Anyone knows how I can find documentation about how Ubuntu's and/or Debian's package archives are signed, as my GSoC student at OpenPrinting is working on the scripting for the downloadable driver archives at OpenPrinting now.
[16:34] <slangasek> since this is giving 'Server connect ok', which gvfsd-smb-browse does not
[16:35] <tkamppeter> elmo, hi
[16:36] <mvo> Keybuk: do you happen to know if libudev/udev should clear the FSTAB_DIR property when device (cdrom in this case) gets unmounted?
[16:38] <Keybuk> mvo: I don't think so
[16:38] <slangasek> seb128: I'm off for a while; will continue working on this later - don't feel obligated to fight with the samba stuff in the meantime
[16:38] <mvo> Keybuk: thanks, I will ask on #udev then and see if I do something wrong in my code or something
[16:38] <seb128> slangasek, ok, I will catch up with other things now and might have an another look later
[16:39] <mvo> (or if its maybe a bug in udev)
[16:45] <tkamppeter> pitti, hi
[16:59] <pitti> hi tkamppeter
[16:59] <cjwatson> Keybuk: mind if I upload that most recent util-linux patch? it's been accumulating dups
[16:59] <cjwatson> (the lsb_release thing)
[17:02] <Keybuk> sure
[17:03] <Keybuk> I wasn't ignoring it
[17:03] <Keybuk> I'm just knacker-deep in other things
[17:07] <pitti> phew, seems I finally bent gdm to my will now
[17:08] <Keybuk> pitti: can you show us on the bear where gdm touched you? ;o)
[17:08]  * ogra hopes pitti's will matches ours as well :)
[17:09] <pitti> Keybuk: "on the bear"?
[17:09] <pitti> ogra: well, it's "don't start on vt7 initially, d*****t"
[17:09] <pitti> that was surprisingly hard
[17:10] <Keybuk> pitti: vt1 I assume you mean
[17:10] <pitti> I tried some approaches, but ended up with a terrible, terrible hack which I never want to look at any more
[17:10] <pitti> yeah, "do start on vt7"
[17:10] <pitti> Keybuk: this version also migrates autologin settings
[17:11] <ion> Can you show us on the bear where pedobear touched you?
[17:11] <pitti> seb128: so now the remaining regression I'm aware of is the "cannot save session blabla" warning
[17:12] <Keybuk> ooh, my package built
[17:12]  * Keybuk gets excited
[17:13] <ion> keybuk: Upstart trunk deb?
[17:13] <Keybuk> bah, my reboot test was foiled by my own debugging
[17:23] <kees> hm, gdm resolves my homedir path
[17:24] <kees> (i.e. /home/kees is a symlink so launched shells aren't in /home/kees, theylre in the resolve path)
[17:24] <kees> *resolved
[17:25] <kees> hmmm
[17:26] <Keybuk> Subject: 	[ubuntu/karmic] upstart 0.6.0-1 (Accepted)
[17:26] <Keybuk> MUAHAHAHAHAHAHA
[17:28] <Keybuk> pitti: you have a while longer to fix gdm, nobody will notice the breakage while their machines don't boot
[17:29]  * robbiew now stops his update
[17:29] <Keybuk> oh bah, it ftbfs
[17:30] <pitti> Keybuk: haha
[17:30]  * Keybuk thought he timed that right
[17:30] <Keybuk> clearly not
[17:30] <tkamppeter> pitti, what about putting the CUPS 1.4 RC into Karmic so that it gets more intensively tested?
[17:30] <ion> I felt a great disturbance in the Source, as if millions of computers suddenly cried out in terror and were suddenly silenced.
[17:31] <pitti> tkamppeter: dunno, when will Mike release the final?
[17:31] <pitti> tkamppeter: a PPA perhaps, for a start?
[17:31] <tkamppeter> Usually, Mike says when an RC is without problems for two weeks it will get the final.
[17:32] <ion> keybuk: Been playing Monkey Island lately?
[17:32] <Keybuk> ion: no, I've been resolutely *not* playing the new Monkey Island game because I've been trying to finish this release ;-)
[17:34] <pitti> tkamppeter: so, we should do an 1.4 bzr branch, and put it into a PPA for now
[17:34] <pitti> tkamppeter: I guess that might need some time to port anyway (all these filters and our patches)
[17:36] <seb128> do we have anything relying on the gtk directfb backend?
[17:36] <pitti> Keybuk: FTBFS> versioned build deps FTW :)
[17:36] <cjwatson> seb128: d-i's gtk frontend, same as the last seventeen times anyone from the desktop team asked ;-)
[17:37] <seb128> cjwatson, whoever use it will have to start maintaining it that's really an issue
[17:37] <seb128> they rewrote gdk for client side decoration
[17:37] <cjwatson> I've seen Debian people working on it
[17:37] <seb128> but not the directfb backend
[17:37] <seb128> I doubt they will package 2.17 soon though
[17:38] <cjwatson> I don't mind if it breaks for a while in Ubuntu. It's a bit of a myth that nobody is contributing patches for it upstream though
[17:38] <seb128> and I've neither the directfb competences not the free slot required for that and it blocks karmic goals during this time
[17:38] <cjwatson> ditch it in Ubuntu then
[17:38] <seb128> ok thanks
[17:38] <cjwatson> for the time being, though, please
[17:38] <cjwatson> as opposed to permanently
[17:38] <seb128> yeah, bratsche said he can help with that next week
[17:39] <seb128> but I would like to get client side decoration to land soon if possible rather than waiting for directfb to work again
[17:39] <cjwatson> (ps last time somebody complained about nobody contributing to the directfb backend, I looked and there were several patches that had been contributed in upstream bugs but ignored)
[17:39] <mathiaz> james_w: hi - how can I tell if squid already has a bzr package branch in LP?
[17:39] <cjwatson> mathiaz: https://code.launchpad.net/ubuntu/+source/squid
[17:40] <cjwatson> looks as though the importer hasn't got that far yet
[17:40] <james_w> mathiaz: I can do it now for you if you like?
[17:40] <mathiaz> james_w: that would be awesome :)
[17:41] <cjwatson> james_w: BTW I assume the fact that it isn't getting round to updating existing branches is just because you're prioritising new ones?
[17:41] <seb128> cjwatson, what I said previous time is rather than nobody upstream cares about the directfb backend
[17:41] <james_w> cjwatson: yeah, it was
[17:41] <mathiaz> james_w: some posted a debdiff for a debian merge, and I'd like to test the bzr branch/review
[17:41] <seb128> cjwatson, ie they will not work on changes, not bother testing it works and not reviews changes in bugzilla either
[17:41] <cjwatson> seb128: right, but the obvious place for somebody to start addressing that is to contribute patches in bugzilla :)
[17:42] <james_w> cjwatson: I've now imroved the code so that it's easier to do both at once, so it's converging on having existing branches up to date as well
[17:42] <cjwatson> can't magically step up and say "hi, I'm maintaining this now"
[17:42] <tkamppeter> pitti, OK
[17:42] <cjwatson> james_w: no rush certainly, was just curious to see how it would behave after branches have been committed to externally
[17:42] <seb128> cjwatson, right
[17:43] <james_w> cjwatson: ah, that's still not really possible as LP hasn't opened up write access
[17:43] <cjwatson> james_w: oh, heh, of course *I* can ;-)
[17:43] <james_w> mathiaz: it's in the queue, should be picked up in a few minutes
[17:43] <cjwatson> hadn't occurred to me that that was due to magic privileges
[17:43] <james_w> cjwatson: oh, but you would never try to break it on purpose would you? :-)
[17:43] <mathiaz> james_w: great  - thanks
[17:43] <james_w> but I had noticed you had been
[17:44] <cjwatson> james_w: only one or two commits I think
[17:44] <cjwatson> seb128: Sven Neumann committed a bunch of stuff upstream a while back; maybe he can be nudged
[17:44] <cjwatson> (according to http://git.gnome.org/cgit/gtk+/log/gdk/directfb)
[17:45] <seb128> cjwatson, I'm sure we can sort that, bratsche offered to help too now
[17:46] <seb128> cjwatson, the things is that we often hit the case where it blocks standard desktop work and where we need to rely on people to unbreak it to unblock desktop updates and changes
[17:47] <seb128> and I'm wondering if that's worth the annoyance
[17:47] <cjwatson> yeah, as far as I'm concerned temporary disabling there is not a problem
[17:47] <seb128> ok, that's what I wanted to know, thanks
[17:47] <mathiaz> james_w: hm - I don't seem to be able to understand where I can find the link from the +source/package page to the bzr branch
[17:47] <cjwatson> if it breaks, switch it off, it'd just be nice if you could switch it on once it works again
[17:48] <james_w> mathiaz: the code tab at the top will take you to a list of branches
[17:48] <seb128> yeah, I will get it working for karmic, I just wanted to check if we can turn it off to unblock things while it's being worked
[17:48] <james_w> there are just no branches yet :-)
[17:48] <mathiaz> james_w: https://launchpad.net/ubuntu/+source/gnome-colors/
[17:48] <cjwatson> seb128: I'd generally appreciate a note when the state changes, since I have to flip a configuration bit in d-i's build system
[17:48] <mathiaz> james_w: I don't see where the bzr branch is
[17:49] <mathiaz> james_w: while https://code.launchpad.net/~ubuntu-branches/ubuntu/karmic/gnome-colors/karmic exists
[17:49] <james_w> mathiaz: on the code tab at the top of the +source page
[17:49] <mathiaz> james_w: hm - it's greyed for me
[17:49] <seb128> cjwatson, ok, I will keep you updated, bratsche will try to get a patch to make it build today so I will wait tomorrow to see how that goes
[17:49] <cjwatson> great
[17:49] <mathiaz> james_w: there isn't any link for the code tab
[17:49] <james_w> mathiaz: ah, it's just on edge
[17:50] <james_w> mathiaz: it's brand new :-)
[17:50] <mathiaz> james_w: ahhhhh - gotcha
[18:03] <mathiaz> james_w: if I want to use init-repo before branching a pkg, which init-repo option should be used?
[18:03] <james_w> mathiaz: you need a newer bzr than jaunty, are you on karmic?
[18:03] <mathiaz> james_w: the default gives a different rich-root support error while trying to branch
[18:04] <james_w> but you want --2a
[18:04] <mathiaz> james_w: I'm running 1.16.1
[18:04] <james_w> which is "rich-root", and the new fast format
[18:04] <mathiaz> james_w: bzr 1.16.1 on hardy (using bzr PPA)
[18:04] <james_w> apologies for the pain, but it's the future :-)
[18:18] <mathiaz> james_w: how often are unstable/sid packages imported?
[18:18] <james_w> twice a day I think
[18:19] <mathiaz> james_w: hm - lp:debian/sid/nagios-plugins isn't up-to-date
[18:19] <james_w> we just watch for LP importing them
[18:19] <mathiaz> james_w: and the last-upload was on 06 Jul
[18:19] <james_w> https://edge.launchpad.net/debian/+source/nagios-plugins
[18:20] <mathiaz> james_w: hm - http://packages.debian.org/source/sid/nagios-plugins shows the same version as in LP
[18:21] <mathiaz> james_w: but it showed a newer version a couple of minutes ago :/
[18:21] <azeem_> w21
[18:21] <azeem_> oops
[18:23] <james_w> it's on ftp.debian.org
[18:23] <james_w> I've asked in #launchpad
[18:24] <mneptok> uh oh. the GPL is in trouble. Micosoft's new EULA is far easier to understand, and far more liberal.
[18:24] <mneptok> http://www.microsoft.com/windowsxp/eula/pro.mspx
[18:24] <ion> I could agree with that EULA.
[18:27] <mathiaz> james_w: hey - could you also bump drbd8 in the import queue?
[18:27] <mathiaz> james_w: basically I've got 3 debdiff for merges from unstable and would like to play with the ubuntu-branches to see how the workflow would work
[18:28] <james_w> I can't do drbd8 I'm afraid
[18:28] <james_w> it's hitting a bug in pristine-tar apparently
[18:28] <mathiaz> james_w: which means I need both ubuntu and debian unstable bzr branches up-to-date
[18:28] <mathiaz> james_w: ok - fine with me then.
[18:28] <ivoks> what bug?
[18:29] <james_w> it can't recreate one of the .orig.tar.gz
[18:31] <ivoks> i'm sorry for not understanding that completly, but should something be changed in drbd?
[18:32] <mathiaz> ivoks: did you base your DKMSization of drbd on kirkland's kvm backport package?
[18:33] <ivoks> yes
[18:33] <james_w> ivoks: nope
[18:33] <james_w> it's a bug in pristine-tar, though it looks like it's fixed in karmic
[18:33] <james_w> I need to arrange a backport to get around this
[18:33] <ivoks> ok
[19:27] <james_w> mathiaz: squid is up
[19:27]  * james_w heads out
[20:35] <kirkland> pitti: around?
[20:35] <kirkland> pitti: http://pastebin.ubuntu.com/213860/
[20:36] <kirkland> pitti: does that look better to you?
[22:37] <mathiaz> kees: hey - I've got an sbuild failure on karmic for the squid package (works correctly on jaunty): http://paste.ubuntu.com/213951/
[22:37] <mathiaz> kees: ^^ does that ring a bell?
[22:46] <kees> mathiaz: checking...
[22:47] <kees> mathiaz: uhm, no idea.  looks like a dpkg error?
[22:49] <mathiaz> kees: hm yeah - I got the same error while trying to build ipsec-tools.
[23:09] <dupondje> https://bugs.launchpad.net/ubuntu/+source/cdrkit/+bug/149076
[23:10] <dupondje> somebody should really take a look @ this