[00:07] <cnd> bregma, I've got a pristine checkout of lp:utouch-geis here
[00:07] <cnd> make check is failing for GeisSubscriptionTests.duplicate_window_subscription
[00:07] <cnd> gtest_subscriptions.cpp:91: Failure
[00:07] <cnd> Expected: (GEIS_STATUS_SUCCESS) != (geis_subscription_activate(sub2)), actual: 0 vs 0
[00:07] <cnd> mistakenly activated subscription 2
[00:08] <cnd> we'll need to get that fixed before releasing anything
[00:21] <bregma> so how does your utouch stack differ from my utouch stack (I've had a few pristine checkouts since that test went in and it continues to pass on every rebuild)
[00:25] <cnd> hmm
[00:25] <cnd> I don't know
[00:25] <cnd> I'll have to investigate
[00:25] <cnd> in the meantime, I'm finding a geis bug where the number of touches in a geis gesture is not being set properly
[00:25] <cnd> I'm tracking it down
[00:25] <cnd> well, I think it's a geis bug :)
[01:30] <cnd> oh right, it's a grail bug that I wrote a fix for but hadn't gotten around to writing a testcase for
[01:31] <bregma> is there a bug for it?
[01:37] <cnd> not yet, though I think it's a separate issue again
[15:16]  * bregma stands up, looking around.....
[15:17] <tvoss> Working on #950974, deployed BuildService server to staging jenkins, updated documentation on builder setup
[15:17]  * tvoss stands up as well
[15:17] <cnd> I'm working on a utouch bugs that are resulting in issues in unity
[15:17] <tvoss> cnd, dandrader, ping
[15:18] <dandrader> tvoss, pong
[15:18] <cnd> I may have a fix for bug 940308
[15:18] <dandrader> I'm working on making that 3-touches gesture to move windows around work again (in unity code)
[15:19] <tvoss> dandrader, just ping'd for standup :)
[15:19] <cnd> tvoss, does the merge proposal script work now?
[15:20] <tvoss> yeah, I'm preparing a follow-up mail on the call for testing and send out instructions
[15:20] <cnd> cool
[15:20] <tvoss> you do not need to interact with script any more
[15:20] <dandrader> tvoss, a web ui now?
[15:20] <tvoss> dandrader, yeah, a very simple one, but a web ui ;)
[15:21] <dandrader> cool
[15:21] <tvoss> or curl, if you like that better
[15:21] <bregma> I'm beating my pulpy head against the wall trying to figure out why the basic compile checks segfault when utouch-geis is buitl in a PPA (and not in a pbuilder)
[15:21] <dandrader> i've now problems with a web ui
[15:21] <dandrader> s/now/no
[15:23] <tvoss> bregma, is it always failing or only on some builds?
[15:23] <bregma> always fails, only in PPA
[15:41] <tvoss> bregma, I remember a thread on some mailing-list about "corrupt" ppa builders
[15:41] <tvoss> bregma, for that I asked
[15:48] <bregma> I don;t think that's the problem here, more liekely something to do with PPA kernels disallowing pipes to be opened from built apps or something
[15:49] <bregma> I beleive I can force a stacktrace but the build backlog is on the order of hours, so turnaround is slow
[15:49] <bregma> it feels like software development in the 1980s again
[15:59]  * tvoss sighs
[17:41] <cnd> bregma, got an issue with geis that we can resolve in a couple ways
[17:41] <cnd> when a "system" geis v1 tap subscription is created
[17:41] <cnd> the min touches is set to 1 instead of matching the start touches
[17:42] <cnd> what ends up happening is a tap gesture is recognized by grail, but it continues to send events all the way down to when only 1 touch is left on the device
[17:42] <cnd> so if you do a two-touch tap you might get from grail:
[17:42] <cnd> gesture begin: 1 touch, no gesture
[17:43] <cnd> gesture update: 2 touches, no gesture
[17:43] <cnd> gesture update: 1 touch, no gesture
[17:43] <cnd> gesture end: 1 touch, tap recognized
[17:43] <cnd> because geis v1 does not allow for tentative events, we transform that into one geis v1 event:
[17:44] <cnd> geis gesture update: 1 touch, tap recognized
[17:44] <cnd> when it should have been:
[17:44] <cnd> geis gesture update: 2 touch, tap recognized
[17:44] <cnd> I'm thinking the best way to resolve this is to only set minimum touches to 1 for non-tap system gestures
[17:45] <cnd> what do you think?
[17:45] <bregma> did it not give the 2-tap gesture event?
[17:46] <cnd> grail is giving a "gesture", which in the end slice is a 1-touch tap
[17:46] <cnd> but in the middle of the gesture there was a slice with 2-touches
[17:46] <cnd> but only the end slice is transformed into the geis v1 gesture event
[17:46] <cnd> which is why it says only 1 touch
[17:47] <bregma> I mean the original grail, you;re saying it never gave the 2-tap gesture?
[17:47] <cnd> the original grail probably did not honor the system flag for tap events
[17:47] <bregma> mmm
[17:48] <cnd> an alternative would be to keep the max touch count of a gesture in the geis gesture state
[17:48] <cnd> and when emitting a tap gesture, emit it with the max number of touches
[17:48] <cnd> but then we have to keep around more state, such as each touch position
[17:49] <cnd> I think that would be a hairy solution
[17:49] <bregma> that would effectively be moving gesture recognition out of the recognizer and into geis
[17:49] <cnd> yeah
[17:50] <bregma> a tap event is already a special case, what with not haveing a begin and an end
[17:50] <bregma> I see nothing wrong with treating it special in other ways
[17:50] <cnd> bregma, is not setting the min touches to 1 for a system tap gesture alright with you?
[17:51] <cnd> I can whip up a patch for it fairly quickly I think
[17:51] <bregma> yes, I'm fine wit hthat
[17:51] <cnd> ok
[17:52] <bregma> ... it looks like the build failures I see in the PPA are _bash_ segfaulting, not the test program
[17:52] <bregma> curiouser and curiouser
[17:53] <cnd> bregma, it looks like bash segfaults when the program executed at make check segfaults
[17:53] <cnd> that's been my experience
[17:53] <cnd> bregma, do you have the build log url?
[17:53] <cnd> I can see if it matches what I've seen before
[17:54] <bregma> https://launchpadlibrarian.net/96910377/buildlog_ubuntu-precise-i386.utouch-geis_2.2.6%2Br217%2Bp159~ppa2_FAILEDTOBUILD.txt.gz
[17:54] <bregma> in this run, I run the test program in valgrind to catch and display a traceback of the segfault
[17:54] <cnd> ahh
[17:55] <cnd> yeah, this is the test segfaulting
[17:55] <cnd> not bash
[17:55] <bregma> bash still appears to segfault
[17:55] <bregma> you mean, the test segfaults and valgrin is not catching it?
[17:55] <cnd> bregma, are you referring to this line: /bin/bash: line 5: 30068 Segmentation fault      valgrind ${dir}$tst
[17:55] <cnd> ?
[17:55] <bregma> yep
[17:55] <cnd> yeah, I've seen that exact message before
[17:56] <cnd> it's not bash segfaulting, it's valgrind
[17:56] <cnd> I thought the same thing when I first saw it
[17:57] <cnd> and RAOF told me what's really going on :)
[17:57] <cnd> I have no idea why those tests would segfault though...
[17:57] <bregma> I have always assumed it's the app segfaulting, but it makes no sense valgrind would be degfaulting here
[17:58] <cnd> bregma, maybe remove valgrind and add a signal handler to the testcases to get a backtrace?
[17:58] <cnd> it's a pretty heavy-handed approach, but it might work
[17:58] <bregma> I added valgrind to get the backtrace -- valgrind will give a backtrace if the app it's running segfaults
[17:58] <bregma> without valgrind you get the same message, except without the valgrind
[17:59] <cnd> hmm
[17:59] <bregma> as you can see, valgrind is not catching any errors with the app
[17:59] <cnd> what if it's segfaulting at program exit/cleanup time?
[17:59] <bregma> the package builds cleanly using sbuild and pbuilder on my machine
[18:00] <cnd> maybe the code would be run at valgrind exit/cleanup time too
[18:00] <cnd> which would be why it appears that valgrind finishes running the test
[18:01] <bregma> so what's in the PPA that selective segfaults any program run in several nested bash shells (like the automake CHECK targets here) that does not occur without the nested shells and does not occur in an sbuild elsewhere?
[18:01] <bregma> it has to be something ni the buildd's custom sbuild environment
[18:02] <cnd> bugs could be dormant on some systems and not others
[18:02] <cnd> I don't know we can be sure that the environment is different in a systematic way
[18:03] <bregma> well, it's the same up-to-date precise distro, it's both x86 and amd64 architectures, and it consistently fails in various PPAs and consistently passes in clean sbuild and pbuilder images
[18:04] <bregma> it wouldn't be so bad except for the build delays in PPAs
[18:05] <cnd> yeah
[18:06] <cnd> bregma, maybe add geis_delete() and see if it fixes things?
[18:07] <cnd> bregma, I assume your valgrind run would output any stack or heap corruption?
[18:08] <bregma> valgrind has always been useful to find errors like that, it's kinda the point
[18:09] <bregma> I will crank up the volume of valgrin messages and see what obtains
[18:11] <cnd> yeah, I just wanted to make sure you weren't somehow disabling that
[18:45] <dandrader> cnd, in Geis, what's the difference between the centroid and the position of a gesture?
[18:45] <cnd> dandrader, there isn't, it's a bit of a snafu
[18:45] <cnd> IIRC
[18:46] <cnd> there was a big issue of how to handle two ways of defining gesture motion
[18:46] <cnd> centroid + full affine transformation
[18:46] <cnd> or center of rotation + rotation + multiplication
[18:47] <cnd> in the mix of the discussion, we added a centroid parameter, but it should be the same as the position parameter
[18:47] <cnd> we needed to add a center of rotation parameter instead
[18:47] <cnd> which we never did...
[18:48] <cnd> no one has asked for it, so...
[18:48] <dandrader> :)
[18:48] <dandrader> ok, thanks for explanation
[18:50]  * bregma slaps forehead with dead fish and mumbles something unintelligible about libtool
[18:52] <cnd> bregma, did you figure it out?
[19:06] <cnd> bregma, wow, geisv1 has a badly broken api :(
[19:06] <cnd> the xcb window info takes a uint32_t window id
[19:06] <cnd> but X Window is typedef'd to a long
[19:07] <cnd> so on 64-bit, the geis v1 window id only holds the lower 32-bits
[19:07] <cnd> it probably won't matter too much, but it's quite an oversight
[19:08] <burli> hi
[19:08] <cnd> burli, hi
[19:09] <burli> hi cnd. The guy I want to see ;)
[19:09] <cnd> :)
[19:09] <burli> Currently I'm trying Kubuntu-Active.
[19:09] <burli> Same problems like with Unity-3D
[19:09] <burli> add a comment to the bug report https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/949791
[19:10] <cnd> burli, I've seen a few reports about it
[19:10] <cnd> I can't seem to reproduce it here
[19:10] <cnd> but I may have a commit that would fix it
[19:11] <cnd> burli, are you capable of compiling a branch of utouch-grail to see if it's fixed?
[19:12] <burli> cnd, I can try
[19:12] <cnd> burli, to make sure you have all the dependencies you need, run "apt-get build-dep utouch-grail"
[19:13] <burli> just a second
[19:14] <cnd> then, check out the branch: bzr branch lp:~chasedouglas/utouch-grail/tap-accept-v2
[19:14] <cnd> cd into it
[19:14] <cnd> run: ./autogen.sh && ./configure --prefix=/usr --libdir=/usr/lib/x86_64-linux-gnu --with-xi
[19:14] <cnd> make
[19:14] <cnd> sudo make install
[19:15] <cnd> log out and back into unity 3d and see if it fixes things
[19:15] <burli> hang on. let me first install all updates
[19:17] <cnd> ok
[19:17] <cnd> I've got all day, so don't worry about time :)
[19:20] <burli> need to install bzr first ;)
[19:23] <cnd> heh
[19:24] <burli> cnd, x86_64?
[19:24] <cnd> burli, are you on i386?
[19:24] <burli> shure
[19:24] <cnd> ok
[19:24] <cnd> use --libdir=/usr/lib/i386-linux-gnu
[19:25] <burli> ok
[19:26] <burli> cnd, 64 Bit on an Atom CPU with 1GB RAM is not a good idea ;)
[19:27] <cnd> suit yourself :)
[19:27] <burli> ok, compiling
[19:27] <burli> ok, no errors
[19:28] <cnd> good :)
[19:28] <burli> well, lets see
[19:29] <burli> no, sorry. nothing changed
[19:29] <burli> let me reboot
[19:31] <burli> hm, strange. let me test something
[19:38] <burli> cnd, ok. Same problem. I can do something for a few seconds.
[19:39] <cnd> burli, ok
[19:39] <cnd> burli, I need you to try to figure out the simplest way to always trigger the bug
[19:39] <burli> for example move the hover icon from onboard or drag a select box on the desktop
[19:39] <cnd> that may be tapping over one window
[19:40] <cnd> burli, dragging a select box once will trigger the bug?
[19:40] <burli> let me try again something
[19:41] <cnd> k
[19:42] <burli> it's confusing
[19:49] <burli> ok. first, I can't use the panel all the time, doesn't matter what I do. Not even F10 works.
[19:49] <burli> wait, got a bug
[19:50] <burli> Its the second time that nautilus crashed
[19:51] <burli> nautilus crashed with SIGABRT in raise()
[19:51] <dandrader> cnd, got the 3-finger drag working again! (with hit test method)
[19:51] <cnd> dandrader, sweet!
[19:52] <cnd> I'll be able to test it on my touchscreen here too
[19:52] <cnd> dandrader, did you get rid of the XQueryTree call too?
[19:52] <burli> ok, next: I can open the launcher with the Super key directly after login and drag the launcher icons for a few seconds.
[19:53] <dandrader> cnd, yes
[19:54] <cnd> dandrader, \o/
[19:55] <dandrader> :)
[19:55] <cnd> burli, do you mean you drag one launcher icon to reorder it in the dock?
[19:55] <cnd> and then your touch is broken?
[19:56] <burli> cnd, not reorder. just scroll all icons up and down
[19:56] <cnd> ok
[19:56] <burli> I copied a file to my desktop folder and relogin
[19:56] <burli> I can drag this file twice, than touch is broken
[19:57] <burli> let me try something different
[19:57] <cnd> burli, I worry that this may be exacerbated by the slowness of your system
[19:57] <cnd> but I'll try those
[19:58] <cnd> my unity 3d touch screen system is a quad core i7
[20:00] <burli> cnd, I try to drag the file for a longer time. than I dropped it and drag it again for a while. Works fine so far. If I try to drag it again it doesn't work
[20:01] <burli> ok, now I can drag it only once
[20:02] <cnd> burli, btw, I'm tracking this issue in bug 949791: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/949791
[20:02] <burli> this is my report ^^
[20:03] <cnd> ahh, ok
[20:03] <cnd> right
[20:03] <cnd> I was thinking of another bug
[20:04] <burli> are you shure this is a performance issue? Unity-3D runs fine on my netbook
[20:04] <cnd> I think I started commenting on the other bug instead of your bug by mistake
[20:04] <cnd> burli, it's not that unity 3d shouldn't be able to run on your machine
[20:05] <cnd> just that the bug may only manifest on a slower machine
[20:05] <cnd> which would explain why I haven't seen the bug yet
[20:05] <burli> ah, ok
[20:05] <burli> If you are in germany I can send you my tablet for testing ;)
[20:06] <burli> cnd, where do you live?
[20:08] <cnd> burli, portland, OR
[20:08] <cnd> US
[20:08] <burli> ouch. thats to complicated
[20:09] <cnd> burli, I'm sure we'll be able to fix it
[20:09] <cnd> I am working on all the bugs I can find involving utouch
[20:10] <burli> I'm wondering that nautilus crashed twice
[20:10] <burli> did not crash on unty 2d
[20:10] <burli> unity
[20:11] <cnd> ooo... it's already 1:12
[20:11] <cnd> I need to get some lunch
[20:11] <cnd> biab
[20:12] <burli> hehe
[21:06] <cnd> bregma, when you ran the tests under valgrind, did you run valgrind ./test?
[21:07] <cnd> if so, that won't work since ./<progname> is a script to run the progname under .libs
[21:07] <cnd> maybe that's what you meant when you cursed at libtool earlier?
[21:09] <bregma> yeppurs
[21:10] <bregma> valgrind needs --follow-children or something like that
[21:10] <bregma> or else libtool execute valgrind, but that would miss the shell
[21:10] <bregma> looks like the problem is that the kernel used in the PPA does not support epoll
[21:11] <cnd> interesting...
[21:11] <bregma> in an unpleasant sort of way
[21:11] <cnd> bregma, does that break all geis tests?
[21:11] <cnd> or is there a workaround for when epoll isn't available?
[21:12] <bregma> it will break geis
[21:12] <bregma> I have another build pending that will reveal more details of why epoll_create() is failing
[21:12] <cnd> ok
[21:12] <cnd> I guess we might have to disable tests when building in the archive
[21:13] <cnd> do  you think it's ppa only?
[21:14] <bregma> I believe PPAs use the exact same buildd used by the distro
[21:14] <cnd> generally they don't
[21:14] <cnd> it's a separate system
[21:14] <bregma> are you sure/
[21:15] <cnd> I don't know all the details, but I think the setups are very different in implementation
[21:15] <cnd> whether that makes a difference in the build environment, I don't know
[21:15] <cnd> when I asked for arm builders for some dx-touch ppas
[21:15] <cnd> they seemed to need to flip a switch to make them build on a different set of buildds
[21:16] <cnd> I remember something about virtual builders vs regular builders
[21:16] <bregma> do you know weher to ask for more information on all this stuff?
[21:16] <bregma> *shere*
[21:16] <cnd> I think #soyuz
[21:16] <bregma> hot spit, I mean _where_
[21:16] <cnd> nope
[21:17] <cnd> soyuz is the project
[21:17] <cnd> I think #launchpad is the irc channel
[21:49] <dandrader> cnd, you can try this one lp:~dandrader/unity/geisv2/
[21:49] <dandrader> it has the 3-touches drag fix
[21:49] <cnd> dandrader, I will in a bit
[21:49] <cnd> I'm knee deep fixing other issues
[21:49] <dandrader> 4-touches drag and 4-touches tap behave way better as well
[21:50] <cnd> I'm currently fixing timeout calculation now that atomic gestures must wait for the composition time :)
[21:50] <cnd> sweet
[21:50] <cnd> hopefully with some stuff I'm working on they will be perfect
[21:50] <dandrader> I bet it must be because of the kinds of subscriptions done
[21:50] <cnd> I have around 3 fixes I'm currently working on
[21:51] <dandrader> cool
[21:52] <dandrader> hopefully it fixes the craziness I get when I just apply the 3-touches fix on top of unity trunk (without all the geisv1 -> geisv2 refactoring)
[21:53] <cnd> one of the particular bugs I'm working on is geisv1 only
[21:53] <cnd> so it might
[21:53] <cnd> the number of touches in a tap gesture are reported incorrectly in geisv1 right now
[21:54] <bregma> I was thinking we might want to spin a grail release early next week
[21:55] <cnd> bregma, yeah, after a couple fixes I have in the queue
[21:55] <cnd> the next freeze is next thursday anyways
[21:55] <cnd> so we need to get stuff out by then
[21:56] <bregma> if you all could all the fixes you want in to the next milestone, we'll know when we're ready because they're all committed
[21:58] <cnd> yeah, I should do that
[21:58] <cnd> the problem is that I'm trying to solve one bug, and I'm already up to 3 necessary fixes
[21:58] <cnd> and I think I need to fix a fourth
[21:59] <cnd> 2 in geis, 2 in grail
[22:15] <cnd> bregma, have you filed the FFe for the geis accept/reject?
[22:31] <bregma> not until I have it building in a PPA
[22:32] <bregma> PPAs run kernel 2.6.24, I need 2.6.27 but I think I can maybe fall back to an older epoll_create() if the first try fails
[22:33] <bregma> either way the code path for handling epoll_create() failure needs fixing
[22:33] <cnd> bregma, we need to file the FFe today
[22:33] <cnd> I think they've started approving FFes at the release team meeting on friday mornings
[22:33] <cnd> is that going to be possible?
[22:34] <bregma> OK, I don't need the build working to file the FFe, especially now I know why it was failing
[22:35] <cnd> k
[23:01] <cnd> bregma, a tap event in geis v1 should come across as one update event
[23:01] <cnd> no begin or end events
[23:01] <cnd> right?
[23:17] <bregma> "should" is a strong word:  yes, that's the way it did come across


