[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


[01:06] <bschaefer> duflu, hey, figure out that software rendering issue in SDL. Turns out if you set mir_buffer_hardware instead of mir_buffer_software you get a failed to mmap a buffer
[01:06] <bschaefer> i think it started to happen when shm was introduced
[01:06] <duflu> bschaefer: Ah yes, sounds like the right error then :)
[01:06] <bschaefer> duflu, :)
[01:07] <bschaefer> you can get the same error if you change multiwin as well
[01:07] <duflu> I keep thinking we should augment some exception messages like that to describe the most likely cause/mistake
[01:07] <bschaefer> could be helpful, but the area it fails at, im not sure if it knows much about the buffer type
[01:08] <bschaefer> as it happens in: client/mesa/client_buffer.cpp:60:
[01:08] <RAOF> We should make mir_surface_get_graphics_region return an error when called with a hardware buffer.
[01:08] <bschaefer> but there could be a better way to detect, if the surface is set to hardware
[01:08] <bschaefer> and you ask for the region, it should possibly have an error there
[01:08] <bschaefer> yeah
[01:09] <duflu> bschaefer: Yes, that too. "hardware" and "software" are kind of vague words
[01:09] <bschaefer> duflu, just a little :)
[01:11] <duflu> bschaefer: More confusingly "hardware" does not always imply GL. For example, our X drivers render (accelerated) using "hardware" buffers but not GL
[01:11] <duflu> But that's the only exception
[01:13] <bschaefer> duflu, thats interesting, I didn't know that... im not sure how SDL would handle that?
[01:13] <bschaefer> as SDL either uses OpenGL/ES1/ES2/Software
[01:14] <duflu> bschaefer: Yeah that's normal. Only X is weird.
[01:14] <bschaefer> duflu, haha
[01:14] <RAOF> As far as almost all clients are concerned, “hardware” == “Can use OpenGL*”
[01:14] <RAOF> Theoretically you could have something like the cairo-drm backend, though, and that would use hardware buffers without going through GL.
[01:14] <duflu> RAOF: Can we ever use OpenGL on shm buffers? surely...
[01:14] <bschaefer> cool, yeah i hand't taken that into consideration, and defaulted to "hardware buffer"
[01:15] <RAOF> duflu: Yes, we can, if we want to.
[01:15] <RAOF> duflu: Although that'll need some libEGL support.
[01:15] <duflu> RAOF: Your sound's still broken. I give up on the hangout
[01:15] <RAOF> Eh.
[01:15] <RAOF> I didn't think anyone was saying anything?
[01:16] <duflu> RAOF: I think we need that for software rendering anyway
[01:16] <RAOF> Oh, yes.
[01:16] <RAOF> Well, if we want to allow software-rendered GL clients.
[01:16] <duflu> It would also be generally cool to have a fallback buffer sharing mode that works on *everything*
[01:17] <RAOF> Buffer sharing the easy part; the hard part is getting anything on the display :)
[01:17]  * duflu thinks the opposite
[01:17] <RAOF> Howso?
[01:18] <duflu> We should work together
[01:18] <duflu> RAOF: I just know more framebuffer stuff than buffer sharing
[01:18] <RAOF> We've already got a buffer sharing mechanism that works everywhere - shm.
[01:19] <duflu> When it's fixed to work everywhere?
[01:19] <RAOF> It works everywhere now (although doesn't get you GL)
[01:19] <RAOF> (And will never get you hardware-accelerated GL)
[01:19] <duflu> I think we're missing a flag in our buffer messages to tell the client explicitly which to use?
[01:20] <RAOF> Yes; I we assume that the client remembers what it asked for.
[01:20] <duflu> Fortunately we have a flags field in those messages :)
[01:20] <duflu> Although an enum to support N buffer sharing mechanisms might be better
[01:22] <RAOF> Hm, maybe?
[01:22] <RAOF> I don't think that would be particularly helpful; everything but “software” is platform-specific.
[01:25] <duflu> RAOF: Yeah that's enough so long as the type of "hardware" is clarified by the currently loaded client driver-thing
[01:26] <RAOF> And that's what mir_surface_get_platform_type tells you.
[01:51] <memeka> hi all
[01:51] <memeka> I have libhybris installed on an ARM device, test_hwcomposer works ... what else is needed to get mir running?
[01:56] <racarr__> oh sorry forgot
[01:56] <racarr__> the meeting
[01:57] <duflu> racarr__: Yeah twas just RAOF and myself. Nothing happened
[01:57] <racarr__> :)
[01:57] <racarr__> "It was just me and RAOF! NOthing happened I Swear"
[01:57] <racarr__> like a sitcom plot
[01:57] <racarr__> lol
[01:57] <duflu> Nobody in here but us chickens
[01:58] <RAOF> memeka: Have you tried it? That sounds like the major prerequisites :)
[01:58] <memeka> RAOF: not yet... planning to
[01:59] <memeka> just wanted to know what to expect
[01:59] <memeka> XMir probably will not work?
[01:59] <RAOF> XMir will definitely not work.
[01:59] <duflu> memeka: No XMir, but you should be able to compile/run the native Mir demos
[01:59] <memeka> except the demos, is there anything that would run?
[02:00] <RAOF> SDL2 stuff should.
[02:00] <duflu> memeka: You need toolkits to answer that question. So yes, SDL2 and Qt-based apps
[02:00] <duflu> But you have to have the right packages and voodoo
[02:00] <RAOF> memeka: Well, XMir won't work unless your ARM device happens to already have a kms driver, X support, mesa support, and you want to add a little patch to its DDX. :)
[02:01] <memeka> RAOF: so that's a no :)
[02:01] <RAOF> Correct :)
[02:01] <memeka> demos require libgles2-mesa .... can I bypass mesa and use the egl from hybris?
[02:01] <RAOF> They will use the egl from hybris.
[02:02] <memeka> k, so setting the env variables should do it then
[02:02] <RAOF> I think if you've got hybris installed it will already be providing your libGLES2.so.2; we use the alternatives system to delegate stuff like that.
[02:03] <memeka> kwin_gles and konsole should work, right?
[02:04] <duflu> memeka: Native EGL/GLES stuff needs explicit porting to Mir. Just the initialization stuff
[02:04] <duflu> Because you need to create a Mir connection and surface for EGL to run in, and GLES runs in that.
[02:04] <memeka> duflu: i see
[02:05] <duflu> Unfortunately EGL is not sufficiently featured to be a "platform" in itself
[02:06] <memeka> duflu: so that's why the egl tests fail :)
[02:06] <duflu> RAOF: So it seems 1hz needs much porting
[02:06] <memeka> only hwcomposer test actually runs
[02:06] <RAOF> duflu: Yes indeed.
[02:06] <duflu> Plus all the other proposals :P
[02:07] <RAOF> duflu: I'll be doing that shortly, once the FrameDroppingPolicy
[02:07] <memeka> duflu: and where is the init stuff done? :D
[02:08] <duflu> mememka: A good example is in the Mir source. This sets up enough of Mir for an EGL app to use it: http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/examples/eglapp.c
[02:11] <memeka> right, so this is when you want to start an EGL app
[02:11] <memeka> this does not mean that kwin_gles needs to be patched as well, does it?
[02:13] <memeka> duflu: thx for the link
[02:15] <memeka> duflu: hmm.. the exmaples there have a demo shell and window manager ... so I guess kwin_gles will not work...
[02:25] <duflu> memeka: It's not a real shell or window manager. They're just class names. You can still run anything on top of that.
[02:25] <RAOF> memeka: Correct. kwin is fundamentally an X11 window manager. Making it work with Mir will require you to turn it into a Mir compositor.
[02:27] <memeka> my impression was that you need android /system + libybris + mir and it should work out-of-the-box with e.g. unity 8
[02:29] <memeka> RAOF: yes I forgot kwin is not mir compositor :P
[02:30] <memeka> so for unity8 + apps like konsole, there shouldn't be anything to code
[02:30] <memeka> while for EGL apps you just need to make them Mir clients
[02:30] <RAOF> As long as konsole doesn't use any X11-only calls.
[02:31] <RAOF> Apparently lots of KDE apps _do_ use X11-only calls (and are now adding Wayland detection, so they'll make X11-only or Wayland-only calls depending on environment variables. Woot!)
[02:32] <RAOF> This seems to me to be a sub-optimal solution over, say, adding support in Qt to abstract these interfaces, but who am I to judge? :)
[02:32] <memeka> I see...
[02:34] <memeka> thanks for the answers...
[02:36] <RAOF> But there shouldn't be _significant_ work required to get, say Konsole to run under a Mir compositor.
[02:37] <duflu> Is there a nice software-blitting console app we should aim to port first?
[02:38] <RAOF> There's kmscon - http://www.freedesktop.org/wiki/Software/kmscon/
[02:41] <RAOF> That actually gets us both software and GLES2-accelerated rendering.
[02:43] <duflu> RAOF: Sounds a little too tied to KMS/DRM
[02:44] <RAOF> Also supports wayland.
[02:44] <RAOF> Though a fork, perhaps.
[02:45] <RAOF> See also, http://www.freedesktop.org/wiki/Software/kmscon/wlterm/
[08:06] <RAOF> And with that Qt Creator lock up, it's EOD for me!
[10:12] <duflu> Wow, throwing and catching exceptions is exceptionally slow. I can actually see the difference on screen :(
[14:44] <asac> racarr__: hey, do you know if stgraber ended up being able to get something going with the lxc container thingy last week?
[16:14] <racarr__> asac: I never heard back
[16:21] <asac> kk
[16:21] <asac> thanks racarr__
[19:57] <AlbertA> kgunn: so I have a branch for compatibility changes to 0.2.0 for unity-mir , do I push this devel now I suppose? what is the workflow now?
[19:58] <AlbertA> kgunn: compat to next revision of mir
[19:58] <kgunn> AlbertA: yes...that would make sense, and _should_ end up giving you a binary in staging
[19:59] <AlbertA> kgunn: how does that work? Just pushing the branch gives you a binary? or after it's merged?
[19:59] <kgunn> the recipes used for unity-mir & papi now use their respecitive devel branches for daily builds
[19:59] <kgunn> https://launchpad.net/~mir-team/+archive/staging
[20:00] <kgunn> you can see here now, papi is failing too...
[20:00] <kgunn> https://launchpad.net/~mir-team/+archive/staging/+build/5971411
[20:00] <kgunn> i assume for the same change ?
[20:02] <AlbertA> ah I see, so basically a compat branch with the debian ver bump should be enough and the next daily build will just pick it up
[20:02] <AlbertA> so it builds against mir devel ?
[20:04] <AlbertA> kgunn: it looks like papi devel is behind trunk
[20:04] <AlbertA> kgunn: or am I reading that wrong
[20:05] <kgunn> AlbertA: well...it shouldn't be, but lemme check
[20:06] <kgunn> yeah...
[20:06] <kgunn> you're right
[20:06] <kgunn> but i guess its just because we've not really tried to commuicate the change in way of working
[20:07] <kgunn> (ci just got going on thurs last week...)
[20:07] <kgunn> AlbertA: also...we need to do this on u-s-c too
[20:08] <kgunn> e.g. there is no u-s-c dev branch
[20:08] <kgunn> atm
[20:08] <AlbertA> kgunn: ok
[20:09] <AlbertA> kgunn: so until that's in place, you can't really build agains mir devel then I suppose
[20:09] <kgunn> right... AlbertA, i'll put one up and see if i can get francis to enable ci on it
[20:20] <kgunn> AlbertA: so for papi-devel, i just merged trunk...but was that really the right way to do it ?
[20:20] <kgunn> i feel its wrong somehow...
[20:20] <AlbertA> kgunn: for this one time yes, to sync them up
[20:20] <kgunn> yeah...
[20:20] <kgunn> i suppose in the future
[20:20] <AlbertA> kgunn: then after this devel should be merged to main
[20:20] <kgunn> the right way would be indy MP's per change just retargeted
[20:20] <AlbertA> kgunn: for the rest of the MP's coming in
[20:21] <AlbertA> kgunn: I see to keep a visible history?
[20:22] <kgunn> exactly
[20:22] <kgunn> AlbertA: ...but not sure how to achieve it ?
[20:22] <AlbertA> you can merge individual revisions from the other branch
[20:23] <kgunn> hmmm AlbertA how to undo what i did?...local bzr revert, then push ?
[20:24] <AlbertA> kgunn: but hold on...I think bazaar does keep history just ...doesn't display it
[20:24] <AlbertA> kgunn: so maybe you don't really want that? it may complain about criss-cross merging
[20:24] <AlbertA> kgunn: in the future when merging from devel to main
[20:25] <kgunn> this would be simpler is trunk were....ah never mind
[20:25] <AlbertA> kgunn: maybe just copy the commit messages to the merge commit?
[20:25] <kgunn> AlbertA: actually...its ok, from the perspective that trunk (release) reflects the right history
[20:26] <kgunn> its only devel which will have a "merged from trunk" item
[20:26] <kgunn> which is totally sensible i think
[20:26] <AlbertA> kgunn: yeah
[20:26] <kgunn> ok..feels slightly less wrong
[20:39] <kgunn> fginther: hey, hope you're well, could you help us out by setting up ci to run ~mir-team/unity-system-compositor/development-branch
[20:39] <kgunn> just like it does for u-s-c's trunk ?
[20:40] <fginther> kgunn, I can actually get to that right now
[20:40] <kgunn> fginther: once that's done, we'll be totally switched onto dev branches
[20:40] <kgunn> cool
[20:55] <racarr__> kgunn: EVerything has dev branches now?
[20:57] <racarr__> that are intended to always build against mir devel
[20:57] <racarr__> ?
[20:57] <kgunn> yes...in the process of writing a mail :)
[20:59] <racarr__> yay
[21:42] <fginther> kgunn, the ci job is ready now
[21:42] <kgunn> fginther: thanks!


