[02:40] <bryce> tjaalton: you around?
[02:41] <bryce> tjaalton: I'm trying to sort out how to update libdrm by doing a merge in git, but the directions in X/GitUsage aren't clear
[04:11] <bryce> hmm, ok nevermind, I'll just do it by hand
[05:03] <tjaalton> bryce: done already?
[05:19] <tjaalton> I wonder if most of the libdrm changes could be dropped now
[12:42] <mikaelhm> Hi, is there anyone good at finde the problem of my X restarting, i have the Backtrace from the Xorg.log?
[13:13] <mnemo> mikaelhm: what does "lspci -nn | grep VGA" print for your machine?
[13:14] <mikaelhm> 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc Radeon Mobility X1400 [1002:7145]
[13:15] <mnemo> mikaelhm: do you know some special action that is guaranteed to trigger the crash?
[13:15] <mikaelhm> no, earlier i had problem with mesa
[13:15] <mikaelhm> but it is not the same backtrace in the log
[13:16] <mnemo> paste the stack from xorg.log into paste.ubuntu.com
[13:16] <mnemo> actually paste your whole xorg.log please :)
[13:17] <mikaelhm> http://paste.ubuntu.com/170545/
[13:17] <mikaelhm> oki
[13:17] <mikaelhm> 2sec
[13:17] <mikaelhm> http://paste.ubuntu.com/170547/
[13:19] <mnemo> and when does the crash happen you say?
[13:19] <mikaelhm> i was writing latex in kile.
[13:20] <mikaelhm> i have activated Compiz, and some of its features, but i was not using them.
[13:20] <mnemo> have you restarted the computer since the crash happened?
[13:20] <mikaelhm> no
[13:20] <mikaelhm> I just logged in agian
[13:21] <mnemo> right, so you still have the backtrace in the xorg.log.old then?
[13:21] <mikaelhm> jep
[13:21] <mikaelhm> i have made a backup also.
[13:21] <mikaelhm> jep=yes
[13:21] <mnemo> please use the command "ubuntu-bug xorg" to open a bug on it (it will attach all the logs automatically)
[13:22] <mikaelhm> oki, but how should i describe the bug?
[13:22] <mnemo> just say "-radeon driver segv while editing latex in kile" or something
[13:22] <mikaelhm> oki
[13:23] <mnemo> and please install the packages xserver-xorg-core-dbg and xserver-xorg-video-ati in case the crash happens again (if you have these packages installed, the stackframe will be much better with proper function names instead of binary return addresses only)
[13:23] <mikaelhm> hehe, oki ill install them now.
[13:23] <mnemo> if the crash happens again and you see similar (but more complete stacktrace in xorg.log.old then find your bug on launchpad and add the improved stacktrace there)
[13:24] <mnemo> mikaelhm: and paste the LP bug number to me here as well
[13:24] <mikaelhm> LPB bug numbet?
[13:24] <mikaelhm> sorry, LP Bug no, where do i find it?
[13:24] <mnemo> yeah the URL to the bug inside launchpad (the bug you're opening using the ubuntu-bug command)
[13:25] <mnemo> when you run "ubuntu-bug xorg" from a terminal it will open up firefox with the bug report
[13:27] <mikaelhm> ahh, i didn't notisfy that...
[13:27] <mikaelhm> 2 sec
[13:33] <mikaelhm> what to fill in the
[13:33] <mikaelhm>
[13:33] <mikaelhm> Further information:
[13:33] <mnemo> skip it for now
[13:34] <mnemo> you can edit the bug later and it's also to post comments to it, so we can request more info if needed etc
[13:35] <mikaelhm> oki, I just wrote, you told me to report it :-)
[13:36] <mikaelhm> https://bugs.launchpad.net/ubuntu/+bug/375414
[13:37] <mnemo> mikaelhm: ok great, can you attach the output of the "dmesg" command as well please?
[13:39] <mikaelhm> jep
[13:39] <mikaelhm> like that?
[13:40] <mnemo> yes
[13:40] <mnemo> thanks for the bug report
[13:41] <mikaelhm> no problem.
[13:45] <mnemo> mikaelhm: i'd like to see one of data point from you system... can you attach the output of "dpkg -l" as well please?
[13:48] <mikaelhm> 2 sec
[13:49] <mikaelhm> mnemo, done :-)
[13:50] <mikaelhm> mnemo, isn't the card r300?
[13:51] <mikaelhm> no, i guess thats just me....
[13:52] <mnemo> im not entirely, sure but wikipedia seems to indicate it's r520? http://en.wikipedia.org/wiki/Radeon_R520#X1300_-_X1550_series
[13:52] <mnemo> mikaelhm: how old is the card?
[13:54] <mikaelhm> hmm dunno, its in my T60 laptop
[13:55] <mikaelhm> oki, i thin its r500
[13:56] <mnemo> yea, T60 is reasonably new... r300 is like radeon 9600 and stuff like that... was sold around 2003 or so
[13:56] <mnemo> anyway your bug was previously reported actually
[13:56] <mnemo> I will mark it as duplicate soonish
[13:57] <mnemo> some norwegian guy found the same bug in the end april it seems --> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/365074
[13:57] <mnemo> but his stack was also partial ;(
[14:00] <mikaelhm> :-(
[14:02] <mikaelhm> but i will add a comment, with the backtrace if it happeds again.
[14:02] <mnemo> yes please do, that would be very useful
[14:04] <mikaelhm> oki.. i will leave for now. Thx for the help with reporting my first bug :-)
[14:04] <mnemo> no problem, please keep the reports coming :)
[14:09] <stgraber> bryce: any opinion on bug 375417 ?
[14:09] <stgraber> bryce: it makes inkscape impossible to use and gimp is way too slow to start
[14:12] <mnemo> stgraber: maybe you can try to generate a graph based on the system calls (strace) and see which ones are causing the delay?
[14:13] <mnemo> this has been done to analyze nautilus startup delays for example
[14:13] <mnemo> see --> http://www.gnome.org/~federico/news-2006-03.html#login-time-1
[14:28] <mikaelhm> hey mnemo  i think i just happend again
[14:28] <mnemo> mikaelhm: aah too bad (and good) ... hehe
[14:28] <mnemo> so you got a better stack this time?
[14:28] <mikaelhm> jep
[14:29] <mikaelhm> but theres no backtrace in Xorg.0.log.old
[14:29] <mnemo> so what happened, did it log you out so you returned to gdm login prompt?
[14:29] <mikaelhm> jep
[14:30] <mikaelhm> just blink, and then gdm login promt
[14:30] <mnemo> and no stacktrace in xorg.log and nothing in xorg.log.old either?
[14:30] <mikaelhm> no
[14:31] <mnemo> run "dmesg"
[14:31] <mnemo> anything about segv at the bottom of dmesg?
[14:31] <mikaelhm> its funny., the xorg.log.old has not been modified since 14:36
[14:31] <mnemo> for example, my firefox just crashed and at the bottom of dmesg I have this:
[14:31] <mnemo> [179033.395844] firefox[28705]: segfault at a7bfad6c ip b03e73c3 sp a8ffe390 error 4 in libflashplayer.so[aff70000+96d000]
[14:32] <mikaelhm> http://paste.ubuntu.com/170596/
[14:32] <mikaelhm> nop
[14:32] <mnemo> hmm ok so your xorg segv's doesnt show up in dmesg I guess
[14:33] <mnemo> mikaelhm: i suggest you activate the apport crash reporter
[14:33] <mnemo> please run this command:
[14:33] <mnemo> sudo force_start=1 /etc/init.d/apport start
[14:33] <mikaelhm> done...
[14:33] <mikaelhm> :-)
[14:33] <mikaelhm> this time i was writing in pidgin,:-p
[14:34] <mnemo> it will start the crash monitor in the background (the crash monitor tool will be activate until you reboot, if you reboot you just manually run this command again because the crash reporter is off by default in the "stable" version of ubuntu)
[14:34] <mikaelhm> ok
[14:34] <mnemo> hopefully apport will detect your crash and tell you to submit a new bug report... if it asks, please do open a new bug
[14:34] <mikaelhm> ok
[14:35] <mikaelhm> can i put it in bashrc or
[14:35] <mnemo> yeah sure, that works
[14:35] <mnemo> well I never tried that myself but I mean.. think it works
[14:37] <mikaelhm> what about the sudo...
[14:37] <mnemo> aah, right that requires a password
[14:37] <mnemo> not sure how to solve that
[14:40] <mnemo> ..hmm and maybe .bashrc runs once for every terminal you start? that'd be bad I think
[14:42] <mikaelhm> oki
[14:42] <mikaelhm> don't mind i just start i every time.
[17:31] <bryce> tjaalton: it'd be good if you could take a look at the libdrm merge.  The bulk of the stuff we're carrying is nouveau which we'll still need, but there's some intel bits and pieces that could use review.
[17:32] <bryce> tjaalton: also I didn't commit to git, since I'm not sure how to do upstream+debian merges in git, so you could look at doing that
[17:35] <apw> bryce, that change to the i915 works for me.  just need to clean up the kernel changes needed and will then write the conclusion in the bug and we can get things pushed
[17:39] <bryce> ok
[18:11] <jbarnes> apw: is there an apt source for the vanilla kernel builds?
[18:12] <jbarnes> for jaunty I mean
[18:12] <apw> nope.  ppa's just get all pissed off if you have more than one thing of the same source package in them
[18:12] <jbarnes> oh lame
[18:12] <apw> yeah its annoying
[18:12] <apw> though they are also massive
[18:14] <superm1> apw, cant you just append a ~jaunty1 and ~karmic1 etc to the source package version and it would be fine?
[18:14] <apw> no cause one or other is still newer
[18:14] <superm1> apw, we end up doing that for weekly mythbuntu builds of mythtv -fixes and -trunk and the PPAs appear to handle it sanely
[18:14] <apw> and that deletes the binary packages for the previous one
[18:14] <superm1> oh right
[18:14] <apw> to put it a different way, yes we could have jsut the latest one in a ppa and we don't and we prolly should
[18:15] <apw> as we wanted them all available for testing
[18:15] <jbarnes> yeah a 'latest' ppa with just the last -rc or something would be helpful
[18:15] <jbarnes> older ones can always be downloaded by hand, e.g. for bisection
[18:16] <jbarnes> I just wanted one because I'm trying to narrow down a boot failure
[18:19] <tjaalton> bryce: sure thing. what do you mean by "upstream merge"? there shouldn't be any git-pulls from upstream
[18:19] <mnemo> jbarnes: not sure if this is what you need but you can just click the "image deb" for the correct arch from here and install it using gdebi --> http://kernel.ubuntu.com/~kernel-ppa/mainline/
[18:20] <jbarnes> yeah thanks, already grabbed them from there
[18:20] <jbarnes> and found that the boot failure seems to be generic with 2.6.30ish on my aspireone
[18:21] <tjaalton> bryce: also, do you have the debdiff at hand, it would help in doing the merge in git
[18:23] <bryce> tjaalton: sure - people.ubuntu.com/~bryce
[18:24] <tjaalton> thanks
[18:24] <bryce> tjaalton: by upstream merge I mean the case where you are not just merging new debian -N, but also pulling in a new upstream version
[18:25] <tjaalton> ah, well it shouldn't be any different
[18:25] <bryce> seems this scenario isn't documented in the wiki, and I didn't find it obvious how to do it on my own
[18:26] <tjaalton> I'll see what happens
[18:26] <bryce> well, I guess even the -N case isn't explicitly documented, although one section referred to updating against debian
[18:26] <tjaalton> btw, it seems that hal has been dropped from the desktop seed, but we are the ones pulling it in :)
[18:27] <superm1> is the only thing left needing hal xorg input stuff?
[18:27] <tjaalton> superm1: I think so
[18:27] <bryce> you're kidding
[18:27] <tjaalton> I'm not sure though
[18:27] <bryce> oh, wait, they're all moving from hal to that new thing aren't they
[18:27] <bryce> devicekit?
[18:28] <tjaalton> the quirks are moved to udev-extras, and the disk stuff to devicekit-disks
[18:28] <superm1> so what about apps that say needed to rely on hal info to find stuff on the system via hal python interfaces.  are there equivalents made for device kit already?
[18:29] <tjaalton> no idea :)
[18:30] <tjaalton> I guess hal will still be around for some time though
[18:30] <tjaalton> just that I'm not sure what's the way forward
[18:31] <superm1> yeah. i'll just keep an eye open for what happens when it does disappear
[18:32] <bryce> I find it ironically humorous
[18:50] <tormod> bryce: ...that as soon as xorg has adopted it, hal is being ditched?
[18:51] <bryce> tormod: right
[18:52] <bryce> tormod: and all the pain we had to go through in switching over to it
[18:53] <superm1> i dont think there is any devicekit equivalent for input devices yet is there then
[18:53] <superm1> so it probably will be around a while
[18:53] <bryce> I suppose now someone will contribute a really spiffy GUI admin tool for configuring input devices with hal, and then right after that someone will switch X from hal to something else
[18:55] <crevette> bryce: just to inform you, I heard thay upstream decide to drop hal
[18:56] <crevette> thay -> that
[18:56] <crevette> decided also
[18:59] <bryce> crevette: seriously?  Do you have a link handy?
[19:03] <tjaalton> it's probably going to be replaced by udev rules
[19:04] <bryce> ideas on a timeframe?  something we need to be worried about for karmic?
[19:04] <crevette> the plan is to use libudev
[19:04] <crevette> pitti should know I guess
[19:04] <tjaalton> bryce: btw, I don't know if 'git pull . debian-foo <tag>' is even supposed to work, but I've used 'git merge <tag>', and it works just as fine even though the upstream version has changed
[19:04] <crevette> trying to find a link
[19:05] <tjaalton> bbiab
[19:05] <bryce> tjaalton: yeah I couldn't get that to work.   I *think* I may have tried that too, but it failed.  Possibly my tree wasn't clean at the time or something
[19:26] <tjaalton> first you need to rebase to origin
[19:27] <bryce> do you mean by doing `git checkout -b ubuntu origin/ubuntu`?
[19:29] <tjaalton> no, git rebase origin/ubuntu
[19:30] <tjaalton> when you are in the local ubuntu branch
[19:30] <bryce> tjaalton: the docs ought to include that step then, I'd never think to do that ;-)
[19:30] <tjaalton> 'checkout -b foo origin/foo' would create a local branch, and would fail if foo already exists
[19:30] <tjaalton> heh, ok I'll add it
[19:31] <bryce> tjaalton: btw, I've merged/syncreq'd most of the outstanding X packages
[19:32] <tjaalton> sometimes just doing 'git pull' works
[19:32] <tjaalton> nice
[19:32] <bryce> tjaalton: the input stuff is left to do, plus xorg/mesa/xorg-server
[19:34] <bryce> guess xorg/mesa/xserver can wait until after UDS
[19:34] <tjaalton> yeah
[19:51] <tjaalton> bryce: ok, the wiki is now updated
[19:54] <tormod> I think you should look at mesa soon
[19:54] <tjaalton> tormod: you'd like 7.5?
[19:55] <tormod> tjaalton: right :)
[19:55] <tjaalton> figures ;)
[19:55] <tormod> it could need some testing and is already past RC
[19:56] <bryce> tormod: I'm starting to lean in the direction of "needs some more testing" != "ready to put into archive" ;-)
[19:56] <tjaalton> s/more //
[19:56] <bryce> heh, even worse
[19:57] <tormod> karmic is playground isn't it?
[19:57] <bryce> yes-ish
[19:57] <tjaalton> OTOH, upstream has changed the meaning of the versions.. 7.5 isn't a dev-snapshot anymore, it'll have bugfixes as 7.5.x
[19:58] <tormod> upstream already starts to comment in bug reports "this should be fixed in 7.5"
[19:58] <tjaalton> we'd probably want 7.6 for karmic if it's released in time
[19:58] <tormod> in that case we should definitely start using 7.5
[19:58] <tjaalton> hopefully it'll have r6/7xx support, and the radeon-rewrite branch
[19:59] <bryce> alright, well if either of you feel like doing the merge, go for it.  Probably post-alpha1 since we're frozen at the moment.
[19:59] <tjaalton> of course
[19:59] <bryce> mainly my concern is this
[19:59] <bryce> it's good for upstream to get widespread testing feedback on rc's
[19:59] <tjaalton> I'll ask on #debian-x if it could go to experimental as well
[19:59] <bryce> however users are going to do this by filing bugs through us
[19:59] <bryce> we simply don't have the manpower to forward those bug reports up to them in a timely manner
[20:00] <bryce> meanwhile, we get buried under more bug reports :-)
[20:00] <tjaalton> we need to keep the devel version unstable enough to keep the random-joe out ;)
[20:00] <bryce> I would rather see users test rcs in a ppa (like edgers) on an opt-in basis and report problems directly to upstream, so they get the feedback more swiftly
[20:02] <bryce> for stuff where upstream says "fixed in 1.2.3", to just update our bug's title to include "(Needs 1.2.3)", so when we pull in that released version, we can easily close all the bugs
[20:03] <bryce> however, I'm still kind of mulling all these thoughts about
[20:03] <tormod> yes, there seems to be plenty of people trying out PPAs, and the most eager are also those who would report upstream themselves
[20:03] <bryce> I suppose to follow the logic through, we'd need some kind of an xorg-proposed ppa or something for putting rc's and pending package updates
[20:03] <bryce> which seems like a bit extra overhead, not sure
[20:04] <bryce> we've had good luck and results from xorg-edgers though
[20:04] <tormod> isn't karmic = proposed ATM?
[20:04] <bryce> xorg-proposed-proposed ?  ;-)
[20:04] <tormod> we don't need something between xorg-edgers and karmic IMO
[20:05] <bryce> certainly we're early enough in development that it's probably not a huge deal, esp. for mesa which we know is going to get many updates and a couple releases before we're through
[20:05] <bryce> I guess it depends a lot on how desperately we need the fixes it contains, and how vigorously we plan to follow up on bug reports
[20:06] <tormod> I am just thinking we will get the bug reports anyway, but better have them now 5 months before release than 1 month before
[20:06] <bryce> but I'm reminded of the situation we went through with -intel in jaunty, where we merged it in fairly early on, and just got buried under bug reports
[20:06] <tormod> minus the ones being fixed "by themselves"
[20:07] <tjaalton> bryce: but that can't happen anymore <g>
[20:07] <tormod> bryce: I think that tells more about intel than of early merging...
[20:07] <bryce> perhaps
[20:08] <tormod> of course, we save bug work by waiting, but we don't do our community duties
[20:08] <bryce> I just think if we got a >little< bit more testing before sticking it in the archive, we could have had a better chance of making a better choice there
[20:09] <bryce> community duties?
[20:09] <tormod> helping upstream
[20:10] <bryce> I think that's orthogonal though - if we have fewer bug reports about Ubuntu, we'd have more time to do upstream work / toolsmithing / etc.
[20:10] <tjaalton> bryce: sure, I'll upgrade to karmic and test every package that it works somewhat before uploading
[20:11] <bryce> mm, on the other hand, I guess we could get better about reverting things once they start accumulating a lot of bugs
[20:12] <bryce> I'm not sure reverting -intel would have gained anything in the end really, but we've typically been more of the "damn the torpedo's, we'll fix the bugs as we go", which ends up with a lot of work to do late in the release
[20:13] <bryce> tjaalton: unfortunately IIRC both you and I tested the -intel upload and didn't see the problems.  I think I did not test on compiz (I never saw problems until turning on compiz).
[20:17] <bryce> anyway, hope I'm not sounding to ranty :-)
[20:17] <tjaalton> and I didn't think the slowdown was critical
[20:17] <tjaalton> :)
[20:17] <bryce> heh, me either but seems we were in the minority ;-)
[20:18] <tjaalton> x11perf --aa10text became faster though
[20:18] <tjaalton> threefold
[20:18] <bryce> tjaalton: fwiw, lately I've noticed a lot of the remaining perf/freeze bugs are being reported by kubuntu users, so I've wondered if Qt is misbehaving with X somehow
[20:19] <bryce> I found a bug where the KDE upstream was lamenting that Ubuntu moved to the newer Qt since it wasn't as well tested and was expected to have problems (corruption, etc.) so I wonder if some of this is an outcome of that
[20:20] <tjaalton> I've heard about that too
[20:20] <tjaalton> too bad I have to maintain both DE's..
[20:21] <bryce> yeah, we need another X guy from the Kubuntu side of things
[20:22] <mnemo> to avoid uploading things with completely "unknown" quality we could create a "about-to-be-merged-version" that we then test ourselves by checking a finite set of core use cases / scenarios that we feel any upload _must_ pass... it would be a table with "core use case" on one axis and "chipset" on the other axis... if we offer a finite and fairly small todo list like that we could probably get more people to complete this sanity test
[20:23] <mnemo> imo the focus for karmic should be to get kms, uxa and radeon-rewrite in a good state for the LTS... i'd rather have some mayhem now and then get something rock solid for the LTS
[20:23] <bryce> that is a good point
[20:27] <bryce> mnemo: certainly for 10.4 I think an "about-to-be-merged-version" ppa could be of value
[20:28] <bryce> for karmic, I guess tormod is right, that it's intended to be a playground, so the extra overhead would slow us down
[20:28] <tjaalton> yeah
[20:29] <tjaalton> and it's hard to track all the ppa's
[20:29] <bryce> at least, up until alpha-5 or so
[20:29] <bryce> tjaalton: well, presumably we'd use xorg-edgers as tormod says
[20:30] <bryce> although, I'm not sure about a case where we have 1.0 in the archive, and want to go to 1.1, but xorg-edgers has 1.2~git1234 in it
[20:54] <tormod> meanwhile, I suggest updating mesa in git, which we'll pick up in xorg-edgers, and ask for testing there until alpha-1 is out
[20:55] <tjaalton> very well then ;)
[20:55] <bryce> sounds fine by me
[20:56] <tjaalton> libdrm git merge pushed
[20:57] <tormod> by the time we get really conservative and consider a released 1.1, a "proposed" PPA would make sense, since xorg-edgers should stay on the edge
[20:57] <tormod> (referring to Bryce's example above)
[21:02] <tormod> mnemo: radeon-rewrite = mayhem :)
[21:03] <mnemo> hehe :)  bring it on
[21:03] <mnemo> (my main machine is intel)
[21:03] <mnemo> ;>
[21:04] <Sarvatt> phew, fix for the no dri on intel in mesa 7.6 the past few days finally got fixed
[21:05] <tormod> mnemo: you have mayhem enough on intel from what I hear
[21:09] <tormod> Sarvatt: btw what's the status of the 102_dont-vblank patch?
[21:11] <Sarvatt> that was me updating at 5 am and canceling auto-xorg-git after changelog update to edit it and it not having reverted 102 before, when i looked at the source it was patched but i didnt realize that till after
[21:12] <Sarvatt> was planning on fixing it when i got home, just got done with 7.6 and doing 7.5 now
[21:13] <tormod> Sarvatt: 5 am :)
[21:14] <Sarvatt> yeah, bad idea to update mesa at 5 am, of course things go wrong and i end up staying up an extra hour or two :D
[21:15] <Sarvatt> ya missed all the fun with dri being broken on intel and fixing the libglew1.5-dev conflicts while you were on vacation! :D
[21:16] <tormod> Sarvatt: you can wait for tjaalton to update ubuntu/origin now :)
[21:16] <tormod> *origin/ubuntu
[21:17] <Sarvatt> tjaalton,:you know about mesa shipping libglew headers in 7.5+ to build demos now so a change is needed for mesa-common-dev.install right?
[21:19] <Sarvatt> that darn glxew.h gets installed and causes a conflict without changing it since it calls usr/include/GL/glx*.h in the .install
[21:24] <tormod> bryce, does blender (the menus) work on your radeons? blender was always good for testing since it uses OpenGL exclusively
[21:25]  * bryce fires it up
[21:26] <bryce> oops, not installed... standby
[21:28] <tjaalton> Sarvatt: nope
[21:29] <tjaalton> Sarvatt: I mean, no idea
[21:32] <bryce> tormod: seems to work ok
[21:32] <tormod> bryce: which card? on stock jaunty?
[21:33] <bryce> 01:00.0 VGA compatible controller: ATI Technologies Inc RV535 [Radeon X1650 Series] (rev 9e)
[21:33] <bryce> yes, stock jaunty; I've not upped to karmic yet
[21:36] <jpds> Hey, does anyone here have any experience with Wacom?
[21:37] <tjaalton> some
[21:38]  * tjaalton wishes for a intuos4
[21:38] <tjaalton> aN
[21:38] <jpds> This was the original error I was getting: http://paste.ubuntu.com/170946/
[21:38] <jpds> I've managed to fix it, GDM starts, it just doesn't recognize the keyboard and mouse.
[21:39] <tjaalton> remove it from xorg.conf
[21:39] <bryce> apw: for bug 314928, is that going to be fixed kernel side, or should I push the patch jbarnes suggested into -proposed, or?
[21:39] <jpds> tjaalton: I did, now it's not recognized.
[21:39] <jbarnes> bryce: that one has to be fixed in the 2d driver
[21:39] <tjaalton> jpds: ok, then I'd like to see the lshal output, and the logfile
[21:40] <jpds> I even tried dpkg-reconfigure xserver-xorg
[21:40] <jpds> tjaalton: One sec.
[21:40] <jbarnes> bryce: have you received test results for it?
[21:40] <bryce> jbarnes: no not yet
[21:40] <bryce> jbarnes: apw made a comment that it worked for him, but I was a little unsure what that meant we should do
[21:41] <bryce> jbarnes, apw: anyway, if we want to push this to -proposed I've got it packaged and am good to go, I just need a go ahead from both of you that this is the right solution
[21:42] <mnemo> tormod: fwiw, i have an old ATI machine with a radeon 9600 (r300) and karmic... and there the menus look fine
[21:43] <jpds> tjaalton: New log: http://paste.ubuntu.com/170960/
[21:43] <jpds> tjaalton: For some reason HAL can't seem start up.
[21:44] <tjaalton> jpds: you've disabled it in xorg.conf?
[21:44] <tjaalton> just move the whole file aside and restart gdm
[21:44] <jpds> tjaalton: I did that too, not recognized.
[21:45] <tjaalton> jpds: so start hal? X doesn't do that
[21:46] <bryce> jbarnes: do you think bug 370292 is a dupe of 314928?
[21:53] <jpds> tjaalton: Weird, all fixed now.
[21:53] <jpds> I wonder why dbus wasn't starting on boot the other times.
[21:53] <jbarnes> bryce: sounds different
[21:53] <tjaalton> jpds: heh, ok
[21:53] <jbarnes> the mtrr thing should just cause a big slowdown but not a hang
[21:57] <bryce> ok
[22:03] <Sarvatt> are you using karmic jpds? there was a dbus problem all day yesterday screwing up hal that got fixed last night
[22:14] <mnemo> Sarvatt: is it safe to run update manager normally in karmic now?
[22:15] <Sarvatt> yup
[22:16] <Sarvatt> unless you're on kubuntu that is :D
[22:16] <mnemo> nah im not
[22:30] <Sarvatt> good to see the progress bar works in KMS usplash now with 2.6.30-rc5
[22:32] <tjaalton> usplash works with kms?
[22:32] <Sarvatt> yup
[22:33] <Sarvatt> it always has, only the progress bar didnt work before
[22:33] <tjaalton> ok
[22:34] <tjaalton> I'll defer the new mesa until "later", it has a truckload of conflicts with the previous version, just like I feared
[22:35] <Sarvatt> if it helps any the changelogs have what we have to do to build it on here https://launchpad.net/~xorg-edgers/+archive/ppa
[22:37] <tjaalton> it could, thanks
[22:38] <tjaalton> just merging the upstream branch is painful, like with every major mesa release
[22:44] <Sarvatt> --disable-egl in the confflags-[dos] targets, making the glx*.h change in mesa-common-dev.install and disabling patches 02 103 104 106 are the only things needed really after merging debian from origin/ubuntu
[23:49] <mnemo> bryce: once intel 2.7.1 is out we're gonna put it into X-Updates right?
[23:49] <bryce> yes
[23:50] <mnemo> just wanted to confirm
[23:50] <mnemo> thx
[23:54] <mnemo> bryce: what should put in title for a bug that's fixed in 2.7.1 and later... suffix with "(needs intel 2.7.1 or later)" or do you have some specific string you search for?
[23:55] <Sarvatt> another bug I'm hitting on -intel UXA now in 2.7+ - font corruption when the system starts swapping. I didn't notice because I dont usually use a swap file :(
[23:55] <bryce> (needs intel 2.7.1) is good
[23:57] <mnemo> Sarvatt: interesting.. i've never seen that either (but I have 8gb of ram) however I've seen many people with old intel chipsets talk about such corruption... I guess those boxes tend to have less ram as well so their are more likely to swap
[23:58] <Sarvatt> http://bugs.freedesktop.org/show_bug.cgi?id=21415


[01:07] <milleja46> anyone know how to fix http://pastebin.com/haeK7p0J? I'm on mac if it helps...
[01:07] <milleja46> but it's more of a key error I guess
[02:10] <milleja46> anyone? I can't even checkout branches on my computer because of this key error and I gave launchpad my ssh public key that I generated....
[02:11] <lifeless> lets see
[02:12] <lifeless> milleja46: check you have the right username
[02:12] <milleja46> I should....because I use the same username on launchpad...
[02:15] <milleja46> yea same id I set on bzr as my launchpad-login is listed under my profile on launchpad....
[02:19] <lifeless> you might try ssh-add
[02:19] <lifeless> check that ssh can see the identity
[02:21] <milleja46> how would I check with that command?
[02:39] <milleja46> well too bad he's gone I was going to thank him for his help >_<
[08:01] <mgz> morning!
[08:08] <jam> morning mgz
[08:08] <jam> how's bzr-2.5 coming today?
[08:36] <jelmer> hi mgz, jam
[08:36] <jelmer> jam: So, db-devel-bzr-2.5.1 ran through ec2 successfully yesterday
[08:36] <jam> great
[08:36] <jelmer> jam: so I'm hoping to get it cowboyed on staging today
[08:42] <mgz> hm, annoying
[08:43] <jelmer> mgz: who is?
[09:12] <jml> :)
[11:46] <jelmer> mgz: new try:
[11:47] <mgz> even gazillionier faster?
[19:08] <fullermd> Gaaah, stupid can't-resolve freakin conflicts.
[19:11] <mgz> fullermd: which ones, just for my edification?
[19:12] <fullermd> Removed directories.  They don't go away until you manually type every zarking last one of them in.
[19:12] <mgz> want to know if the branches I have up will solve your pain
[19:12] <mgz> ah, great, they will.
[19:12] <fullermd> Or swing the "resolve --all" sledgehammer, but that's WAY too big.
[19:12] <fullermd> Oh?  That would be nice.
[19:12] <mgz> okay, so, I need to push through the branches I have up, then you can rm -rf then `bzr resolve`
[19:12] <fullermd> I was just seeing if I'd filed a bug about it, and I did.  5 years ago.
[19:13] <mgz> not quite the "make `bzr rm` do the right thing" you asked for in the bug, but nearly
[19:14] <fullermd> Yeah, that'd be close.
[19:14] <fullermd> Actually, this particular case, I'm not sure it should be a conflict anyway.
[19:14] <fullermd> Giant directory tree, that was removed.  I happened to have a few scraps floating around in it.
[19:14] <fullermd> So when I update'd, I got a giant pile of "can't remove dir because it's not empty" conflicts.
[19:15] <fullermd> I guess it's not entirely insensible in general for that to be a conflict that sticks around bugging you in stat/etc forever, but it sure is in this case.
[19:16] <mgz> that's the ignored junk/precious problem, which is part of what has gunked people up who wanted to get this fixed
[19:16] <fullermd> Well, I dunno.
[19:16] <fullermd> I mean, it shouldn't _delete_ the files, sure.
[19:17] <fullermd> Or even move them aside, probably.
[19:17] <fullermd> And if they were versioned files, deleting the dir absolutely should be a conflict.
[19:17] <fullermd> But they weren't.  Why is it a conflict that the now-unversioned directory just can't be deleted?
[19:19] <fullermd> The junk/precious would be more like a dir becoming versioned, and what to do with the existing unversioned dir of the same name with files in it.
[19:20] <mgz> well, you can set vila's config option I can never remember the name of to move them
[19:21] <fullermd> Furrfu.
[19:21] <fullermd> Repository checkout (format: 1.9)
[19:21] <fullermd> I really should get around to fixing that one of these days...
[21:49] <mgrandi> so
[21:49] <mgrandi> has anyone had any luck dpushing to a bitbucket git repo?
[21:50] <mgrandi> cause i'm getting 'invalid repo syntax'
[22:09] <mgrandi> now i cant get it to just push to a regular localhost git repo =/
[22:10] <mgrandi> so i dunno if oyu are there jelmer
[23:13] <jelmer> mgrandi, hi
[23:13] <jelmer> mgrandi, still there?
[23:14] <mgrandi> yeah
[23:14] <mgrandi> i figured it out, you answered it in a launchpad question thingy
[23:14] <mgrandi> but i agree its very confusing
[23:14] <mgrandi> https://answers.launchpad.net/bzr-git/+question/148313
[23:14] <jelmer> ah
[23:18] <mgrandi> but yeah that should be fixed
[23:19] <mgrandi> also, i can't seem to dpush to bitbucket, have you had any luck with that?
[23:34] <jelmer> mgrandi: dpush doesn't create new branches yet, that's the issue
[23:34] <jelmer> mgrandi: I think that should work - how does it fail?
[23:34] <mgrandi> let me create a separate bitbucket thingy, one sec
[23:39] <mgrandi> bitbucket responds with 'conq: invalid repository syntax.'
[23:42] <mgrandi> with git bzr dpush git+ssh://git@bitbucket.org:mgrandi/myscriptstmp.git,branch=master
[23:42] <mgrandi> i cloned the empty bitbucket git repo, added a file so it created branch master, pushed that to bitbucket, then tried to run that ^
[23:43] <jelmer> mgrandi: that's not a valid URL
[23:43] <jelmer> mgrandi: : is used to separate hsot and port
[23:44] <jelmer> mgrandi, you want / rather than : there
[23:44] <mgrandi> thats how bitbucket shows the url
[23:45] <mgrandi> Clone this repository (size: 580 bytes): HTTPS / SSH  / SourceTree
[23:45] <mgrandi> $ git clone git@bitbucket.org:mgrandi/myscriptstmp.git
[23:45] <jelmer> mgrandi: that's not a URL, but a git-specific location specifier
[23:45] <mgrandi> ah
[23:46] <jelmer> git+ssh://git@bitbucket.org/mgrandi/myscriptstmp.git,branch=master
[23:46] <mgrandi> well i changed it to a slahs, it seemed to work but then it says "bzr: ERROR: The file id "None" is not present in the tree <bzrlib.inventory.CHKInventory object at 0x10fb39ed0>.                           "
[23:46] <jelmer> mgrandi, that's just a bug in dpush from bzr-git I suspect; it's all still experimental
[23:47] <mgrandi> ok
[23:49] <mgrandi> it converted it to git at least for the other repo that i cared about, so its all fine and dandy =)
[23:59] <jelmer> cool