[11:18] <head_victim> Tonight's rsync of the mirror is taking a while, funny how a release does that


[00:02] <jelmer> mgrandi: relative to the working tree rather than os.getcwd() I think
[00:02] <mgrandi> there is a comment in the code saying its "interpreted relative to the process cwd, not relative to the tree"
[00:02] <mgrandi> but even then, i'm giving it the correct relative url, but its stuck saying that the directory the script is running in is not a child of the tree
[00:03] <mgrandi> i have to os.chdir() to the tree and then just smart_add(".") to get it to work =/
[01:37] <Peng> smart indeed
[03:26] <SamB> is http://anonscm.debian.org/bzr/users/naesten-guest/pkg-create-dbgsym a terrible choice for my branch of lp:ubuntu/pkg-create-dbgsym ?


[00:41] <bdmurray> james_w: that person really did have a package for me
[00:42] <james_w> wow
[12:28] <thekorn> hmm, is wiki.ubuntu.com slow/down for anybody else, or is it just me?
[12:29] <jpds> thekorn: Fails with a Squid error here.
[12:30] <thekorn> right, same here
[12:33] <jpds> thekorn: Might want to tell #canonical-sysadmin - but I think that they're on holiday.
[12:37] <thekorn> jpds, ok, it magically works again now,
[12:37] <jpds> thekorn: GReat.
[12:37] <jpds> great*
[15:29] <skorasaurus> hi, I accidentally created a new 'project' in launchpad. https://bugs.launchpad.net/easytag
[15:29] <skorasaurus> I was triaging a bug for easytag, and I looked back on it today, and saw that was created page was created. I don't know if that should have been created.
[15:30] <skorasaurus> because there's also this page - https://bugs.launchpad.net/ubuntu/+source/easytag
[15:31] <thekorn> skorasaurus, I think it is all right, you "created" this project when you linked this bug to the sf bug tracker
[15:32] <skorasaurus> thekorn, okay, thank you.
[15:43] <skorasaurus> i have a question: why does the status of a bug on launchpad not correspond with the upstream status ? For example, https://bugs.launchpad.net/brasero/+bug/187657
[15:44] <Ryan52> because upstream and ubuntu don't always agree? it may be more important to one than another?
[15:44] <skorasaurus> on the upstream (gnome's bugzilla), it is marked [unconfirmed, normal]
[15:55] <charlie-tca> skorasaurus: the bug is triaged for Ubuntu, not for upstream.
[15:56] <charlie-tca> Sometimes it takes a while for upstream status to catch up on launchpad
[16:01] <skorasaurus> k
[17:50] <hggdh> skorasaurus, upstream status depend on upstream work. A triaged bug on LP will still need to be confirmed upstream
[17:51] <hggdh> these are completely separated BTSs; it may be that upstream has some other requirements before confirming, it may be a dup, etc
[17:54] <persia> There are also many cases where a bug is fixed upstream, but still present in Ubuntu, or vice-versa.
[17:58] <hggdh> BTW, 'BTS' means Bug Tracking System
[22:30] <Rocket2DMn> ok guys, im finishing triage on bug 308978 but i cant decide if its xorg or linux
[22:30] <Rocket2DMn> or even hal i suppose
[22:34] <charlie-tca_> Suspend to ram is acpi-support, isn't it? Otherwise, it is linux, since it happens after suspend
[22:34] <Rocket2DMn> its like a nightmarish mix of all of the above
[22:34] <Rocket2DMn> a usb device that works before suspend, but not after
[22:35] <Rocket2DMn> well it sorta works, just doesnt recognize the language i guess
[22:35] <Rocket2DMn> I guess I should ask if it works after the user restarts X after a resume
[22:36] <Rocket2DMn> if it doesnt, then its not a X problem
[22:38] <charlie-tca_> Is it hibernate being called suspend? If so, it is linux
[22:38] <charlie-tca_> as in the kernel team works that
[22:38] <Rocket2DMn> its not hibernate, its suspend to ram
[22:38] <Rocket2DMn> (standby)
[22:39] <Rocket2DMn> thats initially why i set the bug to xorg instead of linux
[22:48] <charlie-tca_> That should be acpi-support then
[22:48] <charlie-tca_> acpi-support is the package for suspend to ram bugs
[23:09] <Rocket2DMn> ok thanks charlie-tca_
[23:12] <crimsun> err, that's not entirely correct. we need to update it.
[23:13] <crimsun> acpi-support and pm-utils are scripts. if it's a kernel problem, the source package affected needs to be linux.
[23:13] <crimsun> if we're failing to twiddle something in the scripts, however, yes, either acpi-support (old) and/or pm-utils (new).
[23:15] <crimsun> (the situation becomes even more hairy when one considers hal-info)
[23:16] <Rocket2DMn> crimsun, the thought had crossed my mind with hal
[23:17] <Rocket2DMn> have a look at bug 308978 and let me know what package you think is appropriate
[23:17] <Rocket2DMn> the problem with the usb kb only appears after a suspend/resume
[23:19] <crimsun> it's a linux bug.
[23:19] <crimsun> nothing in acpi-support, pm-utils, or hal-info twiddles keyboard locales [because there's no such functionality there]
[23:20] <crimsun> also, note that the reporter's laptop keyboard works fine
[23:21] <crimsun> the symptom is only reproducible using a usb keyboard _post_-resume-from-*
[23:21] <crimsun> the other possibility is that there's a bios issue; perhaps ask the reporter if he's running the appropriate (latest?) bios
[23:25] <LimCore> hi.. kmail crashes ALWAYS when downloading.. how epic is that lol :/
[23:25] <crimsun> it's known
[23:26] <LimCore> the one in 8.10 right? oh meh.. :/
[23:26] <LimCore> how to have a version that does NOT crash now then? im on 8.10
[23:27] <joumetal> does bug 312554 have enough information?
[23:28] <crimsun> LimCore: i really have no idea; most mail clients really frustrate me. i tend to use mutt or some smartphone.
[23:29] <LimCore> btw... why we do not have an OBVIOUS field like ubuntu version and app version in the bug tracker?
[23:29] <LimCore> like.. [ubuntu 8.10] [amd64]  [kmail 4.2.1-...] etc.  most can be auto-filled from user agent
[23:30] <crimsun> LimCore: well, apport does include that. it's a question worth posing on ubuntu-devel-discuss
[23:31] <charlie-tca_> joumetal: the video card from lspci perhaps? Also, what version of ubuntu?
[23:31] <crimsun> joumetal: if that's as much of the trace as you can capture, then unfortunately, yes
[23:31] <crimsun> joumetal: it'd be better if you could grab the entire kernel ring buffer up to that point, perhaps via serial console


[00:24] <maxb> Has anyone used 'bzr qlog', right-click, "Tag revision...." recently?
[00:25] <maxb> It throws a medium has reached concurrent request limit error for me
[00:26] <maxb> filed bug 979484
[02:36] <mgrandi> anyone here ?
[02:38] <lifeless> nobody here but us chickens
[02:39] <mgrandi> darn.
[02:43] <mgrandi> having bugs with bzr-git and no such revision
[07:50] <jam> morning all
[07:50] <poolie> o/ jam
[07:50] <jam> hi poolie
[08:07] <mgz> morning
[08:19] <lifeless> poolie: another todo for your handoff list
[08:19] <lifeless> poolie: gnu maintainer status
[08:29] <maxb> 'bzr testament' doesn't have any option to generate a v3 testament
[08:30] <maxb> I wonder if I should do the simple thing of just adding another switch like --strict, or do the more complex thing of attempting to handle testament types like repository format options
[08:30] <lifeless> imple is good
[08:31] <vila> simple != easy
[08:32] <maxb> Hmm
[08:33] <maxb> So I'd have to create testament format registry to do this right, I suppose
[08:33] <maxb> Does that sound worth doing?
[08:35] <maxb> I guess it does, if we have things as simple as bzrlib.log.author_list_registry
[08:35] <maxb> I wonder if this makes it a sufficiently large change to disqualify targeting not-trunk
[08:36] <vila> probably, but so does adding a --strict switch
[08:54] <mira|AO> heh, nice message “Thanks for submitting this bug report. We should be in touch soon. If you want to talk to somebody now, try #bzr on the freenode irc network.”
[08:54] <mira|AO> I like that.
[08:54] <mira|AO> so, if anyone needs additional info, prod me.
[08:54] <mira|AO> (LP#979690)
[09:01] <mgz> mira|AO: hardy, yum. looks like a bzr-svn issue, not seeing an existing bug at quick look.
[09:01] <mira|AO> yeah, “yum” ☹
[09:01] <mgz> can you attach the output of `bzr tags` on the repo you're trying to push?
[09:01] <mira|AO> bzr tags in the bzr repo or the svn repo?
[09:02] <mira|AO> yeah, I’m awaiting the day I can switch to debian testing…
[09:02] <mgz> I presume the bzr one, but try both.
[09:02] <mira|AO> ok
[09:02] <mira|AO> oh. there are tags. apparently imported from upstream svn…
[09:03] <mgz> potentially deleting a odd (non-ascii maybe?) tag will do as a work around.
[09:05] <mira|AO> I never worked with tags though…
[09:05] <mira|AO> doesn’t look any tags are non-ASCII
[09:07] <mgz> whoops, path not tag.
[09:07] <mira|AO> hm?
[09:08] <mira|AO> bzr: ERROR: unknown command "path"
[09:10] <mira|AO> (still, independent of this problem, _if_ someone has got current bzr debs for hardy, or source debs for something else of the lenny era which I could probably build on hardy, tell me ;)
[09:10] <mgz> I'd missed that the failing assertion was on a path, despite being in tag related code
[09:10] <mira|AO> ah
[09:10] <mgz> looking at the context now
[09:11] <mgz> so, the return of:
[09:11] <mgz> self.branch.layout.get_tag_path(tag_name, self.branch.project)
[09:11] <mgz> is not str...
[09:11] <mira|AO> if you need the two svn repositories, I can point you to that. I _think_ I probably can also put my entire shared-repo up somewhere, but that's huge
[09:11] <mira|AO> ah. maybe this is because the pushed-to repo doesn't have any tags?
[09:12] <mira|AO> (not even toplevel dir)
[09:12] <mira|AO> hm let me see if another bzr push will also crash (despite nothing to push)
[09:12] <mira|AO> yes it does
[09:12] <mira|AO> ok, I'll mkdir a tags dir
[09:12] <mgz> running that push with BZR_PDB=1 set, you should land in the python debugger and be able to do `p path` to answer the question of what it is
[09:12] <mgz> could well just be None if the dir is missing
[09:13] <mira|AO> nope, will still crash
[09:13] <mira|AO> ok
[09:13] <mira|AO> do I need to install something for that debugger?
[09:14] <mgz> nope, it's part of python.
[09:14] <mira|AO> ok
[09:14] <mira|AO> path is None, yes
[09:16] <mgz> okay, do `l`, and then print the arguments to the function listed above that assert
[09:16] <mira|AO> (Pdb) p tag_name
[09:16] <mira|AO> u'debian_version_4_5_14-2'
[09:16] <mira|AO> (Pdb) p tag_target
[09:16] <mira|AO> 'svn-v4:9d84d37e-dcb1-4aad-b103-6f3d92f53bf6:tags/debian_version_4_5_14-2:5614'
[09:16] <mira|AO> 166         def set_tag(self, tag_name, tag_target):
[09:17] <mgz> ace.
[09:17] <mgz> what's the layout object, also on the line above?
[09:17] <mira|AO> *** NameError: NameError("name 'layout' is not defined",)
[09:17] <mira|AO> oh sorry
[09:17] <mira|AO> (Pdb) p self.branch.layout
[09:17] <mira|AO> WildcardLayout(['branches/*', 'trunk/gforge_base/evolvisforge', 'trunk/gforge_base/evolvisforge-5.1', 'vendor/testlink', 'trunk/testlink', 'trunk/mediawiki'],['tags'])
[09:19] <mira|AO> und _space ?
[09:19] <mira|AO> oops
[09:20] <mgz> okay, that should be enough, now either want jelmer, or I'll go back and look at WildcardLayout.get_tag_path in bzr-svn 1.0 because the current version seems fine
[09:20] <mira|AO> hm wait a sec…
[09:21] <mgz>         # FIXME
[09:21] <mgz>         return None
[09:21] <mgz> okay, that's the problem :)
[09:21] <mira|AO> just realised tags should be 'tags/*' not 'tags'
[09:21] <mira|AO> doesn't change anything though
[09:21] <mira|AO> ah ok :)
[09:21] <mira|AO> fixed in later versions, then?
[09:21] <mgz> yes. just checking which now
[09:22] <mgz> you may be able to manually update just bzr-svn without breaking any of your other packages
[09:22] <mira|AO> hmmmmmmm
[09:22] <mira|AO> “may” ;)
[09:22] <mira|AO> (on the other hand, I do want a newer bzr anyway, I occasionally run into minor trouble)
[09:23] <mgz> okay, it's implemented in bzr-svn 1.1.0
[09:23] <mira|AO> oh well. I'll try that, and try to push my boss to allow me to switch to debian sooner
[09:23] <mira|AO> thanks
[09:23] <mgz> you should be able to just remove the bzr-svn package
[09:23] <mgz> and install from source to your user plugins dir?
[09:24]  * mira|AO shudders
[09:25] <mgz> I think https://launchpad.net/bzr-svn/1.1/1.1.2 should be bzr 2.1.0 compatible, and it's an easy check
[09:26] <mgz> unpacking into to ~/.bazaar/plugins/bzr-svn will tell you
[09:27] <mira|AO> heh. actually I can't uninstall it, as our dependency metapackage depends on it…
[09:28] <mira|AO> anyway, thanks for all the help so far
[09:28] <mgz> your user plugins dir should be checked first so should override even without uninstalling
[09:28] <mira|AO> ah ok
[09:28] <mira|AO> I’ll try that
[09:28] <mgz> there may also be another workaround, it's not clear to me why you only started hitting this today
[09:28] <mira|AO> argh. the download link doesn't work…
[09:29] <mira|AO> I did several bzr-svn related things in the meantime
[09:29] <mgz> hm, just did for me
[09:29] <mira|AO> so my subversion.conf was changed
[09:29] <mira|AO> new repos, etc.
[09:29] <mgz> https://launchpad.net/bzr-svn/1.1/1.1.2/+download/bzr-svn-1.1.2.tar.gz
[09:30] <mira|AO> oh this is great
[09:30] <mira|AO> it works with lynx
[09:30] <mira|AO> not with bloatzilla…
[09:30] <mgz> heh.
[09:30]  * mgz is using lynx
[09:31] <mira|AO> Unable to load plugin 'svn'. It requested API version (2, 4, 0) of module <module 'bzrlib' from '/usr/lib/python2.5/site-packages/bzrlib/__init__.pyc'> but the minimum exported version is (2, 1, 0), and the maximum is (2, 1, 0)
[09:31] <mira|AO> mh, I don't normally use it with launchpad
[09:31] <mira|AO> maybe I should ;)
[09:32] <mgz> ah, blast, bzr-svn 1.1 isn't compatible with bzr 2.1 it seems.
[09:32] <mira|AO> mh.
[09:32] <mgz> I'll write up the details on the bug and see if jelmer has any better ideas.
[09:33] <jelmer> mgz: is this for bug 979690 ?
[09:33] <mira|AO> ok
[09:33] <mira|AO> I mean, if it's fixed in a later version, there's nothing I require from you ;)
[09:34] <mira|AO> besides, the push works, it just crashes afterwards
[09:34] <mgz> jelmer: yup, short version WildcardLayout.get_tag_path returns None tripping that assertion, fixed in bzr-svn 1.1.0
[09:37] <mgz> any work arounds you can think of, given updating bzr on hardy is a pain? what gets WildcardLayout used rather than one of the others?
[09:39] <mira|AO> mgz, maybe the fact that the pushed-to SVN repo is a fsck'd up PITA that needs WildcardLayout?
[09:39] <jelmer> unsetting the tags = value altogether, if that's an option?
[09:39] <mira|AO> that's an option, yes
[09:41] <mira|AO> ah. that's what I had before, actually
[09:41] <mira|AO> so the "cause" are the changes to subversion.conf
[09:41] <mira|AO> now all I get is:
[09:41] <mira|AO> bzr: ERROR: Tags not supported by SvnBranch('svn+ssh://mirabilos@svn.evolvis.org/svnroot/evolvis/trunk/gforge_base/evolvisforge-5.1'); you may be able to use bzr upgrade.
[09:41] <mira|AO> and no crash
[09:41] <mira|AO> ok, that'll suffice for now
[09:42] <mira|AO> and I'll try to get a permit to drop hardy earlier…
[18:59] <cody-somerville> Can I use 'remerge' to pull in new revisions from merged branch committed since I began the merge?
[19:13] <wgz> nope, it's only for redoing the current merge
[19:14] <wgz> merge --force can pull in the newer changes, but is a little riskier for your current state
[19:15] <wgz> may have done what you want previously with commit/merge/uncommit but don't recall if I also needed some extra cleanup
[19:17] <wgz> so if you've got lots of half resolved conflicts, you probably just want to pick between resolving fully then doing the new ones, or starting again with the newer rev
[20:00] <mgrandi_> so , i gm getting a bzr: ERROR: bzrlib.errors.MalformedTransform: Tree transform is malformed [('overwrite', 'new-65', u'test')] error when i try to revert one of my branches
[20:05] <damd> how do i remove any new files (non-added, non-commited) in a branch directory?
[20:06] <mgrandi_> bzr rm --keep or something
[20:06] <mgrandi_> oh, they arnt added
[20:06] <mgrandi_> you should be able to get a list of unknowns
[20:06] <damd> this is on windows by the way, so i really don't have any of those fancy xargs applications
[20:11] <wgz> see `bzr help clean-tree`
[20:16] <damd> cheers
[22:31] <thomi> Hi, I'm trying to figure out pipelines. I'm having an issue where when I do 'bzr lp-propose' while in the second pipe of two, it sets the source branch to be the first pipe in the series, rather than the current one.
[22:31] <thomi> Any ideas what I'm doing wrong?
[22:48] <thomi> hmm, it seems like my locations.conf breaks things when I use pipelines.