[13:49] <BluesKaj> Hiyas all
 Hello
[21:37] <valorie> hey ahoneybun
 heyo valorie
[21:38] <valorie> I sorta hate telegram, yet I've been using it for years
[21:38] <valorie> I find it useful when traveling
 It's fairly nice.
 I mean we could just have Matrix though I can't seem to log into my account anymore.
 Plus we would need a bot


[11:26] <jtheuer> I want to sign the newly generated ssh host keys (obviously between key generation and sshd start) -- how could I do that with cloud-init?
[13:18] <smoser> jtheuer, wouldn't you need to have access to the signing private key on the instance ?
[13:19] <smoser> natorious, as much as possible, yeah. that would be the case.
[13:43] <jtheuer> smoser, yes, I would need the key but fetching it isn't the difficult part.
[14:06] <openstackgerrit> Scott Moser proposed stackforge/cloud-init: LICENSE: correct wording with respect to Apache 2  https://review.openstack.org/228471
[14:32] <larsks> Merging: can I specify cloud_final_modules in usedata and have it *merge* with whatever the defaults are in /etc/cloud/cloud.cfg? I think I recall recently talking to smoser about this and the answer was "no", but I forget...
[14:33] <smoser> well, you can . but "merge" is sucky for lists by default.
[14:33] <smoser> as for lists, merge is just 'replace'
[14:33] <smoser> you can manage to prepend or append with cloud-config-jsonp
[14:34] <larsks> Actually, I think that may not be true.  I found our prior conversation, in which you saidL
 it appears that you cant patch builtin config
 you can re-define the whole list though
