[00:23] <smspillaz> RAOF: hi
[00:23] <smspillaz> RAOF: so turns out we don't need screen crtc pixmaps to do what I want
[00:23] <RAOF> Funkysauce.
[00:23] <smspillaz> RAOF: I did it using a trick in xcomposite
[00:24] <smspillaz> RAOF: so now all we need is for lightdm to implement a simple compositor and have that carry through into the session until compiz tries to replace it, if at all possible
[00:25] <RAOF> Probably fairly simple.
[00:25] <smspillaz> and then in the logout case, if it's possible to allow lightdm to "take over" a currently running x server, then have it's compositor replace the gnome-session one which will replace the compiz one
[00:25] <smspillaz> and ta-da, no flicker! :)
[00:26] <smspillaz> RAOF: actually, even for the restart case, it looks really cool
[00:26] <RAOF> What's the XComposite trick?
[00:27] <smspillaz> instead of going CLUNCK, flashflashflashflashflash, VANISH, BOOM (shift)
[00:27] <smspillaz> it's just *stop* *start
[00:27] <smspillaz> RAOF: oh, the new compositor doesn't take the selection until it's painted at least one frame
[00:27] <smspillaz> so the old compositor stays around until the new compositor has done this
[00:28] <RAOF> Nifty
[00:29] <smspillaz> (basically, there's a property that the outgoing and incoming compositors set on the window used for the composite selection which says they support the handoff protocol
[00:30] <smspillaz> so when the new compositor comes in, it checks for the existence of the protocol, and doesn't try to do CompositeRedirectManual, but instead does CompositeRedirectAutomatic and *doesn't* touch the composite overlay window
[00:30] <smspillaz> and then it paints one full frame
[00:30] <smspillaz> and then it takes the selection
[00:31] <smspillaz> upon losing the selection, the old compositor checks the new selection owner for the property, and if that's present, it doesn't unmap the composite overlay window or touch it in any way (but it does redirect using CompositeRedirectManual)
[00:31] <smspillaz> err, *unredirect
[00:31] <smspillaz> then the new compositor waits for the old one to finally go away, and does a redirect using CompositeRedirectManual, but the output window is still visible
[00:32] <smspillaz> (because both have a reference on it)
[00:32] <smspillaz> however, the only caveat so far is that it makes the giant assumption that you will lose the composite selection, which is a problem if you went from compositor to no compositor
[00:33] <RAOF> Heh.
[00:33] <smspillaz> so if you replace compiz with an unpatched metacity your screen hangs
[00:33] <smspillaz> (mostly because of the loose marriage between 'compositor' and 'window manager')
[00:34] <smspillaz> I suppose I could make a new selection, but then I'd have to resort to checking incoming properties on the root window and I've found that to be racy
[00:34] <smspillaz> or it could just time out
[00:38] <smspillaz> RAOF: what I *really* want to do though is enforce compositing, like maybe we can do something in gnome-session to always try and composite the screen if it stops being composited or whatever, but that's really hard to do because of the way selections work
[00:39] <RAOF> I wouldn't mind, personally, if the answer to "what happens if you run an unpatched metacity" was "it breaks".
[00:39] <smspillaz> RAOF: s/metacity/xmonad/
[00:40] <smspillaz> think of the people who will ditch ubuntu for arch :p
[00:40] <RAOF> s/metacity/*/
[00:40] <RAOF> unity-greeter could quite happily only do this when running an "Ubuntu" session, which we know will start Unity.
[00:40] <smspillaz> yeah I suppose
[00:41] <smspillaz> and then we could just ignore --replace except when allowing it inside of unity
[00:41] <RAOF> And could start compiz with "--compositor-handoff"
[00:41] <smspillaz> but *gosh* that's a hack :p
[00:41] <jbicha> similar idea to what GDM is doing with it being part GNOME Shell now if the hardware supports it
[00:41] <smspillaz> yeah
[00:41] <smspillaz> I'm not really keen on running compiz on lightdm
[00:42] <smspillaz> *thinks of the security implications*
[00:42] <RAOF> And it's slow on startup.
[00:42] <smspillaz> compiz by itself is really fast to start
[00:42] <smspillaz> it could be faster
[00:42] <RAOF> Oh, right.  I was thinking a full session compiz. :)
[00:42] <smspillaz> but if you did composite --replace composite opengl its pretty much instance :)
[00:42] <smspillaz> err
[00:42] <smspillaz> *compiz
[00:43] <smspillaz> RAOF: I'm more thinking of
[00:43] <smspillaz> "hey, install this BLING BLING plugin"
[00:43] <smspillaz> "GLScreen::glPaintOutput () { execl ("/bin/bash"); }
[00:44] <jbicha> my software center is busted, are y'all having any problems with it?
[00:44] <RAOF> Nope.  Well, apart from my self-inflicted PolicyKit wound.
[00:45] <smspillaz> I wonder if its possible to use PolicyKit for things other than granting root permissions
[00:45] <RAOF> Yes, absolutely.
[00:45] <smspillaz> oh, cool
[00:46] <jbicha> I get a blank white window and this is the only output on the terminal: http://paste.ubuntu.com/705203/
[00:46] <smspillaz> I was thinking of something like being able to have a "blessed" screensaver window
[00:46] <RAOF> It'll become more possible once https://bugs.freedesktop.org/show_bug.cgi?id=41025 gets accepted, too :)
[00:46] <ubot2> Freedesktop bug 41025 in daemon "Add an ‘owner’ user to actions." [Enhancement,New]
[00:46] <RAOF> smspillaz: PolicyKit doesn't actually grant root permissions anyway; it's just a way for $DAEMON to check whether $CLIENT should be able to perform $ACTION.
[00:46] <smspillaz> I figured
[00:47] <smspillaz> RAOF: and I suppose it gives keys or somesuch to applications so you don't have to authorize it all the time ?
[00:48] <RAOF> Depends; you can define that in the action description: http://hal.freedesktop.org/docs/PolicyKit/polkit-conf.html#conf-declaring-actions
[00:51] <RAOF> Although until that patch gets applied your $DAEMON needs to run as root for PolicyKit to be useful.
[00:52] <jbicha> pitti: python plugins are broke in Totem (libpeas again) bug 855100
[00:52] <ubot2> Launchpad bug 855100 in totem "python plugins not working" [Undecided,Confirmed] https://launchpad.net/bugs/855100
[01:10] <smspillaz> RAOF: neat
[05:19] <RAOF> Baurgh.  What part of gdk_x11_display_grab are you not understanding, damnit?
[06:01] <RAOF> Bah!  Of course, my old nemesis, XSync.
[06:14] <smspillaz> RAOF: :)
[06:15] <smspillaz> RAOF: or XNextEvent
[06:16] <RAOF> For my future self, in the hope that writing it down again will make it stick: If you call XGrabServer, it's a good really idea to XSync afterward if you expect it to take effect properly.
[06:16] <smspillaz> yeah
[06:16] <smspillaz> uhh actually
[06:16] <smspillaz> XGrabServer is synchronous iirc
[06:16] <smspillaz> it's XUngrabServer that isn't
[06:16] <smspillaz> or is it not synchronous?
[06:17] <RAOF> smspillaz: So, turns out that if you fork quickly enough you can get in before XGrabServer takes effect.
[06:17] <smspillaz> since if that's the case there's lots of code in compiz that depends on sever grabs (because we send synthetic events)
[06:17] <RAOF> XGrabServer was not sufficiently synchronous for my testing.
[06:17] <smspillaz> RAOF: hmm ok, I think I'll need to do XSync directly befor and after XGrabServer then
[06:17] <smspillaz> *before
[06:18] <smspillaz> well really, when you do XGrabServer, you should first do XSync, then XSynchronize, then XGrabServer, then do your stuff, then XUngrabServer
[06:18] <RAOF> In my case, I was trying to check that I correctly handled the case where XGrabServer causes check_gl_texture_size to hang waiting for XOpenDisplay.
[06:18] <smspillaz> then XSynchronize (false)
[06:18] <smspillaz> RAOF: ah, yikes
[06:19] <RAOF> I, too, thought that XGrabServer was synchronous, so I just called it at the top of the function that forks off check_gl_texture_size... which proceeded to *work* and happily return the correct GL_MAX_TEXTURE_SIZE.
[06:19] <smspillaz> huh
[06:19] <RAOF> Obviously not the effect I was hoping for :)
[06:20] <RAOF> So, in short: ?XGrabServer: your paranoia is justified.?
[06:21] <smspillaz> well, XGrabServer without synchronous behaviour kind of defeats the purpose of XGrabServer if you ask me
[06:22] <smspillaz> because what ends up happening is this:
[06:22] <smspillaz> listen only to me, stop listening only to me, do stuff
[06:23] <smspillaz> since if you're using server grabs, its likely that you're doing stuff with whats directly on the server at that time, which means you have to flush your output buffer
[06:23] <RAOF> In this case, gnome-desktop only wants to batch up some X state fiddling into a single notify.
[06:24] <RAOF> Oh, hai check_gl_texture_size.  *You're* what's consuming 100% cpu?
[06:38] <didrocks> good morning
[06:41] <RAOF> Morning didrocks!
[06:41] <didrocks> hey RAOF, how are you?
[06:41] <RAOF> Chagrined.
[06:42] <RAOF> For being insufficiently paranoid with check_gl_texture_size :)
[06:42] <RAOF> Also, still slightly sick, but that's easier to ignore ?
[06:44] <didrocks> oh really?
[06:44] <pitti> Good morning
[06:44] <RAOF> Morning pitti
[06:44] <RAOF> Oh, whoops.
[06:45]  * RAOF has noticed a *tiny* problem with the most recent gnome-desktop3 upload.
[06:45] <didrocks> guten morgen pitti, feeling better?
[06:45] <RAOF> We really should set --abort-on-upstream-changes by default, shouldn't we :)
[06:46] <pitti> didrocks: a bit, yes
[06:46] <pitti> hey RAOF
[06:46] <pitti> RAOF: I think dpkg 1.16.1 will help
[06:47] <pitti> RAOF: you got a debian-changes* stuff that reverted your patch?
[06:47] <RAOF> That basically flips that option to default-on, doesn't it?
[06:47] <pitti> seems so, yes
[06:49] <RAOF> oneiric-proposed is open, right?
[06:53] <pitti> RAOF: yes
[07:10] <tkamppeter> pitti, hi
[07:10] <tkamppeter> pitti, first thank you for approving my 0-day SRUs during the weekend.
[07:11] <pitti> tkamppeter: guten Morgen
[07:12] <tkamppeter> pitti, I have a little problem with my eeePC. I got a flooding of WLAN password requests due to bug 868293 and then turned off WLAN in the indicator applet menu. This also removed the menu entry to turn on WLAN again, and now I am totally locked out, the machine looks like having no WLAN by hardware now.
[07:12] <ubot2> Launchpad bug 868293 in unity "compiz assert failure: *** glibc detected *** compiz: free(): corrupted unsorted chunks: 0xa05166e0 *** (drm_intel_gem_bo_unreference)" [High,Fix committed] https://launchpad.net/bugs/868293
[07:12] <tkamppeter> pitti, as usual, scrambling bug numbers, I meant bug 854833.
[07:13] <ubot2> Launchpad bug 854833 in gnome-keyring "(oneiric) wireless passwords not remembered" [Undecided,Confirmed] https://launchpad.net/bugs/854833
[07:13] <pitti> tkamppeter: that's something for cyphermox
[07:15] <tkamppeter> cyphermox, hi
[07:16] <pitti> tkamppeter: he's in the US, so he'll answer this afternoon
[07:16] <tkamppeter> pitti, as you have seen the CUPS SRU is verified. I have joined the two bugs as duplicates as they are fixed by the same patch.
[07:19] <tkamppeter> pitti, do you know which package is the culprit for the disappeared WLAN?
[07:22] <pitti> tkamppeter: I don't, no; works here
[07:23] <chrisccoulson> good morning everyone
[07:23] <didrocks> hey chrisccoulson
[07:24] <didrocks> welcome back! (well, if we consider you didn't connect during your vacations ;))
[07:24] <chrisccoulson> hi didrocks :)
[07:24] <tkamppeter> pitti, have found out what happend: Turning of wireless has put the machine into inflight mode (did not see that directly as a plugged USB Bluetooth adapter carried on working, I pressed Fn + F2 to leave inflight mode, then the wireless entry reappeared in the menu and I could turn on wireless again by the menu.
[07:24] <chrisccoulson> thanks ;0
[07:24] <chrisccoulson> how are you?
[07:24] <pitti> tkamppeter: aah, kill switch?
[07:25] <didrocks> chrisccoulson: I'm fine thanks, and you?
[07:25] <chrisccoulson> didrocks, yeah, good thanks
[07:25] <pitti> hey chrisccoulson -- don't you need some holiday now? :-)
[07:25] <chrisccoulson> hi pitti. yeah, i'll need some more holiday again soon ;)
[07:27] <tkamppeter> pitti, what do you mean with "kill switch"?
[07:27] <pitti> tkamppeter: the key/slider which disables/enables wifi is usually called "kill switch"
[07:28] <tkamppeter> pitti, some boxes have a physical slider which cannot be set by software, this netbook not.
[07:32] <tkamppeter> pitti, in this case the software can set the kill switch which this action should not do.
[07:33] <RAOF> chrisccoulson: How would you like to test gnome-desktop later?
[07:34] <chrisccoulson> RAOF, sure, can do
[07:34] <RAOF> I can either PPA it up or point you at a packaging branch.
[07:43] <RAOF> chrisccoulson: First cut is in ppa:raof/aubergine, pending building.  That should ensure your desktop is never blocked by check_gl_texture_size, no matter how crazy gnome-desktop/g-s-d want to be.
[07:47] <rodrigo_> morning
[07:59] <pitti> hey rodrigo_
[08:02] <Sweetshark> Morning all!
[08:04] <rodrigo_> hi pitti, Sweetshark
[08:05] <pitti> hey Sweetshark, how are you?
[08:05] <seb128> hey
[08:05] <didrocks> good morning Sweetshark, rodrigo_
[08:05] <rodrigo_> hi didrocks, seb128 :)
[08:06] <seb128> hey didrocks pitti rodrigo_
[08:06] <seb128> how is everybody,
[08:06] <pitti> bonjour seb128, ca va?
[08:06] <seb128> ?
[08:06] <seb128> pitti, ca va bien, merci ;-)
[08:06] <pitti> still a bit oneiric :)
[08:06] <seb128> hehe
[08:06] <seb128> pitti, how is your cold?
[08:06] <seb128> did you manage to get over it?
[08:06] <pitti> release candidates are built and on the tracker, if you guys feel so inclined
[08:06] <pitti> seb128: seems to be a very slow one; it's not very bad, but already lasting a week :/
[08:07] <seb128> pitti, I will do some iso testing for sure today
[08:07] <seb128> let me start syncs while I catch up on emails etc
[08:12] <Sweetshark> pitti: a cold takes 14 days to heal off, with medicine it takes two weeks ...
[08:13] <pitti> Sweetshark: that used to be 7 days -- the germs keep getting better!
[08:13] <Sweetshark> pitti: we are training them with antibiotics
[08:13] <pitti> I don't
[08:13] <pitti> but they might have gotten resistant against chicken soup and apple pie as well
[08:14] <Sweetshark> pitti: ow, now thats bad
[08:20] <seb128> pitti, do you know about udisk2 and davidz plans for it?
[08:21] <pitti> seb128: he wants to try and push it into gnome 3.4
[08:21] <seb128> ok, what I was feating
[08:21] <pitti> but I haven't played around with it much yet
[08:21] <seb128> I'm pondering staying on GNOME 3.2 for the lts
[08:21] <pitti> it's somewhere on my list of things to do
[08:21] <seb128> do you see that as a risky move in a lts cycle?
[08:21] <pitti> it's installable in parallel with old udisks
[08:21] <pitti> moderate, I think
[08:21] <seb128> well, he's porting gnome-disk-utility and gvfs
[08:21] <pitti> it's completely rewritten
[08:21] <seb128> not sure he will keep both backends
[08:22] <pitti> seb128: no, I mean for other desktops like KDE
[08:22] <pitti> seb128: but anyway, it turns some concepts upside down
[08:22] <pitti> like the distinction between "internal" and "external"
[08:22] <pitti> I'd feel better if this landed in Q TBH
[08:23] <pitti> but then again, I need to actually look at it before I make up my mind
[08:23] <pitti> something to play with next week
[08:23] <seb128> ok, me as well
[08:23] <seb128> pitti, can you look before UDS? thanks ;-)
[08:23] <pitti> one thing I want to do is writing an integration test, similar to what udisks 1 has
[08:23] <seb128> pitti, it's going to be one of the parameters in the "what GNOME version to go for" discussion
[08:23] <pitti> seb128: ok, will make sure I'm prepared for this part
[08:23] <seb128> the glib changes desrt is doing makes me nervous for a lts as well
[08:24] <seb128> and since GNOME sucks at being able to ship a new version on a non current platform I doubt we will be able to take 3.4 without udisks2; glib 2.32 gtk 3.4 etc
[08:26] <pitti> udisks2 and glib/gdu/gvfs certainly go together, yes
[08:28] <seb128> yeah, as usually with GNOME you can't easily cherrypick components
[08:28] <seb128> it's the lot or nothing
[08:29] <pitti> well, that's fairly understandable, though
[08:29] <pitti> keeping both udisks 1 and 2 code in gdu/gvfs would be quite some effort, and nobody would extensively test that upstream anyway
[08:29] <seb128> pitti, well I still wish that "applications" like gedit, eog etc would be handled as standalone applications and a bit lax on their depends ;-)
[08:30] <pitti> I don't think the API changes at the gvfs level, though
[08:30] <pitti> so it still ought to be possible to update udisks/gdu/gvfs/glib, but keep the apps, for example
[08:31] <seb128> that's already something
[08:31] <seb128> well anyway something for UDS
[08:31] <seb128> I just wanted to make sure somebody has a clue about that transition at UDS for the discussion ;-)
[08:32] <Sweetshark> pitti: does anyone know how to setup a software-raid after the install? Mine sorta kinda works -- it sometimes boots through, it is complaining about degradedraids on boot sometimes and just doesnt boot at all at other times (just hangs with a blank screen). I assume I would need to get my raid setup into the initramfs somehow maybe?
[08:32] <pitti> Sweetshark: did you try the latest udev from Friday/Saturday?
[08:33] <pitti> Sweetshark: you mean moving your root fs to raid after install?
[08:33] <pitti> I've done that on my server just through ssh years ago, with repartitioning two times (that was fun)
[08:33] <pitti> but I kept /boot/ on non-RAID; not sure if that works now
[08:40] <Sweetshark> pitti: no, no fancy stuff like root or /boot on raid. Just /home and a custom partition.
[08:40] <pitti> Sweetshark: that should "just work" (tm); i. e. do the mdadm stuff, add /dev/mapper/whatever to /etc/fstab for /home
[08:41] <pitti> mdadm udev rules sohuld assemble the array on boot, and trigger the mounting
[08:51] <didrocks> re
[08:56] <glatzor> morning mvo, debugging aptdaemon I just realized that the session indicator performs a UpgradeSystem Simulate after every change of the transaction queue
[08:56] <glatzor> mvo, that seems to be a little bit too much
[08:56] <glatzor> mvo, the simulate is also processed in the main loop (we don't use threading in oneiric) so the system gets a short block after each transaction
[08:57] <mvo> glatzor: urgh
[08:57] <mvo> glatzor: that is very much not ideal
[08:58] <mvo> glatzor: hm, what can we do, what is the best way to fix session indicator? or should we simply do some clever caching?
[08:59] <glatzor> mvo, for P indicator should use the PackageKit interface. The GetUpdates will be cached in aptdaemon.
[09:00] <glatzor> mvo, it could listen to the org.debian.apt.CacheChanged transaction
[09:00] <glatzor> transaction != signal
[09:01] <glatzor> mvo, I am away
[09:01] <mvo> glatzor: thanks for the notify!
[09:07] <czajkowski> Aloha
[09:16] <glatzor> mvo, the signal won't be enough.
[09:17] <glatzor> mvo, it seems to be difficult to this right with the current infrastructure. we have to accept some inaccuranceness
[09:17] <mvo> ok
[09:17] <glatzor> oh that word seems to be odd :)
[09:17] <mvo> I know what you mean
[09:17] <mvo> its just a bit inaccurate ;)
[09:17] <glatzor> mvo, right :)
[09:18] <Sweetshark> pitti: well, it doesnt "just work" here. and the sometimes works, sometimes doesnt stuff scares me a bit.
[09:18]  * mvo is still proud member of blatant errors and awkward grammar
[09:18]  * glatzor too
[09:18] <glatzor> see you, mvo
[09:19]  * mvo waves
[09:22] <pitti> Sweetshark: when it doesn't work, does the /dev/mapper/* device exist? or not even that?
[09:27] <Sweetshark> pitti: I am not used dmapper or lvm, just md.
[09:28] <pitti> Sweetshark: yes, but that should still end up in /dev/mapper/
[09:28] <chrisccoulson> hmmm, so, since i went on vacation, something seems to have broken the panel menus in unity on my second monitor :(
[09:28] <chrisccoulson> they no longer stay open anymore, but instead, they appear briefly and close immediately again
[09:28] <chrisccoulson> that never used to happen
[09:29] <chrisccoulson> didrocks, have you seen that?
[09:30] <didrocks> chrisccoulson: I'm not with my second monitor right now
[09:30] <didrocks> njpatel: you still have your second monitor, isn't it, do you have this? ^
[09:30] <pitti> Sweetshark: hm, or maybe not -- what do you get there, /dev/mdsomething?
[09:30] <chrisccoulson> hmmm, it's pretty broken. i tried logging out and back in again, just to make sure it wasn't transient
[09:31] <chrisccoulson> and it's consistently broken on my second monitor
[09:31] <chrisccoulson> all the menus are unusable
[09:32] <Sweetshark> pitti: I have /dev/md/1 and /dev/md/2 in /etc/mdadm/mdadm.conf and am using the UUIDs of those arrays in fstab. However, even when booting trough I get /dev/md127 and /dev/md126 instead of 1 and 2
[09:32] <njpatel> chrisccoulson, didrocks, erm, no, but let me try
[09:33] <seb128> hey chrisccoulson
[09:33]  * njpatel upgrades first, though
[09:33] <pitti> Sweetshark: oh, mdadm.conf? that shouldn't have been necessary for some ten years or longer..
[09:33] <chrisccoulson> hi seb128
[09:33] <seb128> njpatel, chrisccoulson: kenvandine (I think) mentioned the same second monitor issue
[09:33] <chrisccoulson> ah, so it might not just be me then :)
[09:33] <seb128> chrisccoulson, how are you? had nice holidays? happy to be back?
[09:33] <njpatel> okay
[09:33] <pitti> Sweetshark: perhaps try to move that away, and see what it does then?
[09:33] <njpatel> damn
[09:33] <njpatel> chrisccoulson, bug please, sir :)
[09:33] <pitti> Sweetshark: (just to rule out the possibility of some mis-configuration ther)
[09:33] <chrisccoulson> seb128, yeah, the holiday was great thanks
[09:34] <chrisccoulson> it felt like i never left really ;)
[09:34] <chrisccoulson> njpatel, did you manage to confirm it?
[09:34] <njpatel> chrisccoulson, no, but I have a feeling you might be right
[09:34] <seb128> njpatel, chrisccoulson: bug #869196
[09:34] <ubot2> Launchpad bug 869196 in unity "unity panel menus don't stay open when clicked on second monitor" [Undecided,New] https://launchpad.net/bugs/869196
[09:34] <njpatel> not yet*
[09:34] <njpatel> seb128, swheet
[09:34] <njpatel> shweet*
[09:34] <chrisccoulson> excellent, thanks :)
[09:35] <chrisccoulson> it seems all the bugs come out of the woodwork when i finish my vacation ;)
[09:35] <seb128> no, they have been sitting there
[09:35] <chrisccoulson> heh
[09:35] <pitti> seb128: my concerns about clutter weren't so much about performance, but about not working at all on some hardware; or can that be ruled out?
[09:35] <seb128> the issue is that dx didn't fix bugs previous week because njpatel was not around
[09:35] <chrisccoulson> ah, ok
[09:35] <chrisccoulson> i found a nice bug for RAOF at the weekend too
[09:35] <njpatel> seb128, come on, they were fixing bugs
[09:36] <seb128> pitti, well, if it's for games or side features it's easy enough to not care or turn the features off at beta time?
[09:36] <njpatel> it's just the bugs are harder at this point the cycle, so sometimes they take days instead of hours
[09:36] <pitti> seb128: right; but I'm concerned about it for the video player
[09:37] <seb128> njpatel, yeah, sorry, it was a bit of exageration
[09:37] <pitti> seb128: TBH I'd rather stay with totem 3.0 than moving to banshee or clutter-totem for LTS
[09:37] <seb128> njpatel, I'm a bit annoyed that things like the launcher not showing, the dash not getting the focus, the right menu list not working on for use, etc didn't get fixed
[09:37] <seb128> njpatel, sorry for turning that in wrong accusation ;-)
[09:38] <seb128> pitti, right, which is the topic of my email, I just responded to the "let clutter out of the CD" bit, I totally agree with you otherwiwse
[09:38] <njpatel> seb128, funnily enough, I just asked for a patch of the first one you mentioned, which fingers-crossed fixes it (will be in compiz release today), and the second two are the same bug with jason has been working on. I'll help him out today too
[09:39] <pitti> seb128: ah, ok; we violently agree then :)
[09:40] <seb128> njpatel, \o/ thanks
[09:40] <chrisccoulson> dear xchat, thanks for crashing
[09:40] <Sweetshark> pitti: you mean completely removing mdadm.conf?
[09:42] <pitti> Sweetshark: well, renaming for now
[09:43] <chrisccoulson> so, now oneiric is nearly released, who wants to carry on running the firefox beta before they upgrade to precise (and help test the next security update)?
[09:43] <chrisccoulson> https://launchpad.net/~mozillateam/+archive/firefox-next
[09:43] <chrisccoulson> ;)
[09:45]  * pitti updates
[09:46] <pitti> chrisccoulson: oh, 8.0 already?
[09:47] <rodrigo_> yeah, firefox version numbers increase every day now :)
[09:47] <chrisccoulson> pitti - yeah, that's the next release
[09:47] <pitti> chrisccoulson: this disables ubufox, known/intended?
[09:47] <chrisccoulson> pitti - yeah, that's known, but unintended
[09:47] <chrisccoulson> i've got a fix for that
[09:47] <njpatel> chrisccoulson, your screens have different geometries?
[09:47] <chrisccoulson> njpatel, yeah, my secondary screen is slightly bigger
[09:48] <njpatel> thanks
[09:48] <pitti> chrisccoulson: I now get an annoying "Extension-Update" dialog about test pilot
[09:48] <pitti> chrisccoulson: clicking "Update..." button doesn't do anything, and it keeps staying on all desktops
[09:48] <Laney> does it use gsettings for proxies yet? :-)
[09:48] <chrisccoulson> pitti - oh, i've not seen that
[09:48] <chrisccoulson> you could try disabling test pilot
[09:48] <chrisccoulson> i think people do that anyway ;)
[09:48] <pitti> chrisccoulson: the red "X" button on the top right works
[09:49] <chrisccoulson> pitti - yeah, the issue with it appearing on all desktops has been mentioned before
[09:49] <chrisccoulson> note that test pilot is only switched on in the beta and aurora builds
[09:49] <chrisccoulson> feel free to switch it off ;)
[09:59] <pitti> mvo: would you miss attach_gconf() much from source_update-manager.py?
[09:59] <pitti> mvo: u-m and gnome-power-manager seem to be the only two package hooks using it, and I just removed the g-p-m one in bzr
[10:00] <pitti> mvo: it uses the static "gconf" python module which will certainly mess up apport-gtk, and it's gsettings these days anyway
[10:03] <mvo> pitti: no, this needs updating to gconf anyway its outdated
[10:03] <mvo> pitti: no in the sense that I will not miss it
[10:03] <pitti> mvo: ok, thanks; I'll remove it and replace it with a no-op function, so that it doesn't immediately break hooks
[10:06] <seb128> pitti, we need an _gsettings() variant ;-)
[10:06] <pitti> seb128: bug 836489, working on it :)
[10:06] <ubot2> Launchpad bug 836489 in apport "apport should have built-in support for gsettings hooks" [Medium,In progress] https://launchpad.net/bugs/836489
[10:07] <seb128> pitti, \o/ ;-)
[10:08] <seb128> ok, I'm going to make friends :p
[10:08] <mvo> pitti: thanks
[10:08] <seb128> I'm suggesting on ubuntu-devel list that we stop getting stuff in universe and lock them to our freeze cycle but that we push packagers and upstreams to extra.ubuntu.com
[10:08] <seb128> let's see how much people will hate me :p
[10:11] <pitti> hm, is there any way to find out the system default of a gsettings key?
[10:12] <seb128> pitti, not that I know, but better to ask desrt
[10:13] <pitti> maybe there's a way to parse .config/dconf/user
[10:15] <pitti> oh, perhaps with g_settings_new_with_backend ()
[10:15] <seb128> pitti, look to the dconf-editor source?
[10:15] <seb128> pitti, the non default value keys are bold in there
[10:15] <pitti> seb128: ah, right, that does get the default
[10:15] <seb128> pitti, so robert_ancell probably does it in some way
[10:18] <pitti> wendar: are you on very latest oneiric? several bugs of that sort got fixed last week
[10:19] <wendar> very latest, just updated
[10:19] <pitti> wendar: so, for the record, your screen gets completely turned off right after logging in, but only for your user account?
[10:19] <pitti> rodrigo_: ^ I just asked her to reset org.gnome.settings-daemon.plugins.power *, but that didn't help
[10:20] <wendar> yes, backlight turned off completely
[10:20] <wendar> has to be manually turned back on
[10:20] <pitti> how do you do this? with the brightness keys?
[10:20] <wendar> (through the keyboard brigtness key)
[10:20] <wendar> yes
[10:20] <seb128> what is the bug?
[10:20] <chrisccoulson> seb128, i agree with you btw (about extras.ubuntu.com)
[10:20] <seb128> ELACKCONTEXT
[10:20] <seb128> chrisccoulson, great ;-)
[10:21] <chrisccoulson> i have an upstream currently asking me to package their software in ubuntu, and i was going to direct them there instead ;)
[10:21] <seb128> well I wish the appreviewboard was functional
[10:21] <wendar> seb128: pitti and I just switched an ongoing conversation to the channel for more perspective
[10:21] <pitti> wendar: for bisecting, you could start with chmod 0'ing /usr/lib/gnome-settings-daemon-3.0/*power* and *xrandr*, and checking if that "fixes" it
[10:21] <seb128> let's see if they fix it if they get new people on board
[10:21] <seb128> wendar, pitti: could you describe the issue?
[10:21] <wendar> seb128: so, when I log in, my backlight turns off, and doesn't turn back on again
[10:22] <wendar> seb128: it used to do the same when I resumed from sleep, but resuming is fine now
[10:22] <wendar> seb128: so it's just login, and only on my installed user account, not on a guest account on a LiveCD
[10:22] <seb128> hum
[10:24] <chrisccoulson> why do we have shutdown actions listed under "Applications" in the dash?
[10:24] <chrisccoulson> http://www.omgubuntu.co.uk/2011/10/how-to-log-out-from-unity-dash/
[10:24] <chrisccoulson> mpt? ^^
[10:24] <wendar> pitti: do you want both the lib*.so and the *.gnome-settings-plugin versions of both?
[10:24] <pitti> wendar: can't hurt to just chmod both
[10:24] <mpt> chrisccoulson, lol, I have no idea
[10:25] <chrisccoulson> heh
[10:25] <seb128> chrisccoulson, mpt: ted figured people might want to search for shutdown and find it
[10:25] <wendar> pitti: brb
[10:25] <chrisccoulson> seb128, yeah, having actions in the dash might make sense. but it doesn't make sense that they are grouped with "Applications"
[10:25] <chrisccoulson> that's weird ;)
[10:25] <mpt> +1
[10:27] <seb128> is there any way to get them listed but not in applications?
[10:27] <seb128> do we have any other category?
[10:27] <seb128> he added "System" to the category in http://bazaar.launchpad.net/~indicator-applet-developers/indicator-session/trunk/revision/217
[10:27] <pitti> seb128: bah -- dconf-editor parses the schemas
[10:28] <seb128> pitti, there is probably no other way...
[10:28] <wendar> pitti: that does it
[10:28] <wendar> pitti: both on relogin and reboot
[10:28] <pitti> wendar: can you now chmod 644 one, and see whether it's xrandr or power?
[10:28] <wendar> yup
[10:30] <mpt> Hmm ... Random question: Would it be theoretically practical for code in g-c-c to warn you that the language pack you're about to uninstall is being used by N user accounts?
[10:31] <rodrigo_> wendar, pitti: sorry, just reading the backlog now...
[10:32] <seb128> mpt, yes, trivial
[10:33] <pitti> mpt: not very precisely, but should usually be correct
[10:33] <seb128> mpt, the "language" info is in the accountsservice dbus service, so it's easy to iterate through users looking for their language and match with the one you remove
[10:33] <rodrigo_> wendar, hmm, chmod'ing those lib* files fixed the problem for you?
[10:33] <pitti> seb128: not all derivatives use accountsservice, though
[10:33] <seb128> pitti, those who don't use it don't use gnome-control-center
[10:33] <pitti> rodrigo_: just trying to bisect which plugin it was; I already had her reset the power gsettings
[10:33] <seb128> pitti, the question from mpt was about g-c-c ;-)
[10:33] <pitti> seb128: you could have some KDE and some GNOEM users
[10:34] <seb128> oh, right, I know what you mean
[10:34] <pitti> that's what I meant with "not precisely"
[10:34] <seb128> we should talk to other derivatives about using accountsservice, it's a fdo tech
[10:34] <seb128> I think robert_ancell planned to do that
[10:34] <seb128> he wanted to standardize on it for lightdm as well
[10:35] <wendar> pitti: so, it's libxrandr that causes the problem
[10:35] <seb128> wendar, interesting
[10:35] <wendar> pitti: but with libpower disabled, I can't manually turn the backlight back on
[10:35] <wendar> pitti: which made it interesting to test :)
[10:35] <pitti> wendar: can you do the list-recursively/reset-recursively/compare dance again for .xrandr?
[10:35] <seb128> xrandr has no settings
[10:36] <seb128> only enable and the default behaviour
[10:36] <pitti> not many, indeed
[10:36] <seb128> (which is "let xorg does it work)
[10:36] <pitti> but somehow that user account must be different
[10:36] <seb128> it might have a .config/monitors.xml
[10:36] <pitti> wendar migh thave a bad ~/config/monitors.xml, which would xrandr off the screen
[10:36] <wendar> it has 4 settings
[10:36] <pitti> but then the brightness settings wouldn't work
[10:36] <pitti> wendar: anyway, might be worth trying to move ~/.config/monitors.xml away
[10:37] <seb128> could be that xrandr trigger an xorg bug?
[10:37] <seb128> i.e xrandr use might screw xorg
[10:37] <seb128> which would be an xorg,driver bug
[10:37] <seb128> it would be interesting to see if with another session using the capplet or xrandr leads to similar issues
[10:38] <wendar> I have no file /etc/gnome-settings-daemon/xrandr/monitors.xml
[10:39] <wendar> The directory /etc/gnome-settings-daemon/xrandr/ is completely empty
[10:39] <seb128> wendar, ~/.config/monitors.xml
[10:39] <seb128> wendar, the etc directory is for system defaults
[10:39] <wendar> seb128: yes, but the value of default-configuration-file is '/etc/gnome-settings-daemon/xrandr/monitors.xml'
[10:40] <seb128> wendar, right, that's the default system one
[10:40] <seb128> but if you have an user one it will be used
[10:40] <seb128> the key name is misleading
[10:40] <seb128> it's actual system-default-configuration-file
[10:41] <seb128> the user location is not configurable but used anyway ;-)
[10:41] <wendar> ok, removed ~/.config/monitors.xml, trying again
[10:41] <pitti> wendar: did you chmod 644 back both plugins?
[10:42] <wendar> pitti: yes
[10:43] <wendar> pitti: and, bug is gone with nuked monitors.xml, but xrandr and power on
[10:43] <seb128> wendar, does using xrandr manually to apply a resolution trigger the bug?
[10:44] <wendar> seb128: example command line to try?
[10:44] <seb128> not sure ... xrandr --auto? ;-)
[10:44] <seb128> do you use a laptop screen, an external one?
[10:44] <wendar> no external screen
[10:45] <wendar> (except for presentations)
[10:45] <rodrigo_> hmm, so removing ~/.config/monitors.xml fixed the problem?
[10:45] <wendar> seb128: xrandr --auto doesn't trigger the problem
[10:45] <wendar> rodrigo_: yes
[10:45] <seb128> wendar, xrandr --output LVDS --mode 1024x768
[10:45] <seb128> or whatever resolution is yours?
[10:45] <rodrigo_> I guess it's a driver problem indeed, maybe it's not detecting correctly a specific monitor
[10:46] <rodrigo_> wendar, did you keep a copy of that monitors.xml file?
[10:46] <wendar> rodrigo_: of course, I just moved it to another directory
[10:46] <wendar> rodrigo_: would you like a copy?
[10:46] <rodrigo_> wendar, yes please
[10:47] <seb128> wendar, you can probably just try to use the session menu, display panel to apply a resolution and see if that triggers the bug
[10:48] <rodrigo_> yes
[10:49] <wendar> seb128: oooh, using the display panel does trigger it
[10:49] <seb128> wendar, what about "xrandr --output LVDS --mode 1024x768"
[10:49] <wendar> seb128: (still, even with no monitors.xml)
[10:49] <seb128> or whatever resolution your tried in the graphical ui
[10:49] <seb128> wendar, well, you probably have a monitors.xml now
[10:49] <seb128> wendar, that panel is what writes this config
[10:50] <seb128> looks like a driver bug
[10:50] <wendar> seb128: that gives me "warning: output LVDS not found; ignoring"
[10:50] <seb128> xrandr screws things
[10:50] <seb128> wendar, it might be LVDS1 if you are on intel dkms
[10:50] <seb128> wendar, look in the "xrand" log how the active output is called
[10:50] <pitti> just run "xrandr" to see the available outputs
[10:50] <wendar> seb128: yes, it's been recreated, but it's not the same old corrupt one (whatever was wrong with it)
[10:51] <seb128> wendar, I don't think it was wrong or corrupted
[10:51] <seb128> it just seems something in xorg doesn't like xrandr calls
[10:51] <seb128> i.e that you hit a bug when the resolution is changed with xrandr
[10:51] <wendar> pitti: ah, it gives me LVDS1
[10:52] <wendar> seb128: so I do trigger the same bug with
[10:52] <wendar> xrandr --output LVDS1 --mode 1024x768
[10:52] <seb128> ok
[10:52] <seb128> so what I said
[10:52] <seb128> xorg or driver issue
[10:52] <seb128> it just happens that GNOME applies stored config using xrandr at login time
[10:53] <rodrigo_> yes, seems so
[10:54] <rodrigo_> wendar, do you have anything under ~/.xrandr ?
[10:54] <wendar> rodrigo_: nope, no such directory
[10:55] <wendar> I guess bryceh will be up in 5-6 hours
[10:55] <rodrigo_> sorry, ~/gsd-debug-randr.log
[10:56] <seb128> rodrigo_, you need to create a file to get that log IIRC
[10:56] <wendar> rodrigo_: don't have that file either
[10:56] <seb128> rodrigo_, but "xrandr" triggers the same bug
[10:56] <didrocks> pitti: hey, I will need your help for a SRU question after a discussion with njpatel for bug #841750
[10:56] <ubot2> Launchpad bug 841750 in unity "Dash - horizental divider line in between categories incorrectly drawn" [Medium,In progress] https://launchpad.net/bugs/841750
[10:56] <didrocks> pitti: see the merge req: https://code.launchpad.net/~macslow/unity/unity.fix-841750-2/+merge/78809.
[10:56] <rodrigo_> seb128, that's where the xrandr g-s-d plugin writes, as I can see in the code
[10:57] <njpatel> pitti, basically it makes it always draw instead of sometimes (it was being drawn outside of clip, hence x/y change), but also dims it by 0.05
[10:57] <didrocks> pitti: I agree that in some case, the line isn't shown, so maybe moving it tiny. I utterly disagree with the color change, even if told "not noticeable", if it's "not noticeable", so "don't push it"
[10:57] <njpatel> it = separator, sorry
[10:57] <njpatel> didrocks, it's noticeable from a design sense, I meant that it doesn't effect docs
[10:58] <wendar> pitti, seb128, rodrigo_: this is non-critical for release?
[10:58] <didrocks> for a SRU? If we start pushing design change in SRU, it's road to crazyness
[10:58] <seb128> wendar, no it's not, it's specific to your hardware
[10:58] <seb128> wendar, it's a bit unfortunate and annoying but not a blocker
[10:58] <pitti> wendar, seb128: it might also be related to the SRU that RAOF is about to upload (libgnome-desktop3)
[10:58] <wendar> seb128: yup, so I won't worry about it, but will check in with bryce when he's up
[10:59] <pitti> http://launchpadlibrarian.net/81934986/gnome-desktop3_3.2.0-0ubuntu3_3.2.0-0ubuntu4.diff.gz might be related to it
[10:59] <seb128> wendar, thanks
[10:59] <wendar> pitti: will try that and see if it resolves the issue
[10:59] <pitti> unfortunately the patch which got uploaded there got reverted by that silly debian-changes* patch
[10:59] <wendar> pitti, seb128, rodrigo_: thanks!
[11:00] <pitti> wendar: so you could reinstall that broken config, apt-get source gnome-desktop3, quilt pop -a, drop teh debian-changes patch, rebuild, and check if that makes a difference
[11:00] <pitti> (and meh @ UDD)
[11:00] <seb128> rodrigo_, I'm pretty sure g-s-d only writes that log file if the file is on disk (or another file is on disk), I've debugged xrandr bugs with federico before where he asked me to create a file to have the debug output
[11:01] <seb128> pitti, UDD :-(
[11:01] <rodrigo_> seb128, ah ok, didn't know
[11:01] <pitti> didrocks: so on https://launchpadlibrarian.net/81808065/dash_divider%20lines%20wrong1.png it's the slightly thicker ends of the lines?
[11:01] <pitti> didrocks: no need to spend time on color changes indeed, IMHO
[11:01] <didrocks> pitti: that's my guess, MacSlow|lunch can confirm
[11:02] <didrocks> pitti: what do you mean, should we let the color change in?
[11:02] <pitti> didrocks: but if it's that subtle, I don't think ubuntu-sru would violently veto it
[11:02] <seb128> rodrigo_, you need to create a file "gsd-debug-randr" to get the log apparently from the old bug comments I read
[11:02]  * didrocks thinks we really open the pandora box, but oh well
[11:02] <pitti> didrocks: if it only slightly changes colors, I think "whatever is easier for you"
[11:02] <pitti> didrocks: (not in general, though; SRUs are not for that kidn of fixing)
[11:02] <seb128> lunch, bbiab
[11:03] <pitti> didrocks: if you fell better about dropping that change, pleaes do
[11:03] <didrocks> pitti: I'm afraid it open the gate to it, but again, I'm just a puppet there
[11:03] <rodrigo_> seb128, right, it checks for that file indeed, didn't see it when looking at the code
[11:03] <didrocks> njpatel: ok, you can push to 4.0 branch then ^
[11:04] <pitti> didrocks: oh, I thought it was already
[11:04] <njpatel> pitti, no, it's still proposed
[11:04] <pitti> didrocks: fixing the line ends sounds good and desirable to me, so +1 from me on that part
[11:04] <pitti> but SRUs are not the place for design changes
[11:05] <njpatel> this is the only UI tweak on SRU list, it's just dimming it by 0.05 so it looks nicer on some backgrounds (/me found out why :)
[11:05] <pitti> ack
[11:05] <Wellark> mvo: I've got little something for you :)
[11:05] <Wellark> https://launchpad.net/bugs/871691
[11:05] <ubot2> Launchpad bug 871691 in update-notifier "update notifier message too long on display" [Undecided,Confirmed]
[11:06] <mvo> Wellark: woah
[11:09] <Wellark> mvo: indeed :)
[11:15] <rodrigo_> brb
[11:19] <wendar> other random question: is it a "feature" that the drop-down menu for recent files in gedit no longer lists any files?
[11:25] <seb128> wendar, it does for me
[11:26] <seb128> wendar, well, define "drop down", the file menu you mean?
[11:26] <wendar> seb128: shows a list of recent files?
[11:26] <seb128> yes
[11:26] <wendar> seb128: the down arrow next to the "Open" button on the top of the window
[11:26] <wendar> for me it always says "No files found"
[11:27] <seb128> wendar, http://ubuntuone.com/76bELPEUH0hfzKzbNolX7x
[11:27] <wendar> seb128: yup, that's the one
[11:28] <seb128> wendar, do you have a .local/share/recently-used.xbel?
[11:29] <wendar> seb128: yup
[11:29] <seb128> wendar, does it have entries with "<bookmark:group>gedit</bookmark:group>"
[11:30] <mvo> Wellark: I can reproduce will look at it in a sec
[11:30] <wendar> seb128: several
[11:30] <seb128> wendar, ok, weird that gedit doesn't list those then... how do you start it?
[11:30] <wendar> seb128: tried both from the Launcher and from the command-line, same effect
[11:30] <ogra_> works here too btw
[11:31] <Wellark> mvo: cool! have your time :)
[11:31] <seb128> wendar,
[11:31] <seb128> $ strace gedit 2>&1 | grep recently
[11:31] <seb128> wendar, can you try this and see what files it lists?
[11:33] <wendar> seb128: for some reason, that opens gedit, but piping through less doesn't
[11:33] <seb128> wendar, it doesn't print anything?
[11:33] <seb128> $ strace gedit 2>&1 | grep recentlyopen("/home/seb128/.local/share/recently-used.xbel", O_RDONLY|O_LARGEFILE) = 12
[11:33] <wendar> seb128: it prints "chmod("/home/allison/.local/share/recently-used.xbel", 0600) = 0"
[11:33] <seb128> wendar, that's what I get there
[11:34] <seb128> wendar, hum
[11:34] <seb128> wendar, ls -ld /home/allison/.local/share
[11:34] <seb128> wendar, ls -l /home/allison/.local/share/recently-used.xbel
[11:34] <seb128> wendar, it seems you have wrong permissions on the dir or files
[11:34] <wendar> -rw-------
[11:34] <seb128> the dir or the file?
[11:35] <wendar> -rw------- 1 allison allison
[11:35] <seb128> i.e the first or second command?
[11:35] <wendar> the file
[11:35] <wendar> drwxr-xr-x 15 allison allison
[11:35] <seb128> that seems correct
[11:36] <seb128> wendar, I'm surprised you don't get an "open" line first in strace
[11:38] <seb128> wendar, did you have any gedit open when you run the command?
[11:38] <seb128> can you close all instances
[11:38] <seb128> run "strace gedit 2>log"
[11:38] <seb128> close it after opening it
[11:38] <seb128> less log
[11:38] <seb128> use "/recently"
[11:39] <seb128> and see what it matches and if there are any error before
[11:39] <seb128> wendar, other option is that /home/allison/.local/share/recently-used.xbel somewhat is corrupted, you can maybe try to move it away, open a file and see if the menu gets updated
[11:46] <wendar> seb128: well, opening the file in vim doesn't show any results for "recently"
[11:47] <wendar> will try removing the file
[11:47] <seb128> wendar, the strace log you mean?
[11:48] <seb128> wendar, do you have any "inotify_add_watch(9, "/home/allison/.local/share""
[11:48] <seb128> I wonder if it hits an issue putting the monitor on .local/share for you
[11:50] <wendar> seb128: I'm running backwards through the tips...
[11:50] <wendar> so strace gedit log shows:
[11:50] <wendar> open("/home/allison/.local/share/recently-used.xbel", O_RDONLY) = 12
[11:51] <seb128> ok, so it does open it, great, that's a good start
[11:51] <wendar> and also has the inotify_add_watch for the directory
[11:52] <seb128> wendar, ok, so that's normal, I was getting confused by the lack of open call you had before
[11:53] <wendar> seb128: on the other trial, moving .local/share/recently-used.xbel away has no effect on gedit
[11:54] <wendar> seb128: but, it does empty out the "Recently Used" option in the file picker dialog
[11:54] <seb128> wendar, so you run gedit, ctrl-O, open a file, and the menu is still empty?
[11:55] <wendar> seb128: it was when I removed recently-used.xbel, but it's generally fine
[11:55] <wendar> the only problem is the little "shortcut" button
[11:55] <seb128> wendar, right, that one stays empty after you open a file still?
[11:55] <wendar> seb128: yup
[11:55] <seb128> :-(
[11:56] <seb128> does recently-used.xbel gets written with the file you opened?
[11:57] <wendar> seb128: yes, the file is added to a freshly created recently-used.xbel
[11:57] <seb128> wendar, ok, I'm sorry but I'm not sure what's going on, the fileselector correctly use recently-used.xbel from what you said so the file can be read and parsed, not sure why the small toolbar menu doesn't work
[11:58] <seb128> wendar, the small menu next to the "open" toolbar icon works fine there for me with my user or in a guest session
[11:58] <seb128> wendar, do you get a "no entry found" label in the menu or just no menu at atll?
[11:59] <wendar> seb128: it drops down with "No items found"
[11:59] <seb128> wendar, ok, well you can restore your old recently-used.xbel
[11:59] <pitti> seb128: attach_gsettings_{package,schema} added to apport trunk FYI -- XDG_CONFIG_HOME=/nonexisting gsettings list-recursively... did the trick
[11:59] <seb128> wendar, I'm out of idea for now on why it's buggy for you but I will ping you later if I get a new one
[12:00] <seb128> pitti, \o/
[12:00] <wendar> seb128: okay, thanks
[12:00] <seb128> pitti, well done
[12:00] <seb128> wendar, but if that's of any consolation it's a bug and it doesn't seem to happen to others
[12:00] <seb128> i.e not something broken for everybody
[12:02] <mpt> Am I imagining this, or is the "Keyboard" gnome-control-center panel, accessed from the keyboard indicator, a panel that you can't actually access from the g-c-c home screen?
[12:03] <mpt> oh, no, g-c-c has separate "Keyboard" and "Keyboard Layout"
[12:03] <mpt> how silly
[12:04] <seb128> mpt, it's silly but the "keyboard layout" upstream is in the "region" capplet which we hides because we use language-selector
[12:05] <seb128> mpt, it's on the precise list of polish we want to do
[12:05] <mpt> seb128, right, that's what I'm working on, and stumbled across this :-)
[12:05] <seb128> though "keyboard layout" should probably be under "keyboard" rather than region?
[12:05] <mpt> you'd think
[12:06] <seb128> mpt, btw not sure if you are the right one but I would welcome design input on "screen locking: when and for what users", we will have a session on that at UDS and I dropped an email about it on the desktop list
[12:07] <seb128> mpt, i.e define for what user we do locking by default (i.e do we do it for autologged users), how do you allow users to tweak the behaviour
[12:08] <seb128> etc
[12:09] <mpt> seb128, I agree it would make a lot of sense to have the keyboard settings together. But in Windows keyboard layout is under "Region and Language" and in OS X it's under "Language & Text", both far away from other keyboard options. In OS X it makes *slightly* more sense because one of the text input options is entering Chinese characters by drawing on the touchpad (i.e. not using keyboard at all) ... but still.
[12:10] <seb128> mpt, well maybe "keyboard" should have a least a link to the region tab for the keyboard layout then ;-)
[12:10] <mpt> yeah, cross-references FTW
[12:10] <mpt> It's another example of how settings don't have clear categories (e.g. where do you draw the line between desktop background <-> screensaver <-> screen blanking <-> screen dimming <-> power settings)
[12:11] <seb128> right...
[12:13] <mpt> seb128, I saw the message about screen locking, I think we need a spec for "sessions" in general, e.g. whether an admin should be able to unlock someone else's session, what happens if you shut down while other people are logged in, what the session inhibit dialog should look like, etc
[12:14] <chrisccoulson> an admin can already unlock someone elses session
[12:14] <mpt> What should happen if you go to log out after saving something in a guest session
[12:14] <chrisccoulson> sudo killall gnome-screensaver :P
[12:15] <seb128> mpt, do you want to suggest the topic on the list? ;-)
[12:15] <seb128> I'm trying to get other people than me suggesting topic :p
[12:15] <mpt> seb128, no, I'm not interested in discussing it at UDS, it's not the sort of thing that benefits from a 55-minute fishbowl
[12:16] <seb128> mpt, ok, fair enough, well as said I want design input rather than an UDS session
[12:16] <mpt> well, maybe there could be a brainstorming session, but it's a bit of an esoteric topic :-)
[12:16] <mpt> ok
[12:18] <MacSlow> didrocks, pitti: how that's suppose to happen I don't know... I've never seen this... the lines are certainly drawn being only 1 pixel wide.
[12:25]  * rodrigo_ lunch
[13:40] <chrisccoulson> it's wrong to have an "Arch: all" package installing stuff in to /usr/lib isn't it?
[13:40] <seb128> chrisccoulson, usually yes
[13:41] <chrisccoulson> seb128, thanks. i guess i need to make ubufox "Arch: any" now then, even though it really isn't
[13:41] <chrisccoulson> i need to move it to the firefox $libdir to stop it from being disabled by default
[13:42] <chrisccoulson> which sucks ;)
[13:42] <pitti> chrisccoulson: more to the point, it's considered bad to install architecture neutral files into /usr/lib/
[13:43] <pitti> chrisccoulson: does lintian actually complain if an all package installs stuff into /usr/lib? all python packages place symlinks there
[13:43] <chrisccoulson> pitti - i do that already for firefox. but in any case, i need to install extensions in to /usr/lib/firefox/extensions
[13:43] <chrisccoulson> and this folder can contain binary extensions as well as arch-independent ones
[13:46] <pitti> chrisccoulson: I don't think an arch:all package would be terribly wrong there
[13:48] <chrisccoulson> pitti - so you think i should keep ubufox as arch:all for now (although i still need to move it to /usr/lib/firefox-addons/extensions)?
[13:48] <pitti> chrisccoulson: yes
[13:48] <chrisccoulson> i guess if we want a multi-arch aware firefox at some point, i'd need to make it arch:any
[13:50] <chrisccoulson> pitti - i get lintian warnings for firefox btw (for the icons)
[13:51] <chrisccoulson> if we make firefox multi-arch in the future, then i would move those to a firefox-common package and put them in the right place
[13:52] <chrisccoulson> but i'm not sure of any benefits of doing those now (other than to make the warnings go away)
[15:06]  * kenvandine waves
[15:06] <seb128> hey kenvandine
[15:06] <seb128> isn't topic a national holiday for you?
[15:06] <kenvandine> yes
[15:07] <kenvandine> :)
[15:07] <seb128> ;-)
[15:07] <seb128> how are you?
[15:07] <kenvandine> just replying to a few emails before i get started working on our cars :-D
[15:07] <kenvandine> great, and you?
[15:08] <seb128> I'm fine thanks
[15:08] <seb128> kenvandine, btw I assigned you some telepathy-indicator bugs the other days, not sure if you watch the product or not
[15:08] <seb128> it has a bunch of segfault bugs
[15:10] <kenvandine> yeah, i have a branch fixing at least one of them waiting for review
[15:11] <kenvandine> i haven't looked at the others yet
[15:29] <seb128> ok, first install of the CD worked great
[15:29] <pitti> bbl
[15:29] <seb128> (i386 in install mode using a specific partition without internet)
[15:29] <seb128> seems a good start ;-)
[16:51] <seb128> mvo, stupid question but is it normal that the partner archive is not enabled by default?
[16:55] <pitti> seb128: s-c enables it on demand, doesn't it?
[16:56] <seb128> pitti, well "on demand" means you need to know that what you want to use is in there?
[16:56] <seb128> I was just wondering if there is any reason it's not enabled by default
[16:57] <pitti> app-install-data-ubuntu doesn't have it?
[16:57] <pitti> oh, apparently not
[16:57] <seb128> I should start using graphical uis :p
[16:58] <seb128> in fact I just try to sudo apt-get install adobe<tab><tab> on my new install
[16:58] <seb128> which didn't work until I enabled partner in software-properties
[16:58] <pitti> right; but ISTR that it magically worked in s-c
[16:59] <seb128> ok, ignore me then, will teach me to want to be efficient and use the command line :p
[17:03] <pitti> still a valid question, of course
[17:15] <didrocks> ok, enough unity testing written for today, time for some exercice :)
[17:16] <pitti> didrocks: thanks, bye didrocks
[17:16] <didrocks> see you tomorrow!
[17:43] <jbicha> seb128: I have a simple fix for bug 840858 ready, really just removing the patch we applied earlier this release cycle
[17:43] <ubot2> Launchpad bug 840858 in gnome-control-center "No obvious way to disable Ubuntu startup sound" [Low,Confirmed] https://launchpad.net/bugs/840858
[17:45] <seb128> jbicha, i.e make that list have one entry "startup sound" by default?
[17:45] <seb128> it's pretty confusing on the message it gives to users on what the list is about and why other entries got dropped
[17:46] <jbicha> yelp help:ubuntu-help/session-loginsound
[17:47] <jbicha> ^ out of date for Oneiric but that's how it worked in Natty
[17:47] <jbicha> I think the theory at UDS-O was that we would hide the Startup Apps that it didn't make sense for typical users to disable
[17:50] <jbicha> hmm, Startup Applications has another broken help button
[17:53] <seb128> jbicha, well the theory was that we would hide "services" and let it be what the title claim, i.e startup *applications* ;-)
[17:54] <seb128> jbicha, the login sound is not really an application
[17:54] <seb128> i.e that dialog should be how you autostart your email client at login if you want to do that
[17:56] <seb128> dinner time, bbl
[18:17] <jbicha> seb128: ok, simple fix for bug 871484 should that get uploaded in oneiric-proposed or what?
[18:17] <ubot2> Launchpad bug 871484 in gnome-utils "gnome-screenshot help missing" [Low,Confirmed] https://launchpad.net/bugs/871484
[18:18] <seb128> jbicha, let's try to get it upstream for 3.2.1
[18:18] <seb128> or in the vcs for the next upload
[18:18] <seb128> i.e no need to do an upload now but when 3.2.1 is out we can sru the new version with the fix
[18:23] <jbicha> seb128: sounds good
[18:23] <pitti> seb128: oh, seems you kicked off quite some discussion :)
[18:24] <seb128> pitti, yeah, I'm in the mood for that this week :p
[18:47] <jbicha> pitti: what do you think about python plugins being broken in Totem? bug 855100
[18:47] <ubot2> Launchpad bug 855100 in totem "python plugins not working" [Undecided,Confirmed] https://launchpad.net/bugs/855100
[18:48] <pitti> jbicha: well, obviously I think it's bad :)
[18:48] <pitti> worth an SRU
[18:48] <pitti> jbicha: a reproduction recipe might be handy, though, as normally totem doesn't spit out these errors
[18:49] <pitti> I just tried a youtube search which worked (probalby isn't python)
[18:50] <jbicha> pitti: Totem>Edit>Plugins and just start checking boxes (it's related to libpeas)
[18:51] <jbicha> you had done a bit of work with libpeas recently so I thought you might have an idea about what's wrong
[18:52] <jbicha> maybe it was fixed in Totem 3.2
[18:52] <pitti> jbicha: no time to look at it yet
[18:52] <pitti> jbicha: yes, libpeas works fine now with gedit, I suppose the python plugins in totem itself don't get along with new pygobject
[18:53] <pitti> pretty sure that 3.2 will fix it, so we can do some backporting there
[18:53] <jbicha> pitti: no problem, other things are more important
[19:58]  * pitti sets up new image builds and waves good night
[21:17] <bjsnider> jbicha, just refreshed patches and built totem 3.2, installed it, and i can check the python console button without issue
[21:19] <jbicha> bjsnider: right, Totem 3.0 used the old pygobject which I don't believe works any more
[21:23] <jbicha> but it's probably not too difficult to port to the new style


[00:09] <LinuxGuy2009> Hey guys Im not having any luck with diagnosing a major bug on my mom and dads machine. Everytime they get online with firefox or chromium the screen will randomly blank out and they have to hit the power button and start over. They can't browse much at all. They just asked me to put Jaunty back on. I really could use some help in diagnosing and fixing the issue. I really want them to keep Lucid cause its been so good on other machi
[00:09] <LinuxGuy2009> Could someone take the time?
[00:11] <arand> LinuxGuy2009: "Blank Out" Could use some specifying, for one..
[00:11] <LinuxGuy2009> arand: Blank, black, empty.
[00:12] <LinuxGuy2009> arand: no apps, no panels, nothing. No TTYs can be seen with CTRL+ALT and F keys
[00:12] <LinuxGuy2009> Intel graphics on an IBM P4 system
[00:12] <arand> LinuxGuy2009: Hmm, blank indeed :/
[00:13] <arand> LinuxGuy2009: Does ctrl+alt+del reset it? does alt+sysreq+REISUB work?
[00:13] <LinuxGuy2009> I don't even know where to start. I had the error message wrote down but my dad threw it away of course. I got an error message when booting Lubuntu I figured it would be pretty much the same.
[00:13] <arand> Just seing if the kernel still responds
[00:14] <LinuxGuy2009> arand: What is reisub?
[00:14] <arand> !reisub
[00:14] <ubot2> In an emergency, you may be able to shutdown cleanly and reboot by holding down Alt+PrintScreen and typing, in succession, R, E, I, S, U and B. For an explanation, see http://en.wikipedia.org/wiki/Magic_SysRq_key
[00:15] <LinuxGuy2009> arand: Ok ill try that right now. Have to get it to crash first. Might be a few minutes. Ill be back.
[00:16] <arand> If that works, at least the kernel still responds, if not, well then you might at least be able to blame the kernel for crashing.
[00:16] <LinuxGuy2009> ok
[00:17] <LinuxGuy2009> Ok I told my dad to jump on and try and get it to black out again so I can try the REISUB.
[00:17] <LinuxGuy2009> arand: I apreciate you taking the time!
[00:18] <arand> Note that I'm only able to give very loose, general hints on debugging, I know far too little about it, but maybe enough that you can at least get some material for a bug report...
[00:19] <LinuxGuy2009> arand: That would help a lot Im sure.
[00:22] <LinuxGuy2009> arand: Ok CTRL+ALT+Del made it reboot instantly. As soon as I did that I saw the purple ubuntu screen.
[00:22] <LinuxGuy2009> arand: What to do from here.
[00:23] <LinuxGuy2009> arand: Think it might be the kernel?
[00:23] <arand> LinuxGuy2009: Right, so not specifically the kernel, I'm searching LP, and Bug #541492 for example might be something...
[00:23] <ubot2> Launchpad bug 541492 in xserver-xorg-video-intel (Ubuntu Lucid) (and 2 other projects) "MASTER: [i845] GPU lockup (apport-crash) (Should KMS be blacklisted?) (affects: 40) (dups: 22) (heat: 360)" [High,Triaged] https://launchpad.net/bugs/541492
[00:23] <LinuxGuy2009> arand:Ok thanks
[00:24] <micahg> arand: LinuxGuy2009: if you have an X or kernel bug, please file a new bug even if it looks that same and note the similar bug in your report
[00:24] <arand> LinuxGuy2009: "It happens all the time now. Sometimes when I click a new link, sometimes when I open a new program or whatever. The screen doesn't get signal from the GPU anymore and complains." Sound pretty similar, right?
[00:24] <LinuxGuy2009> arand: Yeah the i845 is the exact video chipset.
[00:25] <LinuxGuy2009> arand: Yeah pretty much. They only browse online and dont run anything else to verify but yeah that sounds dead on what they have.
[00:25] <LinuxGuy2009> arand: Looks like there is a driver in the PPA should I try that?
[00:26] <arand> LinuxGuy2009: Might be worth a shot, make sure to read what people are saying about it though.
[00:26] <LinuxGuy2009> arand: Ok cool
[00:35] <arand> LinuxGuy2009: https://wiki.ubuntu.com/X/Bugs/Lucidi8xxFreezes is full of "workarounds, I've no idea if any of them are relevant though..
[00:35] <LinuxGuy2009> arand: Ok Ill take a look
[00:39] <LinuxGuy2009> arand: I'd like to try downgrading the kernel to 2.6.31 how do I do that? Do I need to manually download a kernel package from like jaunty or karmic and install that and remove the others?
[00:40] <LinuxGuy2009> That was one of the suggestions
[00:41] <micahg> LinuxGuy2009: that will probably break a lot of stuff
[00:42] <LinuxGuy2009> micahg: Ok. How would I safely downgrade it? Is that a bad idea alltogether?
[00:42] <micahg> LinuxGuy2009: I would think it's a bad idea, why do you want to do it?
[00:43] <LinuxGuy2009> micahg: Intel i845 lockups. https://wiki.ubuntu.com/X/Bugs/Lucidi8xxFreezes
[00:43] <micahg> LinuxGuy2009: I thought there's a boot flag to disable KMS
[00:43] <LinuxGuy2009> Kernel downgrade to 2.6.31 is mentioned here. https://wiki.ubuntu.com/X/Bugs/Lucidi8xxFreezes
[00:44] <LinuxGuy2009> micahg: Should I try that first?
[00:45] <micahg> LinuxGuy2009: oh, maybe in your case it's to enable KMS
[00:45] <micahg> LinuxGuy2009: the new intel driver doesn't help?
[00:45] <LinuxGuy2009> micahg: I'm here asking what to do. Havent tried anything yet.
[00:46] <LinuxGuy2009> micahg: What would you recomend I try first?
[00:46] <micahg> LinuxGuy2009: video driver would be my first thing to try, then, enable/disable KMS
[00:46] <LinuxGuy2009> micahg: The driver in the PPA as mentioned?
[00:47] <micahg> LinuxGuy2009: yeah, new video drivers can sometimes help
[00:47] <micahg> LinuxGuy2009: just be familiar with the cli in case it fails
[00:47] <LinuxGuy2009> micahg: Ok Ill do that right now and Ill be back. Yeah i am. Thanks.
[00:48] <arand> LinuxGuy2009: From what people are saying in the bug, though, it seems that the "use vesa instead" seemed to be the working one... Although that will pretty much get you on crappy generic drivers, but stable, possibly. I would (after micahg's suggestions) look into the Brian Roger's experimental PPA, and as a fallback, and as a fallback try the donwgraded one from the x-retro PPA or set it as vesa (although those won't help towards diagnosing
[00:53] <LinuxGuy2009> The PPA for the driver is an old driver it turns out. Already has a newer one installed.
[00:53] <LinuxGuy2009> So should I try the KMS workaround?
[00:54] <micahg> LinuxGuy2009: this has a later driver than Lucid: https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-updates
[00:54] <LinuxGuy2009> micahg: Ok Ill check that.
[01:16] <LinuxGuy2009> Ok the driver was way worse than the other. Couldnt even boot to a desktop. So i uninstalled it and put the official package back in. Now Im about to try out the KMS workaround. If it ends up worse do I just change the part that says modeset=1 back to modeset=0?
[01:18] <micahg> LinuxGuy2009: you can test by editing the boot line and not editing the file on the disk
[01:19] <LinuxGuy2009> So here is the directions I see. What would I do for an i845 to test it?
[01:19] <LinuxGuy2009> https://wiki.ubuntu.com/X/Bugs/Lucidi8xxFreezes
[01:19] <micahg> LinuxGuy2009: idk actually :(, maybe ask in #ubuntu-x if the wiki isn't clear or no one else can help
[01:21] <arand> LinuxGuy2009: I recall there being a "nomodeset" for disabling it ...
[01:24] <arand> LinuxGuy2009: "i945.modeset=0" /1 seems to be another way ...
[01:27] <LinuxGuy2009> Ok I did the KMS workaround and my dad is browsing away. Crossing my fingers.
[01:50] <LinuxGuy2009> Well that didnt work unfortunately. I think they are kinda getting tired of Lucid. Might just have to put Jaunty back on for them again.
[01:52] <LinuxGuy2009> Maybe by 10.04.1 point release it will be fixed.
[02:34] <rww> ubottu: bug 569285
[02:34] <ubot2> Launchpad bug 569285 in empathy (Ubuntu) ""[person] has joined the room" when one joins an IRC channel (affects: 1) (heat: 6)" [Low,Incomplete] https://launchpad.net/bugs/569285
[02:35] <rww> I reported this about a month ago and can no longer reproduce it, and it isn't confirmed by an upstream report or someone else on LP. Should I mark it invalid?
[02:36] <micahg> rww: yes, if you believe it's no longer an issue
[02:36] <rww> micahg: alright. thanks :)
[04:34] <anoteng> anybody here familiar with git-bisecting a kernel?
[07:45] <mtx_init> Hey guys, Ive been having a problem for a white, have looked in the other channel a few times, but with no avail.  It seems only with Ubuntu, sometimes when I do a cold boot, everything is really laggy and jittery.  A reboot solves the problem.  any idea what it could be?
[08:04] <anoteng> mtx_init, check dmesg or /var/log/messages when you're having problems, might give some clues..
[08:04] <mtx_init> ok will do in the morning
[08:05] <anoteng> and please file a bug report if this turns out to be a problem with ubuntu (ie. not broken hw or some config you changed)
[08:06] <mtx_init> I will, I know it is Ubuntu specific, because it only happens with Ubuntu and has since 7.10.  Doesnt occur on FreeBSD, fedora, Arch or Window's
[08:06] <mtx_init> thanks again.
[09:07] <BUGabundo_remote> sleep check,clothes check,Monday start ohhhh
[09:31] <qense> https://wiki.ubuntu.com/BugSquad/Mentors updated
[09:32] <snadge> anyone else have c1e (new processor power saving feature) enabled?
[09:33] <ddecator> thanks qense :)
[09:34] <qense> :)
[09:35] <qense> good morning vish
[09:36] <vish> qense: hey :)
[09:38] <ddecator> looks great qense
[09:38] <ddecator> heya vish
[09:39] <qense> ddecator: Thanks. I mailed it to you already, but if you think some things need to be changed to that page in order to make it fit in with the rest, please do, as long as the original message of the wiki page doesn't get distorted.
[09:39] <ddecator> qense: sure thing. i can't think of anything atm that could be improved, but i'll keep that in mind. thanks :)
[09:39] <qense> good
[09:40] <vish> ddecator: o/
[09:40] <vish> qense are all the mentors listed the latest or the old ones?
[09:42] <qense> vish: The mentors that are currently listed at <https://wiki.ubuntu.com/BugSquad/Mentors> are the ones that once said during the past cycle they would like to mentor. They all should be admins of <https://launchpad.net/~bugsquad-mentorship>. However, since almost no one is actively mentoring we're reviewing the list and will probably be removing some of the people from the list.
[09:43] <qense> The old list -- which is currently the same as the new -- can be found at <https://wiki.ubuntu.com/BugSquad/Mentors.backup>.
[09:43] <qense> Pedro will mail all students and mentors to see whether they still want to be mentored or mentor.
[09:44] <qense> vish: The list on the main wiki page will mostly be maintained by the mentorship admins.
[09:44] <ddecator> he already sent out one to the mentors
[09:44] <vish> neat!
[09:45] <qense> vish: The new approach is that the mentorship admins are going to assign students to mentors, because letting the mentors pick students didn't work.
[09:47] <vish> hmm , the monitor display settings are part of gnome-settings-daemon or... ?
[09:48] <ddecator> depends. nvidia has it's own program that handles display settings
[09:49] <vish> ddecator: otherwise its g-s-t, right?
[09:49] <vish> ddecator: bug is about a user wanting an option to set the default monitor in a mutlimonitor setup
[09:50] <vish> multi-monitor*
[09:51] <ddecator> possibly w/e package has the monitor preferences in it? not sure it that's g-s-t or not (if i try to use any of the gnome packages that handle display settings, i get a warning saying i need to use the nvidia app...)
[09:52] <ddecator> s/it/if
[09:53]  * BUGabundo_remote just figure he had the window scrolled up, and was wondering why this one was blinking
[09:53] <vish> ddecator: well , reporters dont usually give the hardware info, do they .. ;p  we have to ask :s
[09:54] <ddecator> vish: that's where apport comes in handy ;)
[09:54] <ddecator> unless it's not against any package...
[09:54] <vish> ddecator: yeah , they dont use that either ;) /me uses collect-it reply template! ;)
[09:55] <ddecator> even apport-collect will add the info if there is a hook, but there needs to be a hook for it
[10:46] <snadge> https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/566449
[10:46] <ubot2> Launchpad bug 566449 in pulseaudio (Ubuntu) "No Sound Through USB Headset (affects: 2) (heat: 12)" [Undecided,Incomplete]
[10:48] <snadge> new to bug reporting, it seems lucid has introduced zero volume on usb headsets bug.. you can clearly see from the Card1.Amixer.values.txt attachment.. has its volume set to 0% .. and numerous me too posts, but this bug is still "undecided,incomplete"
[10:50] <snadge> you can adjust the volume with alsamixer.. but the sound properties app has no effect.. this additional information is missing from this bug report.. i should just sign up and mention this? :P
[11:08] <bbordwell> Sorry for cross channel posting, but since there are alot more users in here. Is anyone willing to help me upload my first package to a PPA? I am having trouble figuring it out
[11:11] <persia> Unfortunately, this isn't a better target channel :)
[11:22] <snadge> yeah they dont even talk about bugs in here ;)
[11:23] <persia> snadge: What?  We're happy to talk about bugs.
[11:24] <snadge> im joking i added additional information to the bug i posted earlier.. and im presuming that was the right thing to do :P
[11:30] <persia> Generally, yes.
[11:32] <aburch> https://wiki.ubuntu.com/Bugs/Responses#Incomplete bugs without a response from submitter
[11:32] <aburch> Didn't I read here a few days ago that changing bug status from Invalid to something else is no longer possible for regular users?
[11:34] <persia> aburch: best test to confirm.  staging,launchpad.net is a safe place to do that (DB is overwritten regularly, no mail interface exists)
[11:40] <aburch> Hmm, seems still possible.
[11:41] <persia> Well then, if you read it before, the statement may not have been correct :)
[11:41] <snadge> so why is the bug i mentioned earlier still incomplete?
[11:41] <aburch> And one more of my packages no longer has an open bug in Ubuntu :)
[11:43] <persia> snadge: Bug status only changes from manual action.  Either adjust the status to something more suitable yourself, or wait for someone else to examine the bug.
[11:48] <snadge> i have the ability to confirm it? amazing
[11:49] <snadge> oh and say that it effects me and subscribe to it.. cool ;)
[11:52] <persia> snadge: Please feel free to look for other bugs you can confirm, or improve :)
[11:53] <snadge> the alsa people are understandably not happy with the pulseaudio situation, and whats happening with gnome
[11:53] <snadge> difficult to get support from them these days when you mention ubuntu
[11:54] <persia> Which bit makes them unhappy?  Last I heard, lots of improvements were happening to ALSA to improve the pulse experience.
[11:54] <snadge> one of the guys in the appears to be using gentoo and was dismayed when gnome completely yanked the volume control applet.. and replaced it with one which depends on pulseaudio ;)
[11:56] <persia> I thought the old code was still available, if someone wanted to run it.
[11:56] <snadge> it is, gentoo was just missing a buildflag in order to make that work
[11:57] <snadge> if this bug is fixed, would an update to pulse be released if that fixed the issue? or not until next release
[12:01] <persia> Depends on 1) the nature of the bug (see SRU guidelines), the impact of the bug (guidelines again), and the willingness of anyone to push it through the process.
[12:01] <persia> !sru
[12:01] <ubot2> Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates
[12:02] <persia> Anyone can drive the process, although there's no guarantees that anyone will be successful (sometimes even folks who are on the ubuntu-sru approval team get their planned SRUs rejected)
[15:40] <ctimko> Anyone here able to help me with a Networking issue I am having
[15:40] <ctimko> I am using jaunty
[15:41] <micahg> !support | ctimko
[15:41] <ubot2> ctimko: The official ubuntu support channel is #ubuntu. Also see http://ubuntu.com/support and http://ubuntuforums.org
[15:41] <ctimko> Thank you!
[15:42] <micahg> ctimko: np
[15:52] <crocket> Hello
[15:53] <crocket> how can I file a bug against ubuntu 10.04 lucid kernel?
[15:54] <pedro_> crimsun, use 'ubuntu-bug linux'
[15:54] <stenten> crocket: 'ubuntu-bug linux'. Just make sure you check Launchpad first to make sure it's not a duplicate.
[15:54] <pedro_> heh ;-)
[15:55] <crocket> how do I "ubuntu-bug linux" when linux doesn't respond?
[15:56] <davmor2> crocket: can you get into recovery mode?
[15:56] <stenten> crocket: can you get to a virtual terminal with Ctrl+Alt+F2?
[15:56] <crocket> stenten : the keyboard is dead, too
[15:56] <stenten> actually listen to davmor2, I like his response better.
[15:57] <crocket> Even under single mode, linux dies with KMS on.
[15:57] <crocket> Until KMS turns on, everythin goes fine.
[15:57] <stenten> crocket: Does it boot directly into a black screen or something?
[15:58] <crocket> After I start booting until KMS turns on, everything is fine, but then KMS turns on and everything goes black and keyboard toggle LEDs don't work either.
[15:58] <stenten> crocket: so if you enable "nomodeset" through GRUB, can you get to the desktop?
[15:58] <crocket> I haven't tried Ctrl+Alt+F2, though.
[15:58] <crocket> sure
[15:58] <crocket> nomodeset makes everything fine.
[15:59] <crocket> With nomodeset, it's better than ubuntu 9.10
[15:59] <stenten> crocket: so enable nomodeset and then 'ubuntu-bug linux'.
[15:59] <crocket> Somebody suggested me to connect to the seemingly dead linux via SSH
[15:59] <crocket> Is it really good to do it when I'm not under a problem?
[16:01] <stenten> SSH is a better choice if you can do it. But if nomodeset is the only way for you to file the bug in the first place, how else could you do it?
[16:02] <crocket> stenten : SSH
[16:13] <rlameiro> hi, i want to change some bugs, but i dont have permissions to triage them
[16:13] <rlameiro> can anyone help me?
[16:13] <rlameiro> https://bugs.launchpad.net/ubuntustudio/+bug/581786
[16:13] <ubot2> Launchpad bug 581786 in ardour (Ubuntu) (and 2 other projects) "Mute button not enabled by default in Ardour 2.8.6 Lucid AM64 (affects: 1) (heat: 6)" [Medium,Confirmed]
[16:15] <crocket> Even after I add kernel ppa, 2.6.34 kernel doesn't appear
[16:15] <crocket> Is it because I use amd64 version of ubuntu?
[16:16] <arand> rlameiro: Generally what you do is state the requested change and why here, and if you're lucky someone from the bug team can change it for you if they agree.
[16:17] <rlameiro> ok
[16:18] <rlameiro> so the problem is in mainstream (bug) i already added the mainstream project (ardour) and someone of the ubuntustudio team is working on a patch to send upstream and to debian also
[16:18] <rlameiro> so the bug is triaged already
[16:19] <rlameiro> and it is of big importance for ubuntu Studio, and maybe medium for ubuntu, since this is a "pro audio programm"
[16:22] <arand> rlameiro: And the changes persia did 6min ago, are they incorrect?
[16:22] <rlameiro> no
[16:22] <rlameiro> i was talking with persia, he told me to come here
[16:22]  * persia made them based on discussion with rlameiro
[16:22] <rlameiro> maybe i just did it :D
[16:22] <rlameiro> he
[16:23] <rlameiro> arand: how can i enter the bugs team?
[16:27] <stenten> rlameiro: first join the Bug Squad (https://wiki.ubuntu.com/BugSquad) and then you can join the Bug Control Team (https://wiki.ubuntu.com/UbuntuBugControl).
[16:28] <rlameiro> thanks stenten i was reading  the wiki already, shame on me i didnt read the topic
[16:28] <stenten> no worries.
[16:28] <stenten> crocket: Are you talking about the mainline kernel PPA?
[16:29] <crocket> stenten : 2.6.34-rc7 and newer
[16:29] <crocket> yes
[16:29] <crocket> http://kernel.ubuntu.com/~kernel-ppa/mainline/
[16:30] <stenten> crocket: You have to download the three .debs and install them individually.
[16:30] <crocket> I can't add them in repository and install via synaptic....
[16:31] <stenten> crocket: no you cannot.
[16:31] <crocket> stenten , do developers prevent it?
[16:33] <stenten> crocket: Not sure. That's just how the site's set up. I just accept it; it's really easy to install still.
[16:35] <stenten> crocket: you can get in touch with kernel folk at #ubuntu-kernel
[16:35] <crocket> ok
[16:51] <hggdh> rlameiro: I already approved you in, thank you for helping :-)
[16:51] <rlameiro> hggdh: thanks me for aproving me :D
[16:52] <hggdh> rlameiro: my pleasure
[16:52] <rlameiro> happy to help :D
[17:09] <stenten> just curious, does being a member of the bugsquad have any privileges/powers like bugcontrol does?
[17:11] <nigelb> stenten: nope, but it tells us that you're trying to help
[17:11] <nigelb> for example if you screw up 20 bugs in one day, we might take you for a spammer and report you to Launchpad admins
[17:12] <BUGabundo_remote> ahahah
[17:12] <nigelb> but if you're bug squad, we'll get in touch with you and try to explain what went wrong and how to do things right :)
[17:13] <nigelb> BUGabundo_remote: anything you'd like to add? :)
[17:13] <stenten> hah, excellent. thanks nigelb :)
[17:14] <rlameiro> maybe also if you want to get into bugcontrol you need to be on bugsquad first?
[17:15] <nigelb> thats's the simplest explanation to "Why you should join bug squad if you want to help" :)
[17:16] <nigelb> rlameiro: not really, you need to showcase the triaging work you've done, you don't really *need* to be bugsquad member
[17:16] <rlameiro> hum ok thanks nigelb
[17:17] <nigelb> rlameiro: but, like I said, if you want to help, I'd recommend joining bug squad, so *we* know you're trying to help and we can correct if you go wrong :)
[17:18] <rlameiro> nigelb: i just joined :D
[17:18] <nigelb> awesome! thanks for helping out :)
[17:19] <nigelb> I wish I had the time I had initially to help with bugs, at least now I get to help others who'd like to help with bugs :)
[17:20] <scott-work> hello all, i have applied (and emailed the list) for bugsquad membership :)
[17:21] <nigelb> scott-work: one of the admisn should get around soon... hggdh ^
[17:21] <scott-work> thank you nigelb
[17:21] <hggdh> er
[17:21] <hggdh> scott-work: give me 1 min
[17:22] <rlameiro> hggdh: one more from the ubuntustudio team :D
[17:22] <hggdh> scott-work: done. Welcome in, and thank you for helping
[17:22] <hggdh> rlameiro: good
[17:23] <scott-work> hggdh: thanks!
[17:42] <ddecator> hggdh: ping
[17:53] <hggdh> ddecator: I am here
[17:53] <hggdh> (so far)
[17:53] <ddecator> hggdh: just wondering if you remember why you pinged me on friday
[17:56] <BUGabundo_remote> ahahah
[17:58] <nigelb> ddecator: nice of you to wonder on monday :D
[17:58] <ddecator> nigelb: just want to find out before i forget :p
[17:58] <nigelb> lol
[17:59] <ddecator> hggdh: i have to go get ready for class, but i'll be back on in a little bit before class, and then again later after class, so feel free to ping or pm me
[18:04] <jbicha> JFo: thanks for mentioning apport-collect, I didn't know about that command
[18:04] <JFo> jbicha, no problem :)
[18:06] <jbicha> JFo: what do you mean by "automated message", what tool(s) do you use for bug triage?
[18:07] <JFo> I'm running a script that processes the bugs
[18:07] <JFo> so the comment has been automatically generated
[18:07] <jbicha> what script?
[18:08] <hggdh> ddecator: no, I do not remember any more...
[18:09] <JFo> jbicha, it is a script in the kernel branch of the arsenal project
[18:10] <jbicha> ok, I don't do much with the kernel, it scares me :-)
[18:12] <vish> JFo: hi.. while testing bug 543485 , i noticed that the kernel .34 has *very* slow frame rates for video  , do i report it upstream , or wait for it to land in M ?
[18:12] <ubot2> Launchpad bug 543485 in linux (Ubuntu) "gspca: ISOC data errors when using resolution of 640x480 (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/543485
[18:13] <JFo> vish, probably a good idea to report upstream
[18:14] <JFo> then if you encounter it in early tests of M to file a bug and let me know:)
[18:14] <vish> k.. ;)
[18:14] <JFo> so we can track both places
[18:15] <JFo> thanks vish :)
[18:15] <vish> np :)
[18:16] <vish> JFo: what are all the info upstream expect for such bugs?  i can just use apport to collect info and all those upstream? [i recall you mentioning it in UDS that they dont like reporters very much ;p ]
[18:16] <vish> s/all/add
[18:18] <JFo> heh
[18:19] <JFo> vish, I think it depends on the bug
[18:19] <JFo> they may just want some sort of graphics testing for this one, but I couldn't say what exactly
[18:19] <vish> i guess lsusb and lspci should be sufficient for this one?
[18:19] <JFo> yeah, for now
[18:19] <vish> JFo: neat thanks
[18:19] <JFo> and then let me know what they ask for beyond that
[18:20] <JFo> we can add it to a "reporting upstream" wiki page
[18:20] <JFo> np
[18:52] <PrototypeX29A> hi, got the ambitious to file every bug i encounter (yes, i am unemployed)
[18:52] <PrototypeX29A> +idea
[18:53] <Pici> heh
[18:55] <PrototypeX29A> does "Incomplete" also mean "cannort reproduce"?
[18:55] <PrototypeX29A> in launchpad
[18:55] <charlie-tca> not necessarily
[18:55] <Pici> It could, but usually it means that the triager has requested additional information and is waiting for the bug reporter to provide it.
[18:56] <charlie-tca> Even if it can be reproduced, sometimes, you want more information from the reporter
[19:00] <PrototypeX29A> yes, that was what i associated with it. Then I thought my bug was wrongly set to "incomplete" but it seems that it also can mean "cannot reproduce"
[19:01] <PrototypeX29A> which is a little bit confusing for the reporter, because one does not know whether some specific information is missing or the maintainer just is clueless
[19:07] <vish> PrototypeX29A: when a triager marks a bug as incomplete they *will* mention why , so not too confusing
[19:08] <PrototypeX29A> vish: at least they should :)
[19:08] <vish> PrototypeX29A: well if someone hasnt mentioned the reason , do mention it here , the tirager gets 10 lashes  ;)
[19:08] <vish> triager*
[19:09]  * vish hopes it aint me  , fingers crossed x
[19:10] <Pici> Speaking of bugs, could someone take a look at https://bugs.launchpad.net/bugs/459647 and see if the 'fix committed' status change was made improperly? I'd hate to see a bug not get fixed because someone randomly changed the status even though its not fixed.
[19:10] <ubot2> Launchpad bug 459647 in compiz (Ubuntu) (and 1 other project) "Cannot change mouse cursor theme when compiz is enabled (affects: 81) (dups: 7) (heat: 490)" [Low,Fix committed]
[19:10] <Pici> I think it was, but I don't want to change it back before asking.
[19:12] <PrototypeX29A> vish: if this is the policy i will happily do the lashing myself
[19:15] <vish> Pici: hmm , i dont see a commit upstream or anywhere
[19:17] <PrototypeX29A> submitting a useless fix is a nice way to get a bug to be confirmed :)
[19:21] <Pici> vish: Thanks.
[19:21] <vish> np..
[19:23] <anoteng> Anybody familiar with git-bisecting the ubuntu kernel? I fear I keep producing the same .debs over and over again. Anybody care to take a look at my commands and check if I'm doing something stupid? http://pastebin.com/Rfif04jx
[19:41] <kamusin> bug 585079 , should be fine under mime-support?
[19:41] <ubot2> Launchpad bug 585079 in ubuntu "missing mimetype for webm format (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/585079
[19:56] <micahg> anyone experiencing bug 575160
[19:56] <ubot2> Launchpad bug 575160 in seamonkey (Ubuntu Maverick) (and 2 other projects) "seamonkey 2.0 in Lucid crashes with 'RenderBadPicture' diagnostics (affects: 9) (dups: 3) (heat: 70)" [High,Triaged] https://launchpad.net/bugs/575160
[20:20] <JFo> vish, re: reporting a bug upstream, I have the following: https://wiki.ubuntu.com/Kernel/Bugs
[20:20] <JFo> check the section on reporting upstream
[20:21] <JFo> let me know if there is anything broken as you proceed so I can fix it
[20:30] <vish> JFo: awesome, thanks!
[20:31] <JFo> my pleasure
[21:25] <PrototypeX29A> who is to be whipped, when a bug stays on 'new' forever?
[21:25] <PrototypeX29A> looks like i still have to find out how to use launchpad effectively
[21:26] <micahg> PrototypeX29A: one can come here and ask for it to be reviewed if no one reviews it in a reasonable period of time
[21:27] <PrototypeX29A> i just noticed that bugs may be 'Undecided' and 'New' on the Overview page, but are not if you click on the bug
[21:28] <PrototypeX29A> i try to keep track which of my (reported) bugs need attention, but the overview page is confusing
[21:29] <micahg> https://bugs.launchpad.net/~your-id/+reportedbugs
[21:29] <PrototypeX29A> this one is new for quite some time: https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/499889
[21:29] <ubot2> Launchpad bug 499889 in gtk+2.0 (Ubuntu) (and 1 other project) ""Type name of new folder" does not have focus, when doing "save as" with descending ordering. (affects: 1) (heat: 6)" [Low,New]
[21:30] <micahg> PrototypeX29A: you can sort by least recently changed
[21:30] <PrototypeX29A> but there are a lot of bugs which just don't concern me
[21:30] <micahg> if someone else can pick this up, I can't review right now
[21:31] <micahg> hggdh: are you around to help?
[21:31] <PrototypeX29A> don't get me wrong the bug just linked does not need imediate attention for my sake
[21:31] <PrototypeX29A> i am just curious about the processes, as i intend to do some more reports in the next time
[21:32] <ddecator> looks like it just needs to be sent or linked upstream
[21:32] <micahg> PrototypeX29A: well, we're limited on human resources and people have certain packages they try to look after, so it's very possible bugs will slip through the cracks, if you have a bug that has gone unnoticed, you can come in here and ask about it
[21:33] <micahg> PrototypeX29A: or move it along yourself if you like: https://wiki.ubuntu.com/Bugs/HowToTriage
[21:33] <PrototypeX29A> i will have a look at it
[21:35] <PrototypeX29A> and i think this one should be closed as the upstream fix seem to have found his way into the standard kernel https://bugs.launchpad.net/~preineke
[21:35] <PrototypeX29A> no wrong link
[21:35] <PrototypeX29A> https://bugs.launchpad.net/fedora/+bug/496292
[21:35] <ubot2> Launchpad bug 496292 in fedora (and 1 other project) "Kerneloops and disconnecting wlan (affects: 1) (heat: 8)" [Unknown,Confirmed]
[21:41] <micromix> hey can someone just peak at this bug 579098
[21:41] <ubot2> Launchpad bug 579098 in gparted (Ubuntu) "umount partition issue (affects: 1) (heat: 6)" [Undecided,Incomplete] https://launchpad.net/bugs/579098
[21:41] <micromix> i believe it should be wishlist
[21:44] <hggdh> micahg: reading the backlog
[21:51] <hggdh> oh hasty people...
[21:53] <hggdh> PrototypeX29A: no, it should not be closed, until we verify this does not happen on an Ubuntu kernel
[21:54] <PrototypeX29A> it is the ubuntu kernel i was talking about
[21:54] <hggdh> yes. Which one?
[21:54] <PrototypeX29A> the latest one i get with karmic
[21:55] <PrototypeX29A> 2.6.31-21-generic?
[21:55] <PrototypeX29A> so for karmic the problem is solved, isn't it?
[21:56] <PrototypeX29A> unless the other reporter still has a problem
[21:56] <hggdh> Good. *Sounds* like it, but I would rather wait for more confimations -- if the hardware is not exactly the same, symptoms may mix
[21:57] <hggdh> it is always a good idea, anyway, to add it the specific version when it works
[21:57] <PrototypeX29A> i should state that i am using the exact same model as the other reporter
[21:57] <hggdh> also a good idea. Can you please add both the kernel version and the make/model of the card in the bug?
[21:58] <micahg> PrototypeX29A: just a note, kernel team prefers separate bugs even if everything looks the same
[21:59] <PrototypeX29A> understandable :)
[22:00] <PrototypeX29A> i have the model of the notebook at hand, but how do i get the 'card'?
[22:00] <PrototypeX29A> something from lspci? 04:00.0 Network controller: Atheros Communications Inc. AR928X Wireless Network Adapter (PCI-Express) (rev 01)
[22:08] <hggdh> PrototypeX29A: yes, lspci would help (even more if run as root)


[01:31] <ethan_> I have some general questions about upstart and admin of services on karmic if anyone is willing to answer
[01:44] <ethan_> now that it seems ubuntu has completely shifted to upstart as of karmic is the entire system-v init system obsolete,  I ask because I still see how to's on the web explaining service control with /usr/sbin/servic


[08:11] <meena> we have a logging configuration. you can change it
[11:04] <meena> smoser: fixed the mysteriously failing kenv test! https://github.com/canonical/cloud-init/pull/621 now to replace dmidecode with kenv in ds-identify
[11:27] <meena> maybe i should make my console fonts smaller, so i can fit more python backtrace into one screen
[13:20] <smoser> meena: what was it ?
[13:21] <smoser> https://github.com/canonical/cloud-init/commit/963690e5f8867d71a5106ce05a768dcf7eea646f i guess.
[13:22] <paride> Odd_Bloke, could you please create and push a new branch for groovy? `git checkout -b ubuntu/groovy ubuntu/20.3-15-g6d332e5c-0ubuntu1` should do it
[13:22] <paride> ubuntu/devel is already ahead of what ubuntu/groovy should have
[13:22] <paride> I can't prepare a PR for it as the target branch is nonexisting
[13:27] <paride> once that's done let's see if https://code.launchpad.net/~cloud-init-dev/+recipe/cloud-init-daily-groovy builds
[13:41] <meena> smoser, yes, the closure was checking the wrong (translation table)
[13:58] <smoser> meena: i put  a review there.
[13:58] <smoser> paride: the second argument there to 'checkout -b' sets the tracking branch
[13:59] <smoser> doesnt it? which isn't what you want. or maybe if you feed it a tag it does teh right thing.
[13:59] <smoser> i always branch with: git checkout -b fix/my-new-branch upstream/master
[14:01] <paride> smoser, right, but in this case we couldn't cut ubuntu/groovy from ubuntu/devel as ubuntu/devel is one commit ahead of what it's in groovy
[14:01] <paride> no big deal probably? Should we SRU to groovy we're going to merge everything anyway
[14:01] <smoser> right. i'm just saying that you wouldnt want to set the tracking to a tag.
[14:01] <smoser> that is what i'm not familiar with.
[14:02] <smoser> i guess iwth a tag it does not set the upstream tracking.
[14:02] <smoser> so... never mind  me
[14:47] <meena> smoser, thank you for the review. I'll make those changes before moving on to ds-identify fix is_container and ds-identify
[14:49] <Odd_Bloke> falcojr: I was just trying to use IN_PLACE for testing, and it looks to me like the mount happens too late (I've added some logging lines locally for this): https://paste.ubuntu.com/p/nXRRWRFJbg/
[14:51] <Odd_Bloke> It might take a bit of refactoring to get it in the right place: I think we'll need to create but not start the container, perform the mount, then start the container?
[14:56] <falcojr> yeah, good catch. Even without that it's a bit of an outlier in terms of timing
[15:00] <meena> re ds-identify, i'll need some guidance on how to best do that in python, because it's done like this https://github.com/canonical/cloud-init/blob/master/tools/ds-identify#L405
[15:48] <smoser> meena: do what in python ?
[15:52] <Odd_Bloke> paride: +1 on the Jenkins jobs changes, leaving to you to land as you'll need to do some manual cleanup on the no-longer-generated jobs.
[15:52] <paride> thanks Odd_Bloke
[15:53] <meena> smoser, basically, I'm wondering if I should hack that sysctl call into CONTAINER_HELPERS
[15:55] <smoser> oh. i see.
[15:56] <meena> CONTAINER_TESTS,actually
[15:57] <meena> test sysctl call -eq 1
[15:58] <smoser> meena: i m ight re-do CONTAINER_TESTS to be a list of functions.
[15:59] <meena> or i might
[15:59] <meena> or lambdas?
[15:59] <smoser> then just insert one named 'is_container_bsd' that checks uname and returns None.
[15:59] <smoser> you coudl try with lamndas' but theire' harder to mock and such
[16:00] <meena> bah
[16:01] <meena> I'ma let you do the ground work then
[16:06] <paride> Odd_Bloke, I'm tempted to switch to `jenkins-jobs update --delete-old`. I did that in the iso-testing jenkins and it really helped with housekeeping. Can you think of a reason why that might not be a good idea?>
[16:07] <powersj> we have this same debate about once a year :)
[16:12] <paride> powersj, I thought twice :P
[16:12] <smoser> meena: https://paste.ubuntu.com/p/k9VpYPGvwC/
[16:12] <smoser> thoughts ?
[16:12] <powersj> paride, I have had it turned on before, but folks wanted to be able to create temp jobs or deploy dev jobs
[16:18] <meena> smoser, looks good
[16:18] <meena> smoser, wanna add that to my branch?
[16:19] <paride> powersj, I remember you saying that it was not a good idea for some reason. Thanks for chiming in :)
[16:22] <paride> anyway manually added jobs should not be auto-deleted if the '<!-- Managed by Jenkins Job Builder -->' string is deleted from their description
[16:22] <paride> as jjb doesn't recognize them as its own
[16:23] <paride> alternative 2: add a bool parameter to admin-jobs-update so it runs --delete-all on request
[16:25] <paride> I'll make a PR with this and let's discuss it there
[16:28] <smoser> meena: you can add it and flesh out tesets. it will change how the tests work i'm sure. :-(
[16:28] <smoser> but i suspect most things mock is_container() so implementation woudlnt matter
[16:34] <powersj> paride, I like having the param so you can cleanup easily when you need/want to
[16:40] <meena> smoser, I'll attribute it to you
[16:46] <smoser> s/attribute/blame/ thanks
[16:46] <smoser> ;)
[16:51] <paride> powersj,  https://github.com/canonical/server-jenkins-jobs/pull/147
[17:41] <Odd_Bloke> falcojr: Easy one: https://github.com/canonical/cloud-init/pull/656
[17:48] <Odd_Bloke> falcojr: Actually, I think we lost the line that emitted _all_ settings to the log during the refactor, so I'll submit that in a second instead.
[17:56] <Odd_Bloke> falcojr: Take two: https://github.com/canonical/cloud-init/pull/657
[19:46] <meena> somebody please make paste.ubuntu.com not require a login, to download the raw text
[19:51] <meena> smoser: you can't build a FreeBSD system without sysctl
[19:52] <meena> smoser: /rescue (all statically compiled stuff that you can use as … well, rescue system) has sysctl
[19:52] <meena> like we can't build FreeBSD without geom
[20:10] <Odd_Bloke> meena: It requires a login to avoid it being used for spam/malware automation, I believe.
[20:12] <Odd_Bloke> falcojr: Another one for the integration testing nits: I don't think I updated .travis.yml for s/IMAGE_SOURCE/CLOUD_INIT_SOURCE/ before it landed, so all of the tests thus far have been running against the cloud-init baked into our OS image.
[20:31] <falcojr> That's half hilarious half disturbing


[11:17] <avis> hello
[12:24] <BluesKaj> howdy all
[12:35] <BluesKaj> !schedule
[12:50] <dholbach> https://wiki.ubuntu.com/UbuntuOpenWeek starting in 10 minutes in #ubuntu-classroom
[17:24] <nOStahl> hi uys
[17:25] <nOStahl> does ubuntu have any plans for developing their own applications like apple and microsoft does?
[17:28] <jtaylor> own applications?
[17:28] <jtaylor> like unity?
[17:28] <genii-around> I'm pretty sure Unity was an in-house development...
[17:28] <nOStahl> in addition
[17:28] <nOStahl> ie apple has its iwork and ilife suites
[17:28] <nOStahl> microsoft has office etc
[17:29] <jtaylor> ubuntu has libreoffice
[17:30] <genii-around> Because there are already other teams working on stuff like libreoffice there's not really much point to it, why re-invent the wheel?
[17:30] <nOStahl> something with more polish :)
[17:32] <genii-around> Each *buntu flavour though usually has it's own little projects within to make it more integrated, like regular Ubuntu with Unity, Edubuntu with thin-client integration, etc
[17:33] <nOStahl> im running 12.10 on an eee pc 901 right now with a recently upgraded 32 gig sata ssd
[17:35] <nOStahl> I wish empathy would let you add irc contacts to the buddy list...
[21:19] <ironhalik> so... whats new in 13.04? ;>
[21:20] <IdleOne> nothing yet
[22:01] <pepee> hi. #ubuntu is not a lot of help, so... I don't want to file a bug report by myself, so I'm throwing this here:  http://linux.slashdot.org/story/12/10/24/1848203/ext4-data-corruption-bug-hits-linux-kernel   https://lkml.org/lkml/2012/10/23/690
[22:02] <jtaylor> I'm sure thats on someones agenda already
[22:02] <pepee> from what I read in slashdot,  3.5.0-18 from proposed  and 3.6.3 from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.6.3-quantal/, both have the bug
[22:02] <pepee> * 3.6.2
[22:03] <pepee> ak, ok jtaylor , thanks anyway
[23:00] <FernandoMiguel> oh boy
[23:00] <FernandoMiguel> just read about the ext4 bug :S