[04:39] -queuebot:#ubuntu-release- Unapproved: budgie-desktop (zesty-proposed/universe) [10.2.9-3ubuntu3 => 10.2.9-3ubuntu4] (no packageset)
[04:57] -queuebot:#ubuntu-release- Unapproved: libdc0 (zesty-proposed/universe) [0.3.24~svn3121-4 => 0.3.24~svn3121-4ubuntu1] (no packageset)
[04:58] -queuebot:#ubuntu-release- Unapproved: accepted libdc0 [source] (zesty-proposed) [0.3.24~svn3121-4ubuntu1]
[07:29] -queuebot:#ubuntu-release- Unapproved: accepted curtin [source] (zesty-proposed) [0.1.0~bzr479-0ubuntu1]
[07:41] -queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (zesty-proposed) [0.7.9-77-g4a2b2f87-0ubuntu1]
[07:44] -queuebot:#ubuntu-release- Unapproved: accepted mate-panel [source] (zesty-proposed) [1.18.0-0ubuntu2]
[07:46] -queuebot:#ubuntu-release- Unapproved: accepted gnome-settings-daemon [source] (zesty-proposed) [3.24.0-0ubuntu2]
[13:15] -queuebot:#ubuntu-release- Unapproved: caja-dropbox (zesty-proposed/multiverse) [1.18.0-0ubuntu1 => 1.18.0-0ubuntu2] (ubuntu-mate)