[08:01] <nysosym> hi there :)
[08:19] <BHSPitMonkey> yo
[11:34] <nysosym> re
[12:04] <nysosym> hi kwwii :)
[12:07] <nysosym> and hi darkmatter :)
[12:07] <nysosym> und PingunZ ^^
[12:07] <PingunZ> hey
[12:08] <nysosym> i can't find the icon for the upper left corner, to change these in /usr/share/icons
[12:08] <nysosym> http://img79.imageshack.us/my.php?image=bildschirmfototo3.png
[12:08] <darkmatter> hi nysosym
[12:08] <nysosym> any ideas?
[12:09] <darkmatter> I'm busy hacking atm ;)
[12:09] <darkmatter> new slab... gnome-main-menu version 2
[12:09] <nysosym> no problem darkmatter ;)
[12:09] <nysosym> wow, what du u change?
[12:09] <nysosym> *do
[12:09] <nysosym> can i be a beta tester? ^^
[12:10] <darkmatter> nysosym, not changing anything really... just making the new version from novell ubuntu friendly
[12:11] <darkmatter> nysosym, http://img215.imageshack.us/my.php?image=screenshotze0.png <--- thats fresh from svn... first compile to see what needs fixing
[12:11] <nysosym> darkmatter: ahh ok nice and thx :)
[12:11] <darkmatter> now time to crack open gedit
[12:12] <nysosym> ahh ok, i know it's a matter of taste, but for me these menu is tooo big ^^
[12:14] <darkmatter> nysosym, "big" is a tradeoff of actual usable design... the slabs not perfect... but you certainly wont get anything more usable in a container any smaller ;)
[12:16] <nysosym> ok :D
[12:16] <nysosym> http://soapbox.msn.com/video.aspx?vid=f9061379-003b-4fc4-b542-0c18bc0e84e2
[12:16] <nysosym> wow....
[12:53] <kwwii> w00t!
[12:53] <kwwii> I got svgs working in GDM to round the boxes
[12:54] <kwwii> nifty doodle
[01:01] <PingunZ> kwwii, show mee
[01:43] <kwwii> PingunZ: gotta figure out how to take a screenshot first :p
[01:43] <kwwii> PingunZ: still working on it, but I could post the files I changed and added if you want to test it
[01:43] <kwwii> I need to make sure that it works at all resolutions
[01:48] <elkbuntu> kwwii, for screenshot, vmware?
[01:50] <nysosym> kwwii: jippi feisty work fine here, now :D
[01:51] <nysosym> But, Network-Manager need new "human-like" icons
[01:52] <darkmatter> ewww... "human-like"???
[01:52] <kwwii> elkbuntu: for some reason I cannot install ubuntu in vmware
[01:52] <kwwii> nysosym: yeah
[01:52] <elkbuntu> this.. is not a good thing :-/
[01:52] <nysosym> darkmatter: why not?
[01:52] <elkbuntu> mind you, vmware hates me too
[01:52] <kwwii> well, my cdrom is in a docking station and for some reason after it boots it does not find the drive
[01:53] <darkmatter> stick to the tango guidlelines... its the standard now
[01:53] <kwwii> elkbuntu: I am sure there is a way around it
[01:53] <kwwii> but I am too lazy to figure it out
[01:53] <darkmatter> and jimmac did up a sweet set of tango nm applet goodies
[01:53] <nysosym> darkmatter: but tango isn't the standard for ubuntu ;)
[01:53] <elkbuntu> kwwii, a recompile probably
[01:54] <elkbuntu> which of course isnt likely ;)
[01:54] <kwwii> ;-)
[01:55] <darkmatter> nysosym, its the standard for gnome and everything else ubuntu is using... which is why ubuntu currently looks like crap... they should either use tangerine or redesign human to follow the guidlines
[01:55] <kwwii> boah, ever looked at the xml that inkscape writes?
[01:55] <kwwii> total shit
[01:55] <kwwii> the app says width=2px
[01:55] <kwwii> and the svg says width="1.95843736"
[01:56] <nysosym> *check*
[01:56] <kwwii> sory for my potty mouth
[01:57] <nysosym> kwwii: no problem :D
[01:57] <elkbuntu> kwwii, forgiven. you do restrain yourself reasonably well ;)
[01:57] <nysosym> thats the true :D
[01:58] <kwwii> bad, bad inkscape
[01:58] <nysosym> kwwii: thats the reason why, some icons looks a little bit blurry
[01:58] <kwwii> I mean, how hard can that be?
[01:58] <kwwii> even AI doesn't do that
[02:00] <kwwii> is the wiki dead?
[02:00] <nysosym> other question, where i can find the icon in the upper left corner to change?
[02:00] <nysosym> http://img186.imageshack.us/my.php?image=bildschirmfotoxb7.png
[02:00] <elkbuntu> kwwii, is a weekend approaching?
[02:00] <elkbuntu> wiki downtime used to be a v.regular weekend occurrance
[02:01] <kwwii> lol
[02:01] <kwwii> nysosym: that is a tango icon
[02:01] <elkbuntu> anything from thursday to monday was fair game
[02:02] <nysosym> kwwii: sure, but this is there when i have activated the human symbols...
[02:02] <kwwii> nysosym: human defaults back to tangerine and then tango
[02:02] <kwwii> it might also be simply copied into Human
[02:03] <nysosym> thx, i will have a look on it kwwii :)
 hmm... it would seem the entire help.ubuntu.com is down.