[14:34] <smoser> yeah.
[14:34] <smoser> :-(
[14:34] <larsks> Yeah.  No worries. I knew we had talked about it recently.
[14:34] <smoser> probably thats right. i do recall that conversation.
[14:35] <smoser> jtheuer, you could probably manage to write a upstart job that would do it. (or systemd job)
[14:35] <smoser> and have a bootcommand write the upstart job
[14:35] <smoser> have that start on starting sshd
[14:36] <smoser> and it could pull your keys (i'm guessing from a https:// do the sign and destroy the keys)
[14:36] <smoser> or you coudl have a key signing post service that it could post to that you'd give it one time use url
[14:37] <jtheuer> smoser, I currently do it in runcmd but then also needs an ssh restart. But if there is no clean way to do it between key creation and ssh start I'm fine with that.
[14:37] <smoser> you should be able to write systemd or upstart jobs that start on starting ssh
[14:37] <smoser> and do it there.
[14:37] <jtheuer> I would to do it *before*
[14:37] <smoser> well, 'starting' is before
[14:38] <jtheuer> hmm, didn't know that... !
[14:38] <jtheuer> thanks for the pointer
[14:38] <smoser> starting(7)
[14:38] <smoser> starting - event signalling that a job is starting
[14:39] <smoser> jtheuer, http://manpages.ubuntu.com/manpages/trusty/man7/starting.7.html
[14:39] <smoser> that is probably good for upstart, and i'm sure you can find a similar thing in systemd, but i dont know it off the top of my head.
[14:40] <smoser> jtheuer, i'm curious how you're acommplishing it, and i'd be open to something to do it in a sane generic way in cloud-init
[14:40] <smoser> the other thing you could do is pass the keys into the instance
[14:40] <jtheuer> Haven't followed the last war on system init, currently we use ubuntu LTS which uses upstart. I'll check if that is still true for the next LTS version
[14:41] <smoser> it will change to systemd in 16.04. Horay for time lost to re-doing things that are already done!
[14:42] <smoser> you *can* pass keys into the instance reasonably securely, with #include-once
[14:42] <jtheuer> smoser, that would be cool. I see two ways depending on the user's needs: First, add private, public and cert host to cloud-init file. Or second let the instance generate new keys and sign it with a supplied private ca key. (I currently fetch the key from AWS S3 via a script but that is probably not the final version)
[14:43] <jtheuer> Then, a line for the host keys certificate has to be added to the sshd config: "HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub" >> /etc/ssh/sshd_config
[14:46] <jtheuer> Adding all three files (private, public, cert) to cloud-config.yaml has security advantages, the ca file stays on your local computer.
[14:47] <smoser> yeah, but without '#include-once', and a read-once url, you've provided non-root user onthe instance with the ssh private key
[14:50] <jtheuer> You mean all users can read the original cloud-init.yaml file?
[14:53] <jtheuer> So this is a general issue when you add an ssh private key to cloud-init. Never thought about it... Luckily we only have admins users so far but still not very nice.
[15:01] <smoser> jtheuer, well, the user can't read the file on disk
[15:01] <smoser> but if it came from an http web service, it is still probably there (ie, on ec2 its in ec2 user-data that is accessible to anyone on that host)
[15:02] <jtheuer> Then, I probably didn't get what you mean with your concern about the ssh private key in cloud-init (like it is possible now)
[15:03] <jtheuer> or do you refer to the AWS metadata implementation as http endpoint? This is indeed a bit strange that everybody can read the full instance details.


[00:01] <Keybuk> 6s in fact
[00:23] <Kano> hi rtg , saw your firmware update, looks good. but something else now
[00:24] <Kano> rtg: http://paste.debian.net/26668
[00:24] <Kano> do you see that sis agp crash
[00:25] <rtg> Kano: do you see any mention of this upstream?
[00:26] <Kano> well the system boots still,but the crash does not look good
[00:26] <rtg> Kano: do you have a PCI ID?
[00:27] <Kano> http://paste.debian.net/26664
[00:36] <rtg> Kano: huh, nothing obvious. start a bug report and attach those 2 files
[00:36] <Kano> its not my system
[00:37] <rtg> Kano: well then, get the user to do it.
[00:43] <Kano> did you get the openfwwf to compile?
[00:44] <Kano> http://www.ing.unibs.it/openfwwf/
[00:44] <Kano> modprobe b43 qos=0
[00:45] <Kano> means that it may require a kernel option, which could be made default
[02:18] <CarlFK> when I remove/replace an Express Card, display fills with a pattern an the box hangs
[02:18] <CarlFK> januty
[10:40] <lool> Hmm I see that linux-restricted-modules-common in jaunty carries a /etc/modprobe.d/ipw3945; I think this is an old binary daemon that used to be required, but nowadays all 3945 cards will use iwlwifi, right?
[10:48] <lool> It was dropped, but not rm_conffile()d
[14:41] <rtg> amitk: are you working on ARM stuff today?
[14:47] <apw> tjaalton, hey ... how is the drm headers issue going?
[14:47] <tjaalton> apw: should be fixed now
[14:48] <tjaalton> at least mesa built fine
[14:48] <apw> tjaalton, perfect, just waht i wanted to hear :)
[14:49] <tjaalton> yeah :)
[16:45] <amitk> rtg: yes I am
[16:46] <rtg> amitk: are you interested in adding armel support to LRM/LBM ?
[16:47] <amitk> rtg: not at the moment. I don't see a usecase yet.
[16:48] <rtg> amitk: ok, then I'm gonna whack on them so they they don't build at all. I'm currently getting failures 'cause the arch in debian/control is 'any'
[16:49] <amitk> rtg: go ahead. I'll be busy getting the various flavours into shape
[16:50] <rtg> amitk: wfm
[16:55] <mnem0> rtg: tjaalton: I was hit by that intel waitForVBlank freeze bug and I had tested the "dont enable vblanks on disabled pipes" drm patch which worked great on my machine... but today when the .28-5 kernel installed my intel G45 machine got unbootable --> https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/320525
[16:55] <ubot3> Malone bug 320525 in linux-meta "jaunty unbootable on intel G45 since .28-5 kernel update" [Undecided,New]
[17:23] <lool> apw: So you want a LP bug?
[17:27] <apw> lool was asking if there is one?  or not
[17:29] <lool> apw: Yeah and I replied not but happy to file one if you like
[17:29] <lool> apw: Just tell me if you require one, I'll file one; otherwise no there's currently none :)
[17:33] <apw> thats fine thanks for the info
[20:22] <Keybuk> [97766.161127] ata1: exception Emask 0x10 SAct 0x0 SErr 0x1810000 action 0xe fro
[20:22] <Keybuk> zen
[20:22] <Keybuk> [97766.161135] ata1: SError: { PHYRdyChg LinkSeq TrStaTrns }
[20:22] <Keybuk> [97766.161141] ata1: hard resetting link
[20:22] <Keybuk> [97768.652032] ata1: COMRESET failed (errno=-32)
[20:22] <Keybuk> [97768.652039] ata1: reset failed (errno=-32), retrying in 8 secs
[20:22] <Keybuk> [97776.160058] ata1: hard resetting link
[20:22] <Keybuk> [97778.548037] ata1: COMRESET failed (errno=-32)
[20:22] <Keybuk> [97778.548044] ata1: reset failed (errno=-32), retrying in 8 secs
[20:23] <Keybuk> [97786.160023] ata1: hard resetting link
[20:23] <Keybuk> [97788.388036] ata1: COMRESET failed (errno=-32)
[20:23] <Keybuk> [97788.388043] ata1: reset failed (errno=-32), retrying in 33 secs
[20:23] <Keybuk> [97821.160023] ata1: hard resetting link
[20:23] <Keybuk> [97823.388022] ata1: COMRESET failed (errno=-32)
[20:23] <Keybuk> [97823.388028] ata1: reset failed, giving up
[20:23] <Keybuk> [97823.388030] ata1.00: disabled
[20:23] <Keybuk> eep
[20:24] <rtg> Keybuk: did you break your drive?
[20:24] <Keybuk> no, I don't _think_ so
[20:24] <Keybuk> if I reboot, it comes back just fine
[20:25] <Keybuk> any way I can bounce that?
[20:25]  * Keybuk thinks vmware made the kernel think he broke the drive
[20:25] <rtg> I doubt it, its likely boot essential.
[20:25] <rtg> oh, is that from a VM?
[20:26] <Keybuk> no, from the real system
[20:27] <Keybuk> but this only happens when vmware is doing things, and never when vmware's modules aren't loaded
[20:27] <rtg> 2.6.28-5 ?
[20:28] <Keybuk> 2.6.27-11
[20:29] <rtg> ah, intrepid. There were some recent VMware patches. lemme check when they went in.
[20:31] <rtg> Keybuk: what kind of drive? '* libata: fix Seagate NCQ+FLUSH blacklist' went into -11.22
[20:31] <Keybuk> seagate
[20:31] <Keybuk> no, samsung sorry
[20:32] <Keybuk> SAMSUNG SP2504C
[20:33] <rtg> Keybuk: the vmware changes haven't been committed yet
[22:07] <CarlFK> ibex: I boot live cd with a firewire ExpressCard in, lspci shows the FW listing.  I pull the card out, lspci still shows it
[22:25] <CarlFK> same with today's jaunty