[07:52] <na7e> anyone here who is decent with gimp wanna make a usplash image for me, possibly for an upcoming offshoot of ubuntu?
[07:52] <na7e> not a lot of people in here....
[09:17] <Tm_T> I'm testing Gnome, but now I found interesting problem, I can't find "run dialog" from anywhere, nor start it by alt-f2
[09:53] <lapo> hi
[11:09] <lapo> hi
[08:45] <lapo> http://xoomer.virgilio.it/bat/orango-tango/orango-tango-0.0.2.tar.bz2


[01:10] <steve__> Under KInfocenter -> Graphical Information ->  X-Server lists " Screen #0                (Default Screen)".   How can I change the Default Screen?
[01:11] <steve__> I have 3 monitors connected via Display Port, KDE flips out when I turn on my monitors.
[01:12] <steve__> KDE 5.7.5     Kubuntu 16.10
[01:13] <steve__> Using Kernel driver "radeon" and "ast"
[10:39] <BluesKaj> Hiyas all
[12:29] <seeit> what would cause an account to be unavailable to login if I did not delete it explicitly?
[12:32] <BluesKaj> seeit, never heard of that before
[12:32] <seeit> me either, I recall seeing the login name at the kde login about 4-5 days ago
[12:32] <seeit> but it is no longer there
[12:32] <seeit> the home directory is still there however
[12:33] <BluesKaj> what does your terminal prompt show ?
[12:33] <seeit> what do you mean? at login? or in konsole?
[12:33] <BluesKaj> or /etc/hostname and /etc/hosts
[12:34] <BluesKaj> konsole
[12:34] <BluesKaj> konsole=terminal
[12:34] <seeit> my hosts is pretty extensive with a lot of ad,malwre, and fakenews blocks
[12:34] <seeit> also social media
[12:35] <BluesKaj> why?
[12:35] <seeit> why not?
[12:36] <BluesKaj> never heard of using /etc/hosts being used to block urls
[12:37] <seeit> using it to block domains and point them to <IP_ADDRESS>
[12:37] <BluesKaj> anyway does your konsole prompt show your username?
[12:38] <seeit> yes, my username is there it's another account that is missing
[12:38] <BluesKaj> aha
[12:38] <seeit> the account is listed in /etc/passwd too
[12:39] <BluesKaj> well then i have no idea
[12:39] <seeit> yup there one day, gone the next
[14:06] <waka> waka
[14:19] <waka> waka
[14:19] <waka> waka
[15:01] <incibus> TÜ
[15:01] <incibus> Türk var mı?
[19:13] <marcinsky> hi