[02:04] <elkbuntu> seems it's not just the wiki
[02:05] <andreasn> nysosym: the name is system-software-update in apps
[02:06] <elkbuntu> help. seems revived, wiki still sleeps
[02:07] <kwwii> wow, even launchpad is dead
[02:07] <kwwii> who tripped over the cord?
[02:11] <elkbuntu> * mvo_ wonders if something is wrong with bazaar.lp.net
 mvo_: see #launchpad
 Hobbsee: DB vacuuming, another 5 or 10 minutes.
[02:12] <elkbuntu> from -devel, so
[02:13] <nysosym> thx andreasn :)
[02:13] <nysosym> all works fine now :)
[02:14] <kwwii> yeah, you just gotta know the right person :-)
[02:15] <nysosym> yes, in every situations of life :D
[02:21] <PingunZ> kwwii, I was out .. you can make screenies with gdmthemetester
[02:21] <PingunZ> lemme get you the right command
[02:21] <PingunZ> kwwii, gdmthemetester xdmcp YourGDM
[02:22] <PingunZ> and feel free to send me the files ;)
[02:23] <kwwii> PingunZ: no xnest installed here
[02:23] <kwwii> I'll send you files, but know that it is not done yet
[02:23] <kwwii> so no commenting on the artwork :-)
[02:24] <PingunZ> ok
[02:24] <PingunZ> I'll do a screenie ;)
[02:26] <kwwii> PingunZ: http://sinecera.de/human-feisty-rounded.tar.gz
[02:26] <kwwii> the logo looks like crap
[02:26] <kwwii> but the boxes are rounded ;-)
[02:27] <kwwii> we need to test it to see that it works at different resolutions
[02:27] <nysosym> cya
[02:27] <nysosym> go to work now
[02:27] <nysosym> have a nice day
[02:29] <PingunZ> kwwii, uploading screenie
[02:30] <PingunZ> kwwii, http://pingunz.googlepages.com/humangdm.jpg
[02:30] <PingunZ> ^^
[02:32] <kwwii> PingunZ: cool, thanks
[02:32] <kwwii> it works :-)
[02:32] <kwwii> but the logo looks crappy
[02:32] <kwwii> how do you like the entry box?
[02:32] <PingunZ> well .. jpeg compression
[02:33] <PingunZ> looks great
[02:33] <PingunZ> here
[02:33] <kwwii> probably need to tweak the colors a bit
[02:33] <kwwii> but I tried to make it look the same as on the desktop
[02:36] <PingunZ> kwwii, uploading in .png for better quality
[02:37] <kwwii> PingunZ: great, thnx
[02:37] <PingunZ> http://pingunz.googlepages.com/human.png
[02:39] <kwwii> now I'll work on the logo a bit
[02:40] <PingunZ> wasn't the gdm going to be changed
[02:40] <PingunZ> I mean .. that ' smooth ' gdm thingie
[02:45] <kwwii> PingunZ: you mean the face browser or such?
[02:45] <PingunZ> yes .. and it was animated etv
[02:45] <PingunZ> *etc
[02:46] <kwwii> I was hoping so, but I have not heard anything about it in a while
[02:47] <kwwii> I guess that if we do not turn compiz in by default it is impossible
[02:49] <PingunZ> gdm has nothing to do with compiz
[02:50] <kwwii> well, how can you do such 3D stuff without AIXGL or such
[02:50] <kwwii> not compiz, I know
[02:50] <kwwii> wrong choice of words
[02:51] <PingunZ> hmm
[02:51] <PingunZ> if they decide to install video drivers correctly there will be no problem with that gdm
[02:53] <kwwii> the video driver installation has been pushed back to feisty+1
[02:55] <PingunZ> oh
[02:55] <PingunZ> what a shame
[02:56] <kwwii> well, we got a lot of flak about that
[03:04] <PingunZ> what's flak ?
[03:04] <darkmatter> heh.. technically you wouldnt need accelerated gfx to do an animated gdm... you just cant get "3D" without it
[03:05] <darkmatter> PingunZ, getting bitched at
[03:05] <darkmatter> about
[03:05] <darkmatter> etc
[03:05] <PingunZ> ok
[03:05] <PingunZ> so rather negative comments ? :D
[03:05] <darkmatter> yup
[03:05] <PingunZ> I get that
[03:05] <PingunZ> ty darkmatter
[03:05] <PingunZ> btw, how's the menu going ?
[03:06] <darkmatter> kwwii, you should fix them all and clone vista's login for spite ;)
[03:06] <elkbuntu> darkmatter, i believe kwwii rather likes his job
[03:06] <PingunZ> :)
[03:07] <darkmatter> PingunZ, soso... right now I'm not bothering with the schemas, I'm trying to figure out why the places arent showing.. lots of code to dig through
[03:07] <darkmatter> elkbuntu, :P
[03:07] <PingunZ> darkmatter, where can I get it ? :)
[03:08] <PingunZ> a .deb prefferably, I don't really feel like compiling it from source
[03:08] <kwwii> darkmatter: lol
[03:08] <darkmatter> PingunZ, gnome cvs just co gnome-main-menu/branches
[03:08] <darkmatter> no .debs
[03:08] <PingunZ> doh
[03:08] <darkmatter> its in really active dev
[03:09] <PingunZ> oh
[03:09] <kwwii> PingunZ: want to try another logo on that gdm?
[03:09] <PingunZ> yeah, fine
[03:09] <darkmatter> I'm going to check for updates after my nappy... and finish hacking
[03:09] <PingunZ> darkmatter, I'll wait till I'm back from my snowboard vacation then ;)
[03:09] <darkmatter> lol
[03:10] <kwwii> http://sinecera.de/ubuntu.png
[03:10] <elkbuntu> darkmatter, you realise i just read that as 'after my diaper'
[03:10] <kwwii> lol, that is for a different kind of dark matter
[03:10] <darkmatter> PingunZ, the real deal is digging through all the code n backporting to 2.16... meh... I should just install fiesty
[03:11] <PingunZ> I will, when i'm back :)
[03:11] <darkmatter> elkbuntu, sheesh... I'm not that old,,, its like... 2 more years before I need attends
[03:11] <elkbuntu> kwwii, rofl
[03:12] <darkmatter> bbiab.. nature calls... and I answer
[03:12] <kwwii> PingunZ: think you could make another screenshot of that?
[03:13] <PingunZ> you want me to replace the logo with that logo and then make a screenie ?
[03:13] <kwwii> PingunZ: yes please :-)
[03:13] <PingunZ> ok
[03:13] <PingunZ> hold on
[03:17] <PingunZ> kwwii, http://pingunz.googlepages.com/ubuntu.png
[03:18] <kwwii> PingunZ: excellent, thanks
[03:18] <kwwii> ;-)
[03:18] <PingunZ> np
[03:18] <elkbuntu> aww.. decided against gloss?
[03:18] <kwwii> elkbuntu: that is the same logo as in the usplash
[03:18] <kwwii> might have to add some more because it is on a light bg
[03:19] <elkbuntu> yeah, it's a wee bit blurry
[03:32] <kwwii> ok, I am out for a while - bll
[03:32] <kwwii> bbl
[03:33] <kwwii> PingunZ: thanks again for the screenshot - I sent it to sabdfl to get his opinion on the rounded boxes
[03:34] <PingunZ> salute him from me, will ya ? :)
[03:37] <kwwii> lol, yeah
[06:26] <troy_s> greets
[06:27] <troy_s> that new logo in GDM is too heavy.
[06:31] <troy_s> Edgy one still seems superior in elegance.
[06:34] <troy_s> and kwwii -- you should post your 1.9xxxx pixel size issue in #inkscape
[06:34] <troy_s> see if there is a reasoning for it or whatever.
[07:23] <vdepizzol> will ubuntu.com website use a new layout after feisty release?
[07:26] <EmxBA> like which one, vdepizzol ?
[07:26] <vdepizzol> EmxBA: this one? http://www.ingral.com.br/~vdepizzol/ubuntu/index.htm
[07:26] <vdepizzol> (not ready yet)
[07:27] <EmxBA> that's pretty nice :)
[07:29] <andreasn> wow, nice navigation!
[07:31] <vdepizzol> the header menu should look like this old mockup: http://img174.imageshack.us/img174/1219/ubuntuhomejn0.png
[07:34] <EmxBA> Feisty artwork will be designed by kwwii -- of Kubuntu Edgy and KDE Oxygen Icon fame. He will be working closely with sabdfl in the design. Do not expect community involvement in defining this portion. kwwii is only going to do artwork, no job for others or...I don't get it :(
[07:36] <vdepizzol> :|
[09:35] <nysosym> hi there :)
[10:08] <troy_s> greets nysosym
[10:08] <troy_s> nysosym: Missed you a couple of times that you were here.
[10:09] <nysosym> hi troy_s :)
[10:09] <nysosym> sure, i had to do some work
[10:09] <troy_s> Ditto.
[10:09] <troy_s> How are things?
[10:10] <nysosym> very fine, by you?
[10:10] <troy_s> Fine thanks.
[10:11] <nysosym> no problem, everytime again :)
[10:11] <nysosym> what do u do in these times? :)
[10:21] <nysosym> yesterday we have a conversation about the new fedora artwork and that these balloon will be a new metaphor for Fedora. My meaning was, that we need more african style in ubuntu, maybe a african elefant etc. . What do u think about troy_s?
[10:28] <troy_s> nysosym: sorry
[10:28] <troy_s> i was afk
[10:28] <troy_s> back now if you wish to discuss.
[10:28] <troy_s> nysosym: I believe that Fedora is symptomatic of someone with formal training in the fine arts discipline.
[10:29] <troy_s> It is nothing more than a manifestation of a schooled approach -- albeit without the implied discussion regarding audience.
[10:29] <nysosym> troy_s: no problem ;)
[10:29] <troy_s> My personal thoughts regarding 'overarching' Ubuntu design is that it should 100% avoid the plastic looks of vista / osx
[10:29] <troy_s> and turn 100% towards organics.
[10:30] <troy_s> wood, stone, etc.
[10:30] <troy_s> that said, it will never happen.
[10:30] <troy_s> motifs have been around since the dark ages, and Fedora simply implements them.  Again, anyone with 1% of schooled knowledge knows that a motif is one element of your design implementation.
[10:31] <troy_s> Motifs help to bridge continuity, establish your communication (what you are 'saying' between the lines of the design), etc.
[10:32] <troy_s> There are also musical / sound motifs, but that is about sixteen generations past where the development of ubuntu is.  For more information on audio motifs, studying hitchcock doesn't hurt -- as his films used them extensively.
[10:34] <nysosym> yes, the plastic look, is a moldy, wood and stones are very good ideas with a future, bu a well formed wood/stone texture is very difficult to render and i think a lot of people wan't a window with a wood texture like the interior in her car
[10:34] <troy_s> nysosym: Unfortunately it appears that Ubuntu will continue to chase the silly obsolete and archaic plasticky gloss of OSX/Vista and use rather cheeseball imagery for their packaging.
[10:35] <troy_s> nysosym: Yes, organics have been tried (and often reoccur) in interior vehicle design.
[10:35] <troy_s> That said, they have yet to be embraced regarding technology.
[10:36] <troy_s> I believe it could work wonderfully as it tends to communicate a more 'human' / 'real' / 'traditional value' sense -- as opposed to plastic gloss that communicates 'gadgetry'
[10:36] <troy_s> Further, if you examine extremely high end appliances, the current trend is to integrate organics.
[10:36] <nysosym> fully agree with u
[10:36] <troy_s> It all makes perfect sense, but it will never happen.
[10:37] <troy_s> A) We lack educated art folks.
[10:37] <troy_s> B) We lack a leader who values the design aspects of the product.
[10:37] <troy_s> C) We lack a target audience.
[10:37] <troy_s> etc. etc.
[10:38] <nysosym> troy_s: but there are other problems in a window with a wood/stone design, fonts are diffivult to read, small buttons go under in a flood of transitions etc.
[10:38] <troy_s> We do have many talented folks interested, but their abilities will always be only as good as the default design direction permits them to be.
[10:38] <troy_s> nysosym: All negotiable.
[10:38] <nysosym> kwwii: says that a art leader will be adjusted in the next time :)
[10:39] <troy_s> Those are certainly elements that need to be addressed, but to imply that they are insurmountable issues is simply not the case.
[10:39] <troy_s> nysosym: I have zero expectations for Ubuntu design.
[10:39] <troy_s> Which is probably a healthy expectation at this point.
[10:40] <nysosym> hi andreasn
[10:40] <andreasn> hey nysosym
[10:40] <troy_s> Fedora's work has set a new benchmark for all FS design in my opinion.
[10:41] <nysosym> troy_s: sure, another point in the conversation with kwwii was a design specification for ubuntu design. Ma idea was a guidline for 2-3 years, in these time the design of ubuntu will improved in every release, but with a well formed goal.
[10:41] <troy_s> nysosym: I don't know if it needs to take that long at all.
[10:42] <troy_s> nysosym: Once you have an audience, a chosen design communication direction, etc., the bits fall into place rapidly.
[10:42] <troy_s> for example, if you chose something like 'industrial', choosing a palette is relatively easy -- which also limits a plethora of other design issues.
[10:42] <nysosym> troy_s: yes, but other way are insurmountable with a release circle of 6 month, we can't made a design revolution in every release of ubuntu
[10:43] <troy_s> agree
[10:43] <troy_s> but we could realistically be far more flexible
[10:43] <troy_s> either target the LTS releases for entire new looks
[10:44] <troy_s> etc.
[10:44] <nysosym> troy_s: the design of OSX for example is uptodate since 5 Years and the design was improved in every osx release
[10:44] <troy_s> nysosym: Yeah but it is starting to look pretty dated.
[10:44] <troy_s> nysosym: Which again is why I stress that Ubuntu could easily grab the lead in design if it simply had a more innovative attitude.
[10:44] <troy_s> plastics and gloss are bloody _done_
[10:44] <nysosym> troy_s: yes, but what i would say, a design guid with a lifetime with 2-3 years aren't tooo long
[10:45] <nysosym> *guide
[10:45] <troy_s> nysosym: LTS releases are 1.5 years.
[10:45] <troy_s> With a fully firing team, I believe those targets would be very attainable.
[10:46] <nysosym> troy_s: sure, but the question is, "what is the future"
[10:46] <nysosym> we hav matt and gloss, semi matt in a different way, with very smooth transitions
[10:47] <troy_s> nysosym: It doesn't take much to at least make a POKE at the future.
[10:47] <troy_s> nysosym: Simply examine the design trends around you
[10:47] <nysosym> i think, are very less surfaces for the future
[10:47] <troy_s> nysosym: In vehicles, furniture, architecture, etc.
[10:47] <troy_s> Design 'trends' tend to reflect cultural values
[10:48] <troy_s> As we are living with 80s computing trends, they tend to still reflect the values of the 80s
[10:48] <troy_s> being gadets, plastics, etc.
[10:49] <nysosym> troy_s: ok, but the glossy look has a very high priority in many kinds of technology, TFT-Screens, Handys, Notebooks etc.
[10:49] <troy_s> 90s introduced the idea that we have a responsibility to the environment -- recycling, global warming, etc., -- and by no fluke -- a good deal of 'organic grown' produce became mainstream.
[10:49] <troy_s> nysosym: Yes.  They are chasing yesterday.
[10:49] <troy_s> nysosym: If you look to the entire spectrum of technology vendors
[10:49] <troy_s> nysosym: How many are noted for their design innovation?  ;)
[10:49] <troy_s> that is a pretty good indicator.
[10:50] <troy_s> I can think of Apple in the 90s.  That is about where it ends.
[10:51] <nysosym> ohh i think i know many design inovations in technology, especially in concept cars. The glossy look is very actual, and aluminum although. That all thing that we have in the past or in these time
[10:51] <nysosym> really new structures aren't availabe
[10:52] <troy_s> when i said technology vendors, i was specifically referring to computing, sorry.
[10:52] <troy_s> Some car design has been innovated.
[10:52] <troy_s> etc.
[10:54] <troy_s> but the 'plastic' design issue is larger than simply discussing gloss -- there are many natural organic objects that offer specular gloss etc.
[10:54] <troy_s> it really is the 'full' communication package -- for example, look at Vista's packaging
[10:55] <troy_s> The inner display 'retainer' clip is clearly visible, the product case is thick enough to expose the refraction of the plastic, etc.
[10:55] <troy_s> the packaging artwork binds up the plastic glossy feel.
[10:55] <troy_s> etc.
[10:55] <troy_s> Very clearly they are trying to catch onto the consumer 'must have this shiny plastic gadget' trend.
[10:57] <nysosym> and again i agree with u, i waiting for a long time, for something new on the desktop market. Organic structures are very good, u will have the feeling, that du doesn't use a computer, but a thing that u help to life your life.
[10:57] <troy_s> Yep!
[10:57] <troy_s> Bingo - smack on.
[10:57] <troy_s> Computers went from being expensive toys (Apple ] [ era)
[10:57] <troy_s> to useful 'office equipment' (Win 3.1 era)
[10:58] <troy_s> to very much a manifestation of life
[10:58] <troy_s> art/music/
[10:58] <troy_s> education
[10:58] <troy_s> etc.
[10:58] <troy_s> r
[10:58] <troy_s> 'real life'
[10:58] <troy_s> and therefore, the no brainer design direction is to reflect those values in the design of the desktop computer / interface.
[10:59] <nysosym> yes, that's the trend, life your life on a PC, without a feeling that u use a PC. So many portals for people, games, blogs, video communitys ect.
[10:59] <nysosym> that feeling should be banned on the desktop
[11:00] <nysosym> and again, these will be possible with multitouch displays
[11:00] <troy_s> Realistically, Ubuntu is a perfect candidate to establish the newer trend.
[11:00] <troy_s> It simply 'fits' too well.
[11:00] <nysosym> fresh design in combination with a new input method will be the best thing to give people these feelings
[11:03] <troy_s> Ok.  I must run out to pick up some things for the house.   I'm doing alright... just woke up actually. How are you doing?
[12:08] <nysosym> i need some sleep, but i have no reaction to do that ^^


 "Could this be related to https:/..." <- I don't think so; we just don't restore state on switch-to (or rather, we restore *some* state, but if the thing we're switching from has made any significant changes to KMS state we'll be confused)