[20:03] <ibeardslee> morning
[20:12] <ajmitch> morning
[20:27] <ajmitch> interesting news from telstraclear, "no demand" for high-speed broadband in wellington & christchurch
[20:31] <ibeardslee> they are having a cry over not getting any ufb project contracts
[20:32] <ajmitch> it would cut into their margins a bit, when it eventually gets rolled out
[20:32] <ibeardslee> plenty of demand for it, just that they can't be arsed peering properly
[20:33] <ajmitch> I wonder if there'll be any way we can keep an eye on UFB progress around the country
[20:36] <ibeardslee> but the reality is that it is still at the chicken and egg stage
[20:38] <ajmitch> right, which is why the government is saying they want to fund the rollout, to get some of that going
[20:45]  * ibeardslee looks forward to the day when free national data is the norm (again)
[20:45] <ajmitch> it'd be nice
[20:46] <ajmitch> do you know if any peering requirements are built into the UFB project?
[20:46] <ajmitch> or if it'll remain with the big players screwing everyone else?
[20:51] <ibeardslee> I don't know either way .. do you want the optimistic or pessimistic opinion?
[20:51] <ajmitch> the pessimistic one is probably more likely :)
[20:57] <ibeardslee> yeah :(
[20:58] <Atamira> good morning
[21:12] <thumper> morning
[21:31] <chilts> morning
[21:35] <hads> Chilly morning.
[21:35] <ajmitch> slightly
[22:12] <ibeardslee> better than it was yesterday though


[00:25] <emgent`> SteveA: ping
[00:36] <wgrant> emgent`: given that you don't seem to be having much luck, maybe email him?
[00:37] <wgrant> Or find a more appropriate person.
[00:37] <emgent`> wgrant: i mailed kiko too, but i think that i should be wait tomorrow
[00:38] <emgent`> i have little urgence to activate nubuntu in launchpad for start the tracker and the other stuff
[00:40] <wgrant> emgent`: May I ask why you are creating a derivative?
[00:40] <wgrant> As an Ubuntu developer, I would think you would know that that's not the best way to go about things.
[00:41] <emgent`> wgrant: nubuntu exist since 6.X
[00:42] <emgent`> and it`s a really specific project
[00:42] <emgent`> anyway i will commit all packages in ubuntu repo dont worry :)
[00:42] <wgrant> Good, good.
[01:58] <ausimage> Can someone help figure out how to add another administrator to a team I own?
[01:58] <wgrant> ausimage: You click on the edit link next to them on +members.
[01:59] <ausimage> the pencil?
[01:59] <wgrant> Yes.
[01:59] <ausimage> there! it was hiding from me :/
[01:59] <ausimage> thanks
[02:15] <fta> https://edge.launchpad.net/+builds/lansones
[03:43] <mdeslaur> Where do I report launchpad abuse to get an account disabled?
[03:45] <wgrant> mdeslaur: https://answers.launchpad.net/launchpad/+addquestion, given that the usual AsiaPac LOSA is on leave.
[03:45] <wgrant> Which user is it? They've had a few usuals lately...
[03:46] <mdeslaur> hi wgrant. It would be this guy: https://launchpad.net/~maurizio-live
[03:47] <wgrant> Ah.
[03:47] <wgrant> Him again.
[03:47] <wgrant> spm loves him.
[03:47] <mdeslaur> hehe
[03:47] <wgrant> But what the frick is he doing reenabled.
[03:47] <wgrant> Maybe he hasn't been disabled since they fixed that bug.
[03:47] <mdeslaur> what bug?
[03:47] <wgrant> Oh.
[03:48] <wgrant> he's back at it.
[03:48] <wgrant> Bastard.
[03:48] <wgrant> The bug where a deactivated user could reactivate their account.
[03:48] <mdeslaur> ouch
[03:48] <mdeslaur> that's a bad bug :)
[03:48]  * wgrant hopes there is a LOSA around soonish.
[03:48] <wgrant> But of course everybody is on leave, so it probably won't get fixed for two weeks like bugmail.
[03:50] <wgrant> I guess we might have herb in 12 hours.
[03:51] <mdeslaur> ok, I'll ask herb tomorrow
[03:51] <mdeslaur> thanks wgrant
[03:51]  * wgrant forgets who the other LOSA is.
[03:51] <wgrant> Ah.
[03:51] <wgrant> Nobody.
[03:51] <wgrant> That would explain it.
[03:51] <mwhudson> mthaddon is the other losa
[03:52] <wgrant> Right, but he's not here.
[03:52] <mwhudson> indeed
[03:52] <wgrant> I wonder if somebody forgot to really kill maurizio-live after the rollout, or if there is YALPB that we have to work out ourselves.
[04:17] <sgorf> I've just renamed my short name and my PPA url for sources.list now 404s. Have I broken it or will it rebuild itself in time?
[04:19] <nhandler> sgorf: If you changed your name on LP, your PPA url will also change
[04:19] <sgorf> nhandler: Yes it has, but the URL itself 404s
[04:19] <sgorf> The new URL that is
[04:19] <nhandler> The new url?
[04:19] <nhandler> Are you using the URL listed on your ppa page?
[04:20] <sgorf> Yes - that 404s. I've just tried and the old URL still works. These URLs are http://ppa.launchpad.net/...
[04:20] <wgrant> sgorf: You'll have to convince Launchpad to republish your PPA - just uploading a package or copying an existing one to another distribution series will do it.
[04:20] <wgrant> (if you do it now, it'll be fixed in 20 minutes)
[04:22] <sgorf> wgrant: Thanks. I've made a copy to another series. I guess I'll just wait for the new URL to start working and then delete it again?
[04:23] <wgrant> You can probably actually delete it now, but I'd not risk it.
[04:23] <wgrant> So yes, do as you say.
[04:23] <sgorf> Great - thanks very much
[04:24] <wgrant> np
[04:34] <wgrant> stub: Thanks!
[04:35] <wgrant> stub: Can you tell if it was already disabled post-rollout?
[04:35] <stub> Not now...
[04:35] <wgrant> I thought there might have been a log somewhere.
[04:36] <wgrant> Because I would have thought a LOSA would have done that...
[04:36] <stub> There might be - I'm not normally doing this sort of thing ;)
[04:38] <wgrant> I pondered pinging you when I saw you were around while it was being discussed, but presumed you wouldn't do anything of the sort. I am glad I was wrong!
[04:38] <wgrant> Maybe he will stay dead for more than a day this time.
[04:38] <wgrant> FUCKER
[04:39] <wgrant> He's using his other account.
[04:39] <wgrant> ~rutadeevacuacion
[04:39] <wgrant> That *was* dead.
[04:39] <wgrant> I'm sure of it.
[04:40] <wgrant> stub: Can you kill that too, please?
[04:40] <stub> Ok.
[04:41] <wgrant> He noticed quickly this time :(
[05:17] <sgorf> wgrant: It created http://ppa.launchpad.net/.../ubuntu/dists/jaunty/ (I copied from intrepid to jaunty) but not http://ppa.launchpad.net/.../ubuntu/dists/intrepid/ - and then an upload of a new package to intrepid failed during the chroot step as dists/intrepid/main/binary-i386/Packages.gz 404'd
[05:22] <wgrant> sgorf: Blah, I guess it only publishes dirty pockets. Copy something into each series you want published, and I'll see if there's a bug about this.
[05:24] <wgrant> Bug #87326 is probably this.
[05:26] <sgorf> Thanks. I think I've stuffed it more now. I can't seem to copy Hardy -> Gutsy as "same version has unpublished binaries in the destination archive for Hardy, please wait for them to be published before copying" - but it says that the hardy version is published
[05:26] <wgrant> sgorf: You recently uploaded the hardy one?
[05:27] <sgorf> I copied the hardy one from the broken intrepid one. The hardy one built ok
[05:27] <wgrant> Ah.
[05:27] <wgrant> Bug #283960
[05:27] <sgorf> So then I deleted the intrepid one with the intention of then copying hardy back to intrepid
[05:27] <wgrant> Binaries are published separate from sources.
[05:27] <wgrant> Wait 13 minutes, try again.
[05:27] <wgrant> Then the binaries will be published.
[05:27] <sgorf> lol ok ;)
[05:28] <wgrant> The 'Published' field on +archive just refers to the source.
[05:29] <sgorf> Right. I think I understand the state now, thanks.
[06:22] <wgrant> Launchpad.  Again.
[06:28] <wgrant> That's two in a week.
[06:34] <wgrant> Ah, I think I might see what's going on here.
[06:34] <wgrant> So it's not entirely broken by design.
[06:59] <Hobbsee> wgrant: no, they didn't kill him after the rollout.  i asked one LOSA to, but he didn't end up doing it
[07:00] <Hobbsee> although might have done so after lunch, when i hadn't checked again
[07:02] <wgrant> Hobbsee: Ah, damn.
[07:02] <wgrant> Maybe they'll stay dead now.
[07:03] <Hobbsee> wgrant: well, i got my second account killed, and still haven't managed to be able to reactivate it again, so i am confident that they have actually fixed it correctly
[07:03] <Hobbsee> or, that if they haven't, that it's going to take a while to figure out what the next way is to get in
[07:03]  * Hobbsee tried all the obvious options, but no dice.
[07:13] <wgrant> OK, I take back my not entirely broken statement.
[07:14] <Hobbsee> it's just mostly broken?
[07:15] <wgrant> No, it's entirely broken.
[07:15] <Hobbsee> make up your mind ;)
[07:15] <wgrant> More broken than I'd imagined.
[07:15] <Hobbsee> so how's it broken, and what are the implications?
[07:15] <wgrant> That's for the private bug to know.
[07:15] <Hobbsee> awww
[07:16] <Hobbsee> can i get subscribed to it?  :P
[07:18] <wgrant> Oh good.
[07:18] <wgrant> Bad evening, al-maisan.
[07:23] <Hobbsee> wgrant: i'm starting they need to have something between production and edge, where you can just go in and point out all the holes, before this stuff gets released.
[07:23] <Hobbsee> it would probably be the quickest way of finding them
[07:23] <Hobbsee> and finding all the problems, before they became bigger problems.
[07:36] <wgrant> I really fear the freeing now.
[07:36] <wgrant> Even just the availability of design docs is going to make this stuff easier to find. I guess non-malicious people are just going to have to find them first.
[07:39]  * Hobbsee wonders if any other projects do offer private repositories, and other private stuff, centralise
[07:39] <Hobbsee> d
[07:47] <sgorf> Does the "deleted" status ever go away?
[07:47] <wgrant> sgorf: In a PPA?
[07:47] <sgorf> Yeah
[07:48] <wgrant> No, those packages will show up forever.
[07:48] <al-maisan> hello wgrant
[07:48] <sgorf> My PPA now works as it should, but it says "build failed" against intrepid, possibly because I copied it over a previous deleted version
[07:48] <al-maisan> how are things?
[07:48] <wgrant> al-maisan: Hello...
[07:48] <wgrant> al-maisan: Not optimal, if you check your bugmail.
[07:48] <al-maisan> hmm..
[07:49] <sgorf> What I don't really get is that how can you rebuild a package if it already exists in another series? Surely both builds end up in the same place in the pool?
[07:49] <wgrant> sgorf: They do.
[07:49] <wgrant> You can't copy it without binaries within the same PPAa.
[07:49] <wgrant> It will tell you you are wrong.
[07:49] <al-maisan> wgrant: please point me to the bug you have in mind.
[07:49] <wgrant> al-maisan: Bug #310507, bug #310503
[07:50] <sgorf> wgrant: OK I get that...but then how can I have build failed in one series but build succeeded in another - both in the same ppa?
[07:50]  * al-maisan takes a look
[07:50] <wgrant> sgorf: Hm, where's this?
[07:50] <sgorf> https://launchpad.net/~racb/+archive?field.name_filter=&field.status_filter=any
[07:51] <sgorf> I've made a right mess of it if deleted packages are going to hang around forever :-/
[07:51] <wgrant> That's an interesting case.
[07:51] <wgrant> Why?
[07:51] <wgrant> Deleted packages don't affect much.
[07:51] <sgorf> Yeah but it's ugly!
[07:51] <wgrant> Other than stopping you from uploading the same version again.
[07:51] <wgrant> Oh.
[07:51] <wgrant> You mean like that, I see.
[07:52] <wgrant> No, those won't be there forever.
[07:52] <wgrant> The aren't displayed by default, normally.
[07:52] <wgrant> But these are because they were copied into and are still published in another series.
[07:52] <wgrant> That's probably a bug.
[07:52] <sgorf> I see
[07:53] <sgorf> I have to say I'm very impressed by ppas and launchpad generally
[07:53] <wgrant> Once they're gone from that other series, they should both vanish from the page.
[07:53] <sgorf> I used to maintain all my own repositories by hand (for company internal stuff)
[07:54] <wgrant> That's painful.
[07:54] <wgrant> LP certainly makes things much easier.
[07:55] <sgorf> Painful yeah - I built all packages by hand and copied the binaries around to get them to the repository and a script to update the Packages files. No pool - separate directories for each stream. And no removal of old packages either
[07:55] <wgrant> Ah, fun.
[07:58] <sgorf> One other ugliness - Jaunty is listed in the sources.list filter thing even though I don't have any packages for jaunty any more. I guess that's because a Release or Packages file exists for it
[07:58] <wgrant> Right, that sounds like another bug, and I think that one might already be filed.
[07:59] <sgorf> Quite a lot of bugs exposed for one night's work then :-)
[08:00] <sgorf> Are there any bugs you think I should file?
[08:01] <wgrant> sgorf: You could file the one about the deleted packages still showing up.
[08:01] <wgrant> If it is already filed, and I don't think it is, somebody who knows will fix it up, I'm sure.
[08:02] <sgorf> So the deleted package should have disappeared, but hasn't, right?
[08:02] <wgrant> Correct.
[08:15] <sgorf> wgrant: Bug #231364 suggests that I might have to wait 24 hours - or do you think that doesn't apply here?
[08:16] <wgrant> sgorf: I don't think that's relevant here - that's for the packages in the pool.
[08:17] <sgorf> OK thanks. I'll file a bug
[08:28] <sgorf> OK filed bug #310517, thanks very much for the help wgrant
[08:28] <wgrant> sgorf: np
[13:14] <emgent> kiko-afk: ping about question 54892
[13:16] <kiko-afk> yeah yeah
[13:17]  * Hobbsee wonders if questions get dumped to the bottom of kiko's queue if they get asked about too much
[13:19] <kiko-afk> sometimes!
[13:20] <kiko-afk> wgrant, ping?
[13:21] <Hobbsee> kiko-afk: he'll be asleep by now
[13:21] <emgent> kiko-afk: lol, you dont understand me :)
[13:22] <kiko-afk> emgent, sometimes. sometimes. :)
[13:23] <wgrant> kiko-afk: Hi...
[13:25] <emgent> kiko-afk: when you have time take a look on my reply.
[13:25] <Hobbsee> or not
[16:40] <hexmode> are the 64bit ppa builds down?
[16:40] <cprov> hexmode: let me check
[16:41] <cprov> hexmode: no, nothing indicates that, americium is building.
[16:42] <hexmode> k, just wondering because apt-get update is giving me nothing on some ppas...
[16:42] <hexmode> will look a bit closer myself
[16:55] <pmarti> any kind soul to review the .pot of the wader project? thanks :)
[17:42] <MagicFab> hate to ask this, but is there any way to remove someone from the "recently applied" / "deactivated" members list of a team ?
[17:42] <beuno> MagicFab, not really, no  :(
[17:44] <MagicFab> beuno, not even by removing the account completely ?
[17:44] <beuno> MagicFab, maybe if it is deactivated, yes
[17:44] <beuno> sinzui, ^
[17:45] <MagicFab> in fact I thjink this user just deactived their account
[17:45] <MagicFab> https://edge.launchpad.net/~sebastiancobaleda
[17:45] <sinzui> MagicFab: No-one can remove an account
[17:46] <MagicFab> interesting, as I still have his account info in another browser. But opening a new window gives me an error
[17:46] <sinzui> MagicFab: But I see I misunderstood. Congratulation, you have discovered a bug
[17:47] <sinzui> MagicFab: I think the user is now gone. Is he still in your list?
[17:48] <MagicFab> sinzui, how could he remove himself ? I was going to ask the bug squad how he made it into that team as he was  "fix released"ing bugs and causing damage in every place he participated!
[17:51] <MagicFab> sinzui, he had accumulated a karma of 5343 - ~3000 more than yesterday
[17:51] <sinzui> MagicFab: I think the user is deactivated or suspended. No active users have that id, nor do I see sebastian cobaleda when I search. The user could have changed his name or displayname...but that wouls also show up in your list of "recently applied"
[17:54] <sinzui> MagicFab: which team are you seeing this user in?
[17:54] <MagicFab> ok got it -> https://edge.launchpad.net/~jscc88-deactivatedaccount
[17:55] <sinzui> I see
[17:57] <MagicFab> sinzui, he most probably accumulated a lot of karma by opening dummy accounts and sending answers back and forth.
[17:57] <sinzui> ??
[17:57] <sinzui> Why? Blueprints are the way to get karma for doing nothing?
[18:01] <sinzui> MagicFab: Is this user stuck in a recently applied list? For which project? Deactivated users should not appear in a list to join a team
[18:11] <MagicFab> sinzui, as I asked here he apparently zapped himself from everywhere
[18:16] <sinzui> MagicFab: I don't think that is the whole story. A lot of questions are unsolved. I don't see any spam in his remarks. Though I don't think his advise was often helpful
[18:17] <MagicFab> I see a lot of cut & paste comments, and he may just have preferred to storm out.
[18:29] <sgorf> In bugs.../.../+bug/.../+choose-affected-product, how do I select an Ubuntu package? I can see other bugs listed as "bluez (Ubuntu)", but entering "ubuntu", "bluez", "ubuntu bluez", "ubuntu/bluez" all fail to find it
[18:30] <beuno> sgorf, full URL?
[18:30] <sgorf> to the project?
[18:30] <beuno> sure, why not
[18:30] <sgorf> I tried https://launchpad.net/ubuntu/+source/bluez and that failed also
[18:32] <beuno> sgorf, where are you trying to link it?
[18:32] <sgorf> https://bugs.launchpad.net/medibuntu/+bug/285412
[18:32] <sgorf> I've found that that bug is actually a general Ubuntu bug, in I think bluez
[18:32] <sgorf> As it affects non-alsa stuff for me in Intrepid
[18:33] <sgorf> So I am trying to add "bluez (Ubuntu)" as an "also affects project", then enter a comment to explain
[18:33] <beuno> sgorf, if you want to link to a package
[18:33] <nhandler> sgorf: Use also affects distribution
[18:33] <beuno> you'll need to use "Also affects distribution..."
[18:33] <beuno> (I know, not intuitive, we're fixing it)
[18:34] <sgorf> OK, it seems obvious now - and it worked - thanks!
[18:34] <nhandler> :)
[19:06] <CarlFK> https://bugs.edge.launchpad.net/ubuntu/+bugs?advanced=1
[19:06] <CarlFK> the tag list is too long
[19:07] <CarlFK> and I have no idea how to search for "usb" in jaunty
[19:09] <lamalexmas> anyone know the status of the launchpad + PQM integration?
[19:09] <lamalexmas> is that something we can be looking forward to in Q1 2009?
[21:08] <CarlFK> how do I check out trunk from a project? it would be nice to have something I can cut/paste into a shell on  https://code.edge.launchpad.net/~mdipierro/web2conf/devel
[21:10] <beuno> CarlFK, if the project has set a branch as their development focus, it's just a simple:   bzr branch lp:projectname
[21:11] <beuno> CarlFK, which that project hasn't