[12:25] <luckielordie> hi guys, In my Images section the status is "Waiting for rack controller(s) to sync"
[12:25] <luckielordie> Do i need to do anything in with my Rack Controller to get the image to sync?


[12:25] <shawn_work> Question: When is launchpad source code going to be released? will it be?
[12:27] <shawarma> Nothing's planned.
[12:27] <gnomefreak> shawn_work: best to ask in #launchpad (some of it is open)
[12:27] <shawarma> shawn_work: https://launchpad.net/faq <--- Search for "open source"
[12:27] <shawn_work> merci
[12:28] <shawarma> gnomefreak: Huh? Like what?
[12:28] <gnomefreak> shawarma: read the page you gave him ;)
[12:28] <gnomefreak> lol
[12:28] <gnomefreak> hold on ill find it
[12:28] <shawn_work> I See :(
[12:29] <gnomefreak>  Our goal is to release all of Launchpad as free software, though it will take some time (potentially, years) before that happens.
[12:29] <gnomefreak> We are doing so in a piecemeal approach. Parts of Launchpad have already been released as free software where they would be particularly useful to other projects.
[12:29] <shawarma> gnomefreak: Yes, but which parts?
[12:29] <gnomefreak> shawarma: dont know never asked
[12:30] <illovae> hello
[12:30] <shawarma> gnomefreak: Ah, ok.
[12:30] <gnomefreak> hi
[12:31] <illovae> excuse me, LaserJock are you available please ?
[12:38] <LaserJock> illovae: yep, what's up?
[12:39] <illovae> LaserJock: hi, first sorry for my english but it is not my native language ^^'
[12:39] <illovae> well i'm Hari Seldon from https://bugs.launchpad.net/ubuntu/+source/labplot/+bug/98547
[12:39] <ubotu> Malone bug 98547 in labplot "incorrect category in 'Applications' menu" [Wishlist,In progress]
[12:39] <LaserJock> oh hi
[12:39] <illovae> i've discuss of this bug with Adri2000 and mr_pouit and they told me there's nothing to fix...
[12:40] <illovae> i am an beginner in fixing so i don't know what can i do with this
[12:40] <illovae> i am interresting by you experience for closing it in the best way :)
[12:40] <illovae> your*
[12:40] <LaserJock> well, it's a bit of an unfortunate bug
[12:40] <illovae> ^^
[12:41] <LaserJock> technically, it should probably go in Education or Graphics
[12:42] <LaserJock> unfortunately early on I tried to tackle the "Science has no menu" problem
[12:42] <LaserJock> but it's really up to freedesktop.org
[12:42] <illovae> yes so for gnome there's no way for this bug
[12:42] <illovae> you have seen the .desktop for KDE are good
[12:43] <LaserJock> I infact did file a bug in Gnome about it
[12:43] <illovae> ah okay thanks, i didn't think to do it ^^'
[12:43] <illovae> so do i reject the bug ? if yes, how can i tell to close it ?
[12:44] <illovae> s/how/what
[12:44] <LaserJock> well, I guess we can reject it
[12:44] <illovae> "No fixing for ubuntu > bug reported upstream in GNOME ?"
[12:44] <LaserJock> I'm not happy about it
[12:44] <illovae> i understand, i'm not happy too
[12:44] <LaserJock> well, I think my Gnome bug was basically rejected too
[12:45] <illovae> arf
[12:45] <LaserJock> basically it seems to me that freedesktop.org has said that "Science" should be a submenu of "Education"
[12:45] <LaserJock> I should ask freedesktop about it I guess
[12:46] <LaserJock> anyway, for now, I think we should reject the bug
[12:46] <illovae> yes but you're agree it is not a good submenu "Education" for a science application :/
[12:46] <illovae> okay so
[12:46] <illovae> we don't make a .desktop for GNOME in the sources ?
[12:46] <illovae> or in the debian/ ?
[12:46] <LaserJock> not if it installs one already
[12:46] <illovae> a .desktop like > menu:Others ?
[12:46] <illovae> ah yes
[12:47] <LaserJock> no, in the .desktop we say something like Categories=Application;Science
[12:47] <LaserJock> it's just that basically Science = Other in the current menu
[12:47] <illovae> yes it's true
[12:47] <illovae> so it's a freedesktop.org problem i understand
[12:48] <LaserJock> to reject the bug you can click on the little arrow to the left of "labplot" under "Affects"
[12:48] <LaserJock> illovae: and I'm not sure it's one they see as a problem
[12:48] <illovae> arf :/
[12:49] <illovae> so i reject the bug and saying that : "Cannot fix this bug in Ubuntu - It's a bug/problem in the menu definition in freedesktop.org" ?
[12:51] <LaserJock> sure
[12:51] <LaserJock> illovae: check out http://standards.freedesktop.org/menu-spec/latest/apa.html
[12:52] <illovae> ah yes i saw it
[12:52] <LaserJock> notice that Science is a valid Category
[12:52] <illovae> yes
[12:52] <LaserJock> but it isn't in the "Main Menu" section
[12:53] <illovae> why there aren't a Education/Science category Education for main et Science for additional
[12:53] <illovae> ?
[12:53] <illovae> it would be the best ?
[12:54] <LaserJock> well, that's the part that is Gnome
[12:54] <LaserJock> Gnome doesn't do submenus
[12:54] <illovae> oups
[12:54] <illovae> yes :/
[12:54] <illovae> s/oups/ /
[12:55] <illovae> okay thank you for your help, just a little thing : can i quote your name in the bug reject ?
[12:55] <LaserJock> sure
[12:55] <illovae> okay thank you very much for your help, it was a real pleasure for me to discuss with you :)
[12:56] <LaserJock> no problem
[12:56] <LaserJock> anytime ;-)
[12:56] <illovae> :)
[01:48] <bdmurray> tepsipakki: ping
[02:46] <LeeJunFan> shouldn't the low-latency kernel have the hz timer set in /proc? by default the timer interrupts are turned off "0".
[02:50] <crimsun> the safe setting is preferred. You can always set it to 1.
[02:51] <crimsun> (does it really matter for idle, anyhow?)
[02:52] <LeeJunFan> crimsun: yeah, I just figure that most people expect the lowlatency kernel to give them low latency simply from installing it, but turning off interrupts is really turning of preempt isn't it?
[02:54] <ds> the tick rate is not related to kernel preemption
[02:58] <LeeJunFan> I don't think that corresponds to tick rate, it's just a 0/1 enable/disable. 0 is kernel interrupts are disabled.
[04:08] <derek_> is there any reason way a framebuffer isnt compiled into ubuntu kernel so we can have a bearable virtual terminal without recompiling the kernel..?
[04:09] <null__> derek_, i think it is compiled by default ?
[04:09] <null__> u should be able to just pass the vga= parameter to the kerenl opetion on bootup
[04:10] <derek_> what version of ubuntu
[04:10] <null__> i think all of the ones that have the ubuntu splash screen should support
[04:11] <derek_> vga=0F01
[04:11] <derek_> thats not with a frame buffer
[04:11] <null__> CONFIG_FRAMEBUFFER_CONSOLE=m
[04:11] <null__> that should be set in your kernel config
[04:11] <null__> check in /boot/config`uname -r`
[04:11] <mjg59> Because framebuffers mess up suspend/resume support
[04:12] <mjg59> If you pass a vga= argument to put the screen in a vesa mode, vesafb will be used
[04:12] <mjg59> But it's not going to be the default
[04:12] <null__> mjg59, really ?
[04:12] <null__> hmm i dont really have a proibme here
[04:12] <null__> but i am running the 2.6.20-3 vanilla tho
[04:13] <mjg59> It works on some hardware
[04:13] <mjg59> But not all
[04:13] <derek_> when i switched from gentoo i could no longer use the virtual terminals because how bad they are
[04:13] <null__> oh oki
[04:13] <mjg59> If you want to have a framebuffer, pass the boot option.
[04:13] <mjg59> But, as I said, it's not going to be the default.
[04:14] <null__> ahkkk
[04:15] <null__> u need to have CONFIG_VGA_CONSOLE=y for the vesa buffer
[04:15] <derek_> they need to get out of usplash
[04:15] <mjg59> ?
[04:15] <null__> out of usplash ?
[04:15] <derek_> stop using it
[04:15] <null__> mjg59, i believe that is the present default for ubuntu
[04:15] <null__> for the vesa fb
[04:15] <mjg59> Ok. I will say this one more time, and then that is the end of the conversation.
[04:16] <mjg59> If you want a framebuffer, pass the vga= argument to the kernel. Then you will have vesafb, which is broadly equivalent to what gentoo uses by default. This will not be the default on a stock Ubuntu installation, as it tends to interfere with power management on a large number of systems.
[04:16] <null__> derek_, yeah i have disabled the usplash
[04:16] <mjg59> If you have a framebuffer, usplash will use the framebuffer.
[04:17] <mjg59> Otherwise it will make vesa calls directly.
[04:17] <null__> thats right
[04:18] <mjg59> null__: I wrote the software, I know it's right :)
[04:18] <_ion> :-)
[04:18] <mbiebl> mjg59: I always wondered, why usplash can use arbitrary resolutions.
[04:18] <null__> hehe
[04:19] <mjg59> mbiebl: Because it uses code from svgalib to make direct vesa calls
[04:19] <mjg59> It can't actually do arbitrary resolutions, just ones that the vesa bios provides
[04:20] <mbiebl> mjg59: why is that safer (regarding suspend/resume) then using a fb directly? Just curious
[04:21] <mjg59> When you resume, you have no idea what state the video hardware is in
[04:22] <mjg59> The framebuffer that vesa gave you may no longer exist
[04:22] <mjg59> So writing to it isn't safe
[04:22] <mjg59> On the other hand, vga memory is basically specced to be there
[04:22] <mjg59> So it's not a problem to depend on it still existing
[04:22] <mjg59> The worst that can happen is that you get some garbage on the screen
[04:23] <mjg59> When usplash exits, it returns you to standard vga text mode (unless you're using a framebuffer, in which case it just exits)
[04:25] <mbiebl> Thanks for the clarification. So splashy, which relies on libdirectfb+a framebuffer is very likely to have more problems with suspend/resume.
[04:25] <mjg59> Yes
[04:25] <mjg59> That's why I wrote usplash
[04:26] <mjg59> libdirectfb simply doesn't provide the functionality we wanted
[04:26] <mjg59> And it was easier to start from scratch than to modify splashy to avoid the libdirectfb dependence
[04:27] <mbiebl> ok
[04:28] <mbiebl> Have you any plans to focuss more on uswsusp in the future?
[04:28] <mbiebl> So things like graphical suspend/resume work too.
[04:28] <mjg59> Yup
[04:28] <mjg59> The uswsusp package in our archive should Just Work
[04:28] <mjg59> Though I haven't had time to test it
[04:29] <mjg59> I'm trying to finish my PhD off at the moment, so I haven't had as much time as I'd have liked to work on this sort of thing lately...
[04:29] <mbiebl> ;-)
[04:30] <Hobbsee> morning all
[04:33] <bddebian> Heya Hobbsee
[04:34] <Hobbsee> hi bddebian :)
[04:34] <Mez> !seen keybuk
[04:34] <ubotu> Sorry, I don't know anything about seen keybuk - try searching on http://bots.ubuntulinux.nl/factoids.cgi
[04:35] <Hobbsee> [12:35]  [Notice]  -SeenServ- I last saw Keybuk<EMAIL_ADDRESS>10h 25m 53s ago, quiting: ""
[04:35] <Mez> I swear I saw keybuk tonight :D
[04:35] <Hobbsee> Mez: /msg seenserv seen keybuk
[04:35] <Mez> Hobbsee, already did that, ubotu used to do it for ou
[04:35] <Mez> I swear I saw Keybuk though :D hehe
[04:35] <Hobbsee> Mez: true.  hasnt done so for a long time
[04:36] <Mez> Hobbsee, and i haven;t used that functionality in a long time
[04:36] <Hobbsee> ahhh
[04:36] <Mez> I think I danced with keybuk tonight :D
[04:45] <Mez> I was at  gay bar
[04:45] <Mez> s/at  /at a /
[04:48] <Hobbsee> heh
[04:49] <StevenK> bddebian: Is that a pointy stick in your pocket or are you just really really pleased to see us?
[04:50] <bddebian> haha
[08:19] <janimo> cjwatson: hi, when you're around please let through xubuntu-meta, thunar and libxfce4mcs (the latter two are FTBFS related). thanks
[08:19] <janimo> crimsun: hi, libxfce4mcs alsoo needed .la removal
[08:21] <crimsun> janimo: ok
[08:21] <crimsun> that should be the last thing in the stack for xfdesktop4, then
[08:41] <janimo> crimsun: indeed. the last dev package using libstartup-notification-1.la seen by grepping /usr/lib/*a
[08:42] <janimo> crimsun: thunar does not use mcs so when I saw it had built I thoight it was only the gui4 lib
[10:30] <fabbione> Lathiat: ping?
[11:44] <ivoks> ok, debian will get zenoss packages
[11:44] <ivoks> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=361253
[11:44] <ubotu> Debian bug 361253 in wnpp "ITP: zenoss -- Zenoss is a powerful, integrated," [Wishlist,Open]
[11:44] <ivoks> (ups.. wrong channel)
[11:45] <Robot101> it's a powerful integrated? I always wanted one of those :D
[11:46] <bhale> its a network management portal
[11:47] <bhale> it looks pretty good, but i spent the last 2 years writing my own
[11:47] <ivoks> :)
[11:48] <bhale> which takes some focus away from event dashboard onto automation
[11:49] <mdke> whoosh! the dvdcss script has been put back
[12:18] <alex__> can anyone help me with my sound card and wifi card? I'm usuing ubuntu feisty running on LG laptop
[12:18] <mdke> alex__: you can try #ubuntu or #ubuntu+1, or http://www.ubuntu.com/support
[12:19] <alex__> so what this channel is for?
[12:19] <pochu> alex__: development, not support
[12:19] <mdke> discussion of Ubuntu development
[12:20] <mdke> each irc channel has a topic you can read, at the top of your screen, which explains what the channel is about
[12:20] <alex__> what the disscusion is about? Ideas or help applying new things? requests?
[12:21] <mdke> discussion of specific problems that the developers have
[12:23] <alex__> so I still have two more questions if you don't mind
[12:23] <poningru> alex__: #ubuntu+1 is for you
[12:23] <poningru> dude...
[12:24] <alex__> it's not a suuport isue
[12:25] <alex__> ok, I get it. thanks anyway
[12:30] <Hobbsee> mdke: what do you mean?  (the dvdcss script)
[01:05] <Hobbsee> oh, found it.
[01:15] <Riddell> Mithrandir: new adept uploaded http://kubuntu.org/~jriddell/tmp/adept_2.1.2ubuntu25.debdiff
[01:19] <Lathiat> fabbione: pong?
[01:34] <Riddell> Lathiat: he's on holiday (as is almost everyone else)
[01:38] <StevenK> Mithrandir: New ipvsadm uploaded, debdiff is http://wedontsleep.org/~steven/ipvsadm.debdiff
[01:41] <Riddell> most inconvenient really
[01:42] <StevenK> Hopefully, cjwatson will notice.
[01:56] <cjwatson> StevenK: accepted
[01:56] <cjwatson> (I'm aware of everything else in the queue as of now, but haven't reviewed all of it yet due to aforementioned holiday)
[01:58] <StevenK> cjwatson: Thanks!
[02:00] <cjwatson> Riddell: accepted
[02:09] <Riddell> thanks
[02:10] <StevenK> Oh, you can tell when uploads are being held.
[02:10] <StevenK> The buildds just *pounce* on everything.
[02:46] <rouzic> Hi everybody
[02:47] <rouzic> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/103413
[02:47] <ubotu> Malone bug 103413 in linux-source-2.6.20 "(Feisty) During boot, configuring network interface is very slow" [Undecided,Confirmed]
[02:50] <robertj> can someone please look at https://wiki.ubuntu.com/SimpleSambaIntegrationSpec and tell me if that is a viable solution to the people who are filing bugs against samba "not working" when its just that they haven't created samba users
[03:22] <Lathiat> fabbione: ah wellhe pinged me a fewhours aho
[03:22] <Lathiat> err
[03:22] <Lathiat> Riddell: he pingedmea few hoursback
[03:22] <Lathiat> typing on these olpc keyboards is abit ofan art
[03:24] <shawarma> It must be if you mistype "Riddell" as "fabbione".
[03:24] <shawarma> That's really... wow.
[03:27] <StevenK> Hah
[03:54] <mdke> :)
[03:59] <doko> cjwatson: please have a look at http://people.ubuntu.com/~doko/tmp/bash.debdiff
[04:00] <Tonio_> Mithrandir: I just uploaded dolphin for universe
[04:01] <Tonio_> Mithrandir: I put a patch so that it deals with kde ioslave, otherwise switching to it as default would break a lot of things on the desktop, including the kicker
[04:01] <Tonio_> Mithrandir: hope it is okay to be approved :)
[04:01] <Riddell> Tonio_: universe packages shouldn't need approved
[04:02] <Tonio_> Riddell: but they do....
[04:02] <Tonio_> This upload awaits approval by a distro manager
[04:02] <Riddell> oh, ok
[04:02] <Tonio_> I wouldn't ping here if that wasn't frozen too :)
[04:03] <StevenK> This is because selected components can't be subjected to the freeze. Otherwise main and restricted would freeze leaving universe and multiverse thawed.
[04:03] <geser> universe doesn't need approval like main but an archive admin must accepted them by hand
[04:04] <geser> after April 12th universe needs approval too (from motu-uvf?)
[04:07] <StevenK> geser: More than likely. What happened for Edgy was ubuntu-release picked a few universe people to say yay or nay
[04:22] <fabbione> Lathiat: re... sorry.. still around?
[04:54] <Lure_> Tonio_: universe is just on manual, not in approval-required yet
[04:55] <Tonio_> Lure_: hum okay
[04:55] <Tonio_> Lure_: so who will proceed ? :)
[04:56] <Lure_> Tonio_: archive-admins are doing them on regular basis (probably not as much today and over WE due to holidays)
[04:56] <Lure_> Tonio_: universe freeze is Apr 12, afair
[04:56] <Tonio_> Lure_: yup I noticed that concerning universe
[04:57] <Tonio_> Lure_: I'll just wait then :)
[05:05] <rmjb> hello, I'm looking for someone from the kernel team
[05:07] <Hobbsee> rmjb: it's a public holiday
[05:07] <kylem> not really...
[05:07] <kylem> rmjb, join #ubuntu-kernel
[05:07] <mjg59> Hobbsee: In parts of the world, yeah
[05:08] <Hobbsee> most of them, i thoguht
[05:08] <kylem> some of us don't care about non-secular holidays.
[05:09] <rmjb_> hi, sorry about that, my "reliable" isp just dropped my connection again, is there anyone from the kernel team here?
[05:09] <Hobbsee> kylem: well of course - but i would have thought the "any excuse for a holiday" applies
[05:10] <Hobbsee> kylem: no matter whether you agree in what it's for or not
[05:10] <mjg59> Hobbsee: You haven't seen a Canonical employment contract :p
[05:10] <Hobbsee> mjg59: true that.  it's about as bad as my work's, then?
[05:10] <mjg59> Well, Kyle's working, so we can make assumptions :)
[05:11] <sharms> Its not a holiday in the US thats for sure
[05:11] <Hobbsee> sharms: weird!  i thought it was.
[05:11] <kylem> Hobbsee, feh.
[05:11] <Hobbsee> hehe
[05:12] <sharms> ha
[05:13] <kylem> Hobbsee, no, almost everyone is off today.
[05:13] <Hobbsee> kylem: right.
[05:13] <Riddell> they're all skiving
[05:13] <Riddell> he's skiving :)
[05:15] <sharms> What holiday are we talking about? I am 90% sure there isnt once in US
[05:16] <Hobbsee> sharms: it's easter in a whole lot of countries.
[05:16] <sharms> ah that is sunday here?
[05:16] <Hobbsee> no idea
[05:17] <sharms> that is the day we lay easter eggs and go out in the yard and retrieve them
[05:17] <mjg59> It's Good Friday today
[05:17] <sharms> although for some reason since I stopped living at my parents, the easter bunny stopped coming
[05:17] <mjg59> More of a "Jesus being nailed to a cross" thing than an easter bunny one
[05:18] <sharms> I think that is discrediting the bunny
[05:18] <kylem> mjg59, is that the guy who founded your college? :)
[05:19] <mjg59> That lad, yeah
[05:22] <sharms> hey since we have a crowd today, does anyone know if gcc 4.2 is for sure going to be in feisty + 1?
[05:34] <Mirv> does anyone have an idea why the "Install" icon on the desktop does not show its translations? all the translations are there in the ubiquity-gtkui.desktop, so it might be possibly to fix this for feisty?
[05:35] <Mirv> hmm, it's translated under System/Administration menu, but if it's again added/copied to the desktop from there, it's shown as untranslated
[06:09] <Mirv> hmm hmm, it happens only on the live-cd, and for each item that is on the desktop. but it does not happen on an installed system. the translation are there in the menus. would someone have an idea in what part of the system the problem could be? I could try to find some relevant bug.
[06:10] <Mirv> there shouldn't be too many differences between a live system and an installed system, I gather
[06:16] <Mirv> well, I added the information to bug 45741 , and added nautilus to it (purely guessing)
[06:16] <ubotu> Malone bug 45741 in ubiquity "Ubiquity desktop icon "Install" is not translated" [High,Confirmed]  https://launchpad.net/bugs/45741
[06:36] <cjwatson> doko: I'm curious about why we're bothering to apply patches that claim not to even affect our system
[06:37] <doko> cjwatson: counts the patch counter up; I can leave it out, but then I have to modify the patch
[06:38] <cjwatson> doko: what's the release-critical bug you're trying to fix here? I've only skimmed the patch
[06:38] <cjwatson> doko: similarly for python 2.5.1rc1 - would like to know what release-critical bugs it's fixing
[06:38] <doko> cjwatson: bash?
[06:39] <cjwatson> both
[06:39] <doko> cjwatson: ? yesterday you agreed to an UVF exception for python 2.5.1 ...
[06:39] <cjwatson> I did? it's been a busy couple of days ...
[06:40] <cjwatson> remind me what the reason you gave was
[06:40] <cjwatson> I think I may have been under the impression that you were updating from 2.5.1rc1 to 2.5.1, which would have been a different matter
[06:40] <cjwatson> (the more actual releases and the fewer release candidates, the better)
[06:44] <doko> wait, extracting the diffs for python2.5
[06:45] <doko> cjwatson: bash32-013 is one crash fix, that the same for readline5
[06:48] <doko> cjwatson: http://people.ubuntu.com/~doko/tmp/python2.5-changes , the locale.strxfrm fix already is in python2.4
[06:52] <sharms> Anyone want to help me get some action going on: https://wiki.ubuntu.com/Spec/EnhancedBash
[06:55] <cjwatson> doko: bash up to 013 is fine; 014 scares me as it changes parsing (possibly for the better, but I don't really want to risk it), and 015 doesn't apply to us as we have /dev/fd
[06:56] <cjwatson> doko: the python2.5 diff is huge; can we just have a targeted patch for the locale.strxfrm bug?
[06:56] <cjwatson> when I looked at the diff, it changed a lot more than what that release notes diff indicated
[06:57] <doko> wait, sending a diff of the two trees
 cjwatson: (sorry, wrong channel) would like to update python2.5 to the 2.5.1 release candidate 1 today; see bug 103302
 Malone bug 103302 in python2.5 "UVF exception for python 2.5.1" [Undecided,Unconfirmed]  https://launchpad.net/bugs/103302
[06:57] <doko> * illovae_ ist jetzt bekannt als illovae
 doko: ok, that's fine
[06:57] <ubotu> Malone bug 103302 in python2.5 "UVF exception for python 2.5.1" [Undecided,Confirmed]  https://launchpad.net/bugs/103302
[06:59] <cjwatson> doko: ok, sorry, I was obviously frazzled and misunderstood, plus the release notes diff you sent at that point was a lot less scary than the actual diff
[06:59] <cjwatson> score -1 for release notes
[06:59] <illovae> ?
[07:00] <cjwatson> illovae: ignore it, it's just a paste of an IRC log fragment
[07:01] <illovae> arf okay ^^ thanks
[07:08] <doko> cjwatson: http://people.ubuntu.com/~doko/tmp/python2.5.diff ; removed the PC build changes and the changes where just revision Ids are changed.
[07:10] <cjwatson> doko: I would prefer a fix for just the locale.strxfrm bug, if you don't mind
[07:10] <Lathiat> fabbione: am now
[07:10] <Lathiat> fabbione: 3 hours later again ;)
[07:11] <Lathiat> fabbione: feel free to just ask or email<EMAIL_ADDRESS>[07:11] <doko> cjwatson: I would really prefer the update to the rc1. mvo did have enough problems with pickling changes in 2.5
[07:12] <doko> s/changes/bugs/
[07:12] <cjwatson> are there bug numbers?
[07:13] <cjwatson> it would really help if you told me all the reasons at once :-)
[07:13] <cjwatson> rather than bringing up a new reason each time I have an objection
[07:13] <cjwatson> I don't have much time here
[07:13] <cjwatson> and I guarantee that mdz will be asking me why I accepted this
[07:17] <doko> cjwatson: the upstream bug numbers are mentioned in the NEWS file; the locale.strxfrm bug is debian #416931. we should know python upstream very well, that they don't introduce new stuff in point releases, plus in the past we always shipped with the current release or releae candidate
[07:17] <ubotu> Debian bug 416931 in python2.4 "python2.4: off-by-one bug in strxfrm() (causes information leak)" [Important,Closed]  http://bugs.debian.org/416931
[07:18] <cjwatson> doko: what's that timemodule change?
[07:18] <doko> 30% of the patch are documentation fixes
[07:18] <cjwatson> for the record, arguments that go "but upstream are really good" don't tend to go over very well with me :)
[07:19] <cjwatson> I knew about the locale.strxfrm bug. That's one line
[07:19] <cjwatson> ah, the timemodule change is Windows-only
[07:20] <doko> cjwatson: ifdef windows
[07:20] <doko> cjwatson: remove the IN.py diff; that's my mistake
[07:21] <cjwatson> see, the thing you uploaded is a 160929-line diff
[07:21] <cjwatson> the thing you're showing me now is 876 lines
[07:21] <cjwatson> which is it? :)
[07:22] <doko> Colin, ...
[07:22] <cjwatson> no, really, this is something I will be called on
[07:22] <cjwatson> you need to help me justify it
[07:22] <doko> cjwatson: the diff are the regenerated docs (debian/patches/docs.uue)
[07:23] <doko> - the removed debian/patches/svn-updates.diff
[07:23] <doko> I don't hide any diffs, the diff was meant to have a clear look at the changes
[07:24] <doko> there are about 200 diff lines doc changes
[07:26] <cjwatson> I'm not accusing you of anything, I'm just finding it hard to reconcile
[07:26] <cjwatson> copying the diff down now to try to get a better look locally
[07:28] <cjwatson> dinnertime, will continue to look later on
[08:06] <jabra> I have a debian package I would like to get updated in feisty if possible
[08:07] <jabra> the recent update is in debian unstable
[08:07] <robertj> ajmitch: can you look at https://wiki.ubuntu.com/SimpleSambaIntegrationSpec for 60 seconds and give me an initial good-idea bad-idea impression?
[08:29] <Adri2000> jabra: which component ? main, universe? is it a new upstream release or just an update of the package?
[08:30] <jabra> update to fix a bug
[08:30] <jabra> it is in universe
[08:30] <jabra> package is called pbnj
[08:30] <Adri2000> jabra: ok, then it's possible to request a sync
[08:30] <jabra> k
[08:31] <jabra> so should I just submit a bug for the request to sync
[08:31] <Adri2000> jabra: yes: https://wiki.ubuntu.com/SyncRequestProcess
[08:31] <jabra> cool thanks
[08:32] <jabra> will it be able to get into feisty ?
[08:33] <Adri2000> yes, if you do it now and if you get a developer to ack your sync request quickly
[08:33] <Adri2000> this is done by subscribing ubuntu-universe-sponsors to the bug, and/or asking in #ubuntu-motu
[08:34] <jabra> k
[08:45] <gnomefreak> bdmurray: good luck in -bugs. she will never leave you alone now :(
[08:46] <bdmurray> gnomefreak: thanks for the warning
[08:47] <gnomefreak> yw
[08:47] <bdmurray> maybe if I just don't respond now
[08:47] <cjwatson> doko: ok, I think I have resolved some of my confusion by realising that many of the changes were already present in debian/patches/svn-updates.diff
[08:47] <cjwatson> doko: it would REALLY have helped if you had just said that up-front, instead of making me try to guess
[08:47] <gnomefreak> good luck
[08:48] <cjwatson> doko: everyone on the release team is under a lot of pressure to make exactly the right decision at the moment
[09:05] <doko> cjwatson: I don't deny that; anyway, I'll have to leave now, trying to get internet access tomorrow or on Sunday. the readline5 patch is the same as the bash32-013 patch; is that one approved as well?
[09:06] <doko> I updated the python2.5 package on chinstrap:~doko/for-feisty
[09:26] <mdke> cjwatson: around?
[09:28] <mdke> or elmo, mako, sabdfl?
[10:56] <unfo> hi all, how do i forward a bug to an upstream devel mailing list so that list members can click "Reply to All" and replies will get into launchpad?
[10:57] <LaserJock> hmm, like for a specific bug?
[10:57] <unfo> LaserJock: yes, a bug in emacs-snapshot
[10:58] <LaserJock> I'm not exactly sure if that's possible
[10:58] <LaserJock> I think you can use <bug<EMAIL_ADDRESS>[10:58] <LaserJock> but I'm not sure if that's suitable for that kind of thing
[10:59] <unfo> if I email the bug report text to the list and CC <bug<EMAIL_ADDRESS>then when people Reply to All, will it get into lp?
[10:59] <unfo> or will that fail because they're not registered lp users?
[11:01] <LaserJock> I'm really not sure
[11:02] <LaserJock> you might have to ask the Launchpad people
[11:02] <unfo> ok, i'll ask on channel #launchpad.
[11:33] <Burgwork> unfo: it will fail, because LP only accepts signed mail
[11:33] <Burgwork> LaserJock: ^
[11:34] <unfo> Burgwork: oh. :(
[11:34] <Burgwork> and it needs the users key already, so they need an LP account
[11:34] <LaserJock> Burgwork: darn, figures
[11:34] <unfo> Burgwork: it seems from my experimentation that it silently ignores unsigned mail from both registered and not-registered users?
[11:34] <unfo> Burgwork: is that true?
[11:34] <Burgwork> likely
[11:35] <unfo> Burgwork: :( i should file a bug.    It should always provide *some* response.  I wish Launchpad was fully open-source.
[11:35] <Burgwork> unfo: yes, yes, and yes
[11:36] <Burgwork> :)
[11:37] <unfo> Will all of launchpad really eventually be open-sourced, so I could, say, run a private copy of launchpad on my personal web server including malone, answers, and everything?
[11:37] <mdke> unfo: it used to send responses when mail was dropped, so you should file a bug
[11:38] <unfo> I've read the FAQ but I still don't understand if it will.
[11:38] <mdke> #launchpad is the better channel for launchpad discussion, though
[11:39] <mdke> I suspect the answer to your last question is that we don't know. Certainly it isn't ready to be run on various people's private servers at the moment
[11:39] <mdke> the intention, as you saw from the faq, is to make it open source
[11:40] <unfo> mdke: ah.
[11:40] <unfo> mdke: Burgwork: it seems it accepts unsigned comments by email from registered LP users, but it silently drops comment and new-bug emails from others.  I'll file a bug.
[11:40] <Burgwork> mdke: intention to make open source != actual timeline
[11:41] <mdke> Burgwork: I hope that I didn't suggest there was an actual timeline. it would surprise me if the devs have any idea about how to make it happen at the moment. Maybe they do though
[11:42] <Burgwork> mdke: I hope they do
[11:42] <mdke> I suspect they have been focused on 1.0 for a while now
[11:43] <mdke> without worrying about how to scale the concept to make it open-sourceable
[11:43] <mdke> but I think we should move channels
[11:46] <unfo> mdke: ok, moving to #launchpad.


[09:19] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2379 Pending binary packages
[09:36] -queuebot:#ubuntu-ci-eng- Mirv ahayzen, https://bileto.ubuntu.com/#/ticket/2360 Generating diffs
[09:39] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2379 Successfully built
[09:40] <popey> jibel: https://bileto.ubuntu.com/#/ticket/2416 calculator click needs testing please. :)
[10:01] <vigo> dbarth, ping
[10:18] <dbarth> vigo: pong
[10:18] -queuebot:#ubuntu-ci-eng- popey, https://bileto.ubuntu.com/#/ticket/2416 QA Signoff: Ready
[10:18] <vigo> dbarth, I flashed rc on krillin this morning
[10:19] <vigo> and after a while testing I started to notice some screen blinking when hiding/reveaking the OSK
[10:19] <vigo> in webbrowser
[10:19] <vigo> have you seen that?
[10:21] <sil2100> Mirv: uh oh! Just noticed an e-mail from Saturday about the xenial i386 touch builds failing
[10:21] <sil2100>  ubuntu-touch : Depends: ubuntu-sdk-libs but it is not going to be installed
[10:21] <sil2100>                 Depends: qtdeclarative5-qtlocation-plugin-gles but it is not going to be installed
[10:21] <sil2100> Some missing gles rebuild maybe?
[10:22] <dbarth> vigo: hmm no, sorry not testing it right now; oSoMoN, did you see that OSK issue ? ^^
[10:23] <oSoMoN> dbarth, vigo: no, I didn’t see that issue
[10:23] <oSoMoN> vigo, is it only in webbrowser-app?
[10:28] <vigo> oSoMoN, yes, it works fine in uss and messaging for example
[10:28] <oSoMoN> vigo, is it reliably reproducible if you close the browser and open it again?
[10:29] <vigo> oSoMoN, yes, it is
[10:30] <vigo> after closing and reopen it, keeps blinking
[10:30] <vigo> I'm rebooting now
[10:34] <vigo> oSoMoN, still happens after reboot
[10:35] <oSoMoN> vigo, are you seeing that on other devices? I’ll flash rc on my arale to test
[10:36] <vigo> oSoMoN, I'm flashing frieza to check it :)
[10:58] <oSoMoN> vigo, not seeing that on arale
[11:00] <vigo> oSoMoN, I can see it on frieza too
[11:01] -queuebot:#ubuntu-ci-eng- Mirv ahayzen mitya57, https://bileto.ubuntu.com/#/ticket/2360 Currently building (xenial/qtbase-opensource-src, zesty/qtbase-opensource-src). Failed to build (xenial/qtbase-opensource-src-gles). Successfully built (zesty/qtbase-opensource-src-gles)
[11:02] <vigo> oSoMoN, https://trello.com/c/7hKPC4mX/3938-webbrowser-app-oxide-ota15
[11:02] <vigo> that's how it looks on my krillin
[11:09] <rvr> oSoMoN: I can see that in krillin
[11:10] <rvr> Hide the OSK slowly and the blinking can be seen clearly
[11:11] <Mirv> sil2100: hey. I think it's probably that one non-matching version (~5 instead of ~4 because gles needed a rebuild). it'd be fixed in the next landing that's now built, but I'll prepare just a version fix now.
[11:27] -queuebot:#ubuntu-ci-eng- bzoltan, https://bileto.ubuntu.com/#/ticket/2418 Preparing packages
[11:29] -queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2415 Preparing packages
[11:35] <oSoMoN> vigo, rvr: sorry I had misunderstood the issue, I thought it was the OSK that was blinking
[11:35] <oSoMoN> indeed I can see that on arale too
[11:37] <oSoMoN> I’m seeing that on rc-proposed too
[11:38] <vigo> oSoMoN, ack
[11:38] <oSoMoN> re-flashing stable just to be sure it’s an actual regression
[11:40] <rvr> oSoMoN: I also misunderstood the issue :D
[11:47] <oSoMoN> vigo, I’m seeing the same issue on stable
[11:54] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2414 Pending binary packages
[11:59] <oSoMoN> vigo, https://bugs.launchpad.net/oxide/+bug/1660311
[12:00] <oSoMoN> vigo, can you confirm you’re seeing it too on stable?
[12:00] <vigo> rvr, ^
[12:01] <vigo> did you notice?
[12:01] <vigo> oSoMoN, let me flash krillin
[12:01] <vigo> :)
[12:02] -queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2419 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
[12:15] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2414 Successfully built
[12:20] -queuebot:#ubuntu-ci-eng- bzoltan, https://bileto.ubuntu.com/#/ticket/2418 Successfully built
[12:21] <vigo> oSoMoN, confirmed on stable with krillin
[12:22] -queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2415 Successfully built
[12:29] <oSoMoN> vigo, good, so at least it’s not a regression
[12:30] <vigo> oSoMoN, yep
[12:33] -queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2420 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
[12:42] -queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2140 Needs rebuild due to higher version at destination (xenial/qtmir, xenial/qtmir-gles, xenial/ubuntu-system-settings, zesty/qtmir, zesty/qtmir-gles). Needs rebuild due to new commits (zesty/ubuntu-system-settings)
[13:05] <jgdx> camako, ping
[13:05] <camako> jgdx, pong
[13:06] <jgdx> camako, with silo 2369 installed I get a compiler failure in code using ual: http://pastebin.ubuntu.com/23893488/
[13:06] <jgdx> i'm not sure what I'm looking at, can you help?
[13:07] <camako> compiler failure?
[13:07]  * camako looks
[13:07] -queuebot:#ubuntu-ci-eng- renatofilho tiagosh boiko, https://bileto.ubuntu.com/#/ticket/2318 Preparing packages
[13:07] <jgdx> compilation failure :)
[13:07] -queuebot:#ubuntu-ci-eng- renatofilho tiagosh boiko, https://bileto.ubuntu.com/#/ticket/2318 Too many merge targets: lp:history-service, lp:history-service/staging
[13:09] <camako> jgdx, this header got moved, do you have "include/core" in your include path?
[13:10] <jgdx> camako, probably not, I'll make sure it's there. Thx
[13:12] <camako> jgdx, although it was already moved in 0.25. Perhaps you haven't built it for a while?
[13:12] <jgdx> camako, against 0.24 last time I built
[13:13] <camako> jgdx, ok makes sense.... Let me know if you see other failures.
[13:15] -queuebot:#ubuntu-ci-eng- renatofilho tiagosh boiko, https://bileto.ubuntu.com/#/ticket/2318 Preparing packages
[13:21] -queuebot:#ubuntu-ci-eng- Mirv ahayzen mitya57, https://bileto.ubuntu.com/#/ticket/2360 Successfully built
[13:42] -queuebot:#ubuntu-ci-eng- renatofilho tiagosh boiko, https://bileto.ubuntu.com/#/ticket/2318 Failed to build (xenial/history-service, zesty/history-service). Successfully built (xenial/empathy, xenial/telephony-service, zesty/empathy, zesty/telephony-service)
[13:47] <jgdx> camako, hey, so not a failure, but am I right to assume that 0.26 introduces scaling only in the non-deprecated API?
[13:47] <camako> jgdx, you mean mir_output_set_scaling() specifically?
[13:47] <jgdx> camako, yes
[13:48] <camako> yes, it's available to use
[13:48] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2421 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
[13:48] <jgdx> … but not from mir_connection_create_display_config
[13:49] <camako> jgdx, yeah that's been deprecated... you can use : mir_connection_create_display_configuration()
[13:50] <jgdx> camako, yup. Thanks
[13:50] <camako> yw
[14:22] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2421 Diff missing
[14:39] -queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2419 Diff missing (xenial/qtbase-opensource-src). Ready to build (xenial/qtbase-opensource-src-gles)
[14:44] -queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2415 Needs rebuild due to new commits (zesty/unity8). Successfully built (xenial/unity8)
[14:44] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2421 Generating diffs
[14:45] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2421 Successfully built
[14:52] -queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2415 Preparing packages
[14:55] -queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2415 zesty/unity8: Failed to merge https://code.launchpad.net/~aacid/unity8/doubleClickMaximize
[15:15] -queuebot:#ubuntu-ci-eng- tiagosh bfiller boiko, https://bileto.ubuntu.com/#/ticket/2311 Preparing packages
[15:25] -queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2415 Preparing packages
[15:31] -queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2415 zesty/unity8: Failed to merge https://code.launchpad.net/~aacid/unity8/clickOpenMenuClosesIt
[15:57] -queuebot:#ubuntu-ci-eng- tiagosh bfiller boiko, https://bileto.ubuntu.com/#/ticket/2311 Needs rebuild due to new commits (zesty/messaging-framework, zesty/mfw-plugin-irc). Successfully built (xenial/address-book-app, xenial/libircclient, xenial/messaging-app, xenial/messaging-framework, xenial/mfw-plugin-irc, zesty/address-book-app, zesty/libircclient, zesty/messaging-app)
[16:03] -queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2415 Needs rebuild due to new commits (zesty/unity8). Successfully built (xenial/unity8)
[16:05] -queuebot:#ubuntu-ci-eng- mterry dobey, https://bileto.ubuntu.com/#/ticket/2404 Preparing packages
[16:14] -queuebot:#ubuntu-ci-eng- renatofilho tiagosh boiko, https://bileto.ubuntu.com/#/ticket/2318 Preparing packages
[16:14] <boiko> trainguards: could you please remove history-service packages from silo 2283's ppa?
[16:20] <robru> boiko: done
[16:21] <boiko> robru: thanks
[16:21] <robru> boiko: yw
[16:42] -queuebot:#ubuntu-ci-eng- renatofilho tiagosh boiko, https://bileto.ubuntu.com/#/ticket/2318 Failed to build (xenial/history-service). Successfully built (xenial/empathy, xenial/telephony-service, zesty/empathy, zesty/history-service, zesty/telephony-service)
[17:06] -queuebot:#ubuntu-ci-eng- mterry dobey, https://bileto.ubuntu.com/#/ticket/2404 Successfully built
[17:12] -queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2415 Preparing packages
[17:16] -queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2415 zesty/unity8: Failed to merge https://code.launchpad.net/~aacid/unity8/doubleClickMaximize
[17:45] -queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2415 Needs rebuild due to new commits (zesty/unity8). Successfully built (xenial/unity8)
[17:47] -queuebot:#ubuntu-ci-eng- kenvandine ahayzen, https://bileto.ubuntu.com/#/ticket/2236 Preparing packages
[18:18] -queuebot:#ubuntu-ci-eng- kenvandine ahayzen, https://bileto.ubuntu.com/#/ticket/2236 Dependency wait (zesty/qtubuntu-print). Failed to build (xenial/content-hub, xenial/ubuntu-printing-app, zesty/ubuntu-printing-app). Needs rebuild due to higher version at destination (xenial/qtbase-opensource-src). Ready to build (xenial/qtbase-opensource-src-gles, zesty/qtbase-opensource-src, zesty/qtbase-opensource-src-gles). Successfully built (xenial/qtubuntu-print, xenial/ubuntu
[18:22] -queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2415 Preparing packages
[18:26] -queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2415 zesty/unity8: Failed to merge https://code.launchpad.net/~aacid/unity8/doubleClickMaximize
[18:30] -queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2415 Preparing packages
[18:33] -queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2415 zesty/unity8: Failed to branch https://code.launchpad.net/~aacid/unity8/closeMenusOnClick
[19:04] -queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2415 Needs rebuild due to new commits (zesty/unity8). Successfully built (xenial/unity8)
[19:12] -queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/2105 Preparing packages
[19:29] -queuebot:#ubuntu-ci-eng- tiagosh bfiller boiko, https://bileto.ubuntu.com/#/ticket/2311 Preparing packages
[19:48] -queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/2105 Pending binary packages
[19:57] -queuebot:#ubuntu-ci-eng- tiagosh bfiller boiko, https://bileto.ubuntu.com/#/ticket/2311 Needs rebuild due to new commits (zesty/messaging-app, zesty/messaging-framework, zesty/mfw-plugin-irc). Pending binary packages (xenial/messaging-app). Successfully built (xenial/address-book-app, xenial/libircclient, xenial/messaging-framework, xenial/mfw-plugin-irc, zesty/address-book-app, zesty/libircclient)
[20:04] -queuebot:#ubuntu-ci-eng- tiagosh bfiller boiko, https://bileto.ubuntu.com/#/ticket/2311 Preparing packages
[20:08] -queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/2105 Pending binary packages (zesty/ubuntu-app-launch). Successfully built (xenial/ubuntu-app-launch)
[20:28] -queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/2105 Successfully built
[20:37] -queuebot:#ubuntu-ci-eng- tiagosh bfiller boiko, https://bileto.ubuntu.com/#/ticket/2311 Needs rebuild due to new commits (zesty/messaging-framework, zesty/mfw-plugin-irc). Pending binary packages (xenial/messaging-app). Successfully built (xenial/address-book-app, xenial/libircclient, xenial/messaging-framework, xenial/mfw-plugin-irc, zesty/address-book-app, zesty/libircclient, zesty/messaging-app)
[20:57] -queuebot:#ubuntu-ci-eng- tiagosh bfiller boiko, https://bileto.ubuntu.com/#/ticket/2311 Needs rebuild due to new commits (zesty/messaging-framework, zesty/mfw-plugin-irc). Successfully built (xenial/address-book-app, xenial/libircclient, xenial/messaging-app, xenial/messaging-framework, xenial/mfw-plugin-irc, zesty/address-book-app, zesty/libircclient, zesty/messaging-app)
[21:00] -queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2415 Preparing packages
[21:07] -queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/2105 Needs rebuild due to new commits (zesty/ubuntu-app-launch). Successfully built (xenial/ubuntu-app-launch)
[21:08] -queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/2105 Preparing packages
[21:08] -queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2415 zesty/unity8: Failed to merge https://code.launchpad.net/~aacid/unity8/eatHoverWhenLauncherMenuIsOpen
[21:17] -queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2415 Preparing packages
[22:08] -queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/2105 Successfully built
[22:25] -queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2415 Pending binary packages (xenial/unity8). Successfully built (zesty/unity8)
[22:44] -queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2415 Successfully built
[22:59] <jgrimm> trainguards, I'm desiring  'required permission to operate bileto'
[23:54] <robru> jgrimm: hey, sorry for the delay
[23:55] <robru> jgrimm: please read https://wiki.ubuntu.com/Bileto
[23:57] <robru> jgrimm: I've added you, if you're logged in to bileto already then you need to log out and back in to gain the permissions
[23:57] <robru> jgrimm: feel free to ask me if you have any questions, I'm around for an hour then i pop out again


[01:10] <FPSDavid> yo
[01:11] <FPSDavid> Is it a common issue for opening up the Guide to freeze the entire frontend?
[01:13] <laga> http://www.launchpad.net/bugs/229949
[01:13] <laga> maybe you're affected by that bug, but it shouldn't freeze completely
[01:39] <FPSDavid> well, liveTV keeps going (i can hear the audio and see the preview box) but i cant get out of the guide once i open it
[01:39] <FPSDavid> that looks like the problem
[01:39] <FPSDavid> i just updated everything last night though, not fixed
[02:29] <Anusien> So I enabled the VNC service but it doesn't seem to be running now (not in the services list, can't VNC in).  Is there a package that allows me to log in on the same xsession that's on the desktop?
[02:30] <tgm4883_laptop> Anusien, VNC
[02:30] <tgm4883_laptop> but IIRC, you have to restart gdm
[02:30] <Anusien> I had it working earlier when it was on the default xfce install
[02:31] <Anusien> You mean restart gdm and then run vncserver or run vncserver then run gdm?
[02:31] <tgm4883_laptop> restart gdm, the vncserver should start when gdm starts
[02:37] <Anusien> ah
[02:37] <Anusien> how can I verify?  I don't see vncserver in the services list for one thing
[02:37] <tgm4883_laptop> you could VNC into the machine
[02:39] <tgm4883_laptop> "ps aux" should work too
[02:43] <Anusien> I meant more that that will work :P
[02:43] <Anusien> just start a new x session to restart gdm?
[02:45] <tgm4883_laptop> you could "sudo /etc/init.d/gdm restart"
[02:45] <Anusien> Thanks for all your help.  Will give that a shot
[02:46] <Anusien> err, why gdm?  I really should have asked before typing that
[02:46] <tgm4883_laptop> it's a trade secret
[02:46] <tgm4883_laptop> I could tell you, but then I would have to kill you
[02:47] <Anusien> :P "Not loading gnome display manager, it's not the default windows manager"
[02:53] <Anusien> yeah, rebooted the whole machine and still no VNC
[03:28] <Anusien> Turns out the answer is to run x11vnc manually for some reason
[18:32] <gregL> laga: I seen in the log of mythtv-users you were asking who the guy was that wanted the trunk build.. That would be me...
[18:36] <laga> cool :)
[18:36] <laga> sorry, but i forgot your name and was too lazy to look in the logs ;)
[18:37] <laga> well, trunk is built now
[18:37] <laga> mythplugins is missing, but i'll fix that tonight
[18:38] <gregL> ok, Thanks...I get lazy sometimes myself....Thanks for doing this...
[18:39] <gregL> I have a fresh hard drive with a fresh install just waiting..I just need to put it in the box..
[18:41] <laga> nice :)
[18:41] <laga> trunk is still too scary for me
[18:41] <laga> although i'd love to try the h264 improvements
[18:41] <laga> (possibly needs janne's updated ffmpeg merge patch)
[18:46] <gregL> Yeah,I have an hard drive swap system here..I can change a hard drive in a few minutes...So if i mess it up it's no big deal...There is quite a few guys in #hdpvr that i hope can point me in the right direction if i have a problem...
[18:47] <gregL> I will wait till the plugins are done, then i will give it a go...
[18:57] <brewmaster> anyone have trouble downloading a movie video's plot into mythtv?  the changed mentioned here http://ubuntuforums.org/showthread.php?t=878634 makes sense, but didn't work...
[18:58] <laga> gregL: i've uploaded a (supposedly) fixed mythplugins build. it'll take a while to build
[19:02] <gregL> laga:Thanks for the effort..
[19:27] <laga> gregL: humpf, i need to upload another build.
[19:32] <gregL> laga: no problem..I am doing a fresh install of mythtv....I really wish i could do this stuff myself...For some reason i have a tough time compiling....More than likely because i can't get the configure right.
[19:33] <laga> looks like i'm having a hard time, too ;)
[22:11] <thedarkon> has anyone have a problem with nvidia and opengl going black screen?
[22:12] <Tuv0k> nope
[22:12] <thedarkon> do u use opengl?
[22:12] <Tuv0k> I use the beta nvidia drivers, lol, of course
[22:13] <Tuv0k> ppl actually opt out of opengl?
[22:13] <thedarkon> well will they work on mythbuntu
[22:13] <Tuv0k> never said they did not
[22:14] <thedarkon> i use opengl
[22:14] <thedarkon> and using 173.1.14
[23:51] <imat007> I am running Ubuntu 8.04 and I compiled mythtv v21 from source, it works except, I have to manually start backend.  I have 2 users, mythtv and my main login.  I am unable to log in to mysql when I use mythtv user, but if I switch to my main login I can do so.  Does any one know if I might have missed some permission to grant to user mythtv?
[23:54] <laga> imat007: try #mythtv-users
[23:54] <laga> imat007: this channel is mostly for people who are running the packages
[23:54] <imat007> it is not listed in the IRC channels ..
[23:55] <laga>  type
[23:56] <laga>  /join #mythtv-users
[23:56] <imat007> join #mythtv-users
[23:56] <imat007> I entered that but it echoes back my command, I don't see #mythtv-users when I type /LIST
[23:57] <imat007> I will try the mysql channel if it exists ..
[23:58] <imat007> thx for help
[23:58] <tgm4883_laptop> did you try
[23:58] <tgm4883_laptop>  /join #mythtv-users
[23:58] <tgm4883_laptop> as in with the /
[23:59] <imat007> I see my mistake, thx a lot , I can now see the channel ..