[03:06]  * RAOF 's SSH keys being on his physical keychain strikes again!
[08:22] -GitHub[m]:#mir-server- **[MirServer/mir]** bors[bot] merged [pull request #2494](https://github.com/MirServer/mir/pull/2494): Add ImmediateExecutor
[16:57] -GitHub[m]:#mir-server- **[MirServer/ubuntu-frame]** AlanGriffiths closed [issue #72](https://github.com/MirServer/ubuntu-frame/issues/72): Does not pick up "mir-quirks" from a graphics provider until `configure` runs
[19:50] <sophie-w> virtual-pointer is mostly completed, but I've run into problems with absolute motion. It appears our seat implementation never respects absolute motion, and there's no way to mark an event as having it or not.
 "virtual-pointer is mostly..." <- I think there are some existing bugs about absolute motion (from long ago). May be able to sweep them up if you're looking at this.
[20:14] <sophie-w> Indeed, might be time to do some refactoring of pointer events
[20:44] <grayson-g[m]> Still scratching my head on why it doesn't seem like some of the Mir libraries are getting installed when i `make install`. I would like to run Frame outside of a snap so I can run GDB on it, but I can't install an up-to-date version of Mir with the libraries for some reason.
[20:54] <grayson-g[m]>  * Still scratching my head on why it doesn't seem like some of the Mir libraries are getting installed when i `make install`. I would like to run Frame outside of a snap so I can run GDB on it, but I can't install an up-to-date version of Mir with the libraries for some reason.... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/dfdf578d5d50e181685335abe13dda84090487c7)
[21:01] <grayson-g[m]> > <@grayson-g:matrix.org> Still scratching my head on why it doesn't seem like some of the Mir libraries are getting installed when i `make install`. I would like to run Frame outside of a snap so I can run GDB on it, but I can't install an up-to-date version of Mir with the libraries for some reason.... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/4846bdf42fb42d1b33b06fff5bb1f6b93b3e041c)
[21:01] <sophie-w> These two scripts might be helpful:
[21:01] <sophie-w> https://github.com/wmww/personal/blob/master/repos/mir/run_cmake.sh
[21:01] <sophie-w> https://github.com/wmww/personal/blob/master/repos/mir/use_this_mir.sh
[21:02] <sophie-w> Specifically, I run cmake with `-DCMAKE_INSTALL_PREFIX="$INSTALL"  -DCMAKE_INSTALL_RPATH="$INSTALL/lib"`
[21:03] <sophie-w> (Where install is `~/code/mir/install`)
[21:03] <sophie-w> Or any directory I don't need sudo to write to
[21:05] <sophie-w> And then I set... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/29be75455c28dbc722e46aa092d2b838acd5b0ab)
[21:07] <sophie-w> Then in a shell with those set (so either those commands run directly in the shell, or a shell where `source .../use_this_mir.sh` has been run), I can run cmake, make and then run the Mir-based shell (such as ubuntu frame)
[21:08] <sophie-w> And it all works. That means I don't need root at any point to build, "install" and use Mir, and I can have multiple versions of Mir "installed" to different directories and select which I want to use.
[21:10] <sophie-w>  * And then I set... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/f6de6763fac7d9d4c1e22481082fc732b2413d33)
[23:37] <RAOF> https://gitlab.freedesktop.org/wayland/wayland/-/blob/main/protocol/wayland.xml#L2254