[00:07] -SwissBot:#ubuntu-news- ::Softpedia:: openSUSE Leap 42.3 Linux OS Reached End of Life, Upgrade to openSUSE Leap 15.1 @ https://news.softpedia.com/news/opensuse-leap-42-3-linux-os-reaches-end-of-life-upgrade-to-opensuse-leap-15-now-526565.shtml (by Marius Nestor)
[05:25] -SwissBot:#ubuntu-news- ::Planet:: Stephen Michael Kellat: Quick Bits @ http://coyote.works//posts/QuickBits20190630/
[11:46] -SwissBot:#ubuntu-news- ::Planet:: Canonical Design Team: Canonical现提供Kubernetes 1.15升级 @ https://admin.insights.ubuntu.com/2019/06/30/canonical-kubernetes-1-15-upgrade/
[11:58] -SwissBot:#ubuntu-news- ::Planet:: Canonical Design Team: Ubuntu Server development summary – 26 June 2019 @ https://admin.insights.ubuntu.com/2019/06/26/ubuntu-server-development-summary-26-june-2019/
[13:16] -SwissBot:#ubuntu-news- ::OMG!Ubuntu:: GNOME Shell is Adding Another Much-Requested Feature @ https://www.omgubuntu.co.uk/?p=145786 (by Joey Sneddon)
[14:52] -SwissBot:#ubuntu-news- ::OMG!Ubuntu:: Cinnamon 4.2.0 Features Plenty of Bug Fixes, But Nothing Shiny @ https://www.omgubuntu.co.uk/?p=145813 (by Joey Sneddon)
[20:49] -SwissBot:#ubuntu-news- ::Softpedia:: Purism's Security Key Will Generate Keys Directly on the Device, Made in the USA @ https://news.softpedia.com/news/purism-s-security-key-will-generate-keys-directly-on-the-device-made-in-the-usa-526570.shtml (by Marius Nestor)
[21:15] -SwissBot:#ubuntu-news- ::Planet:: Stephen Michael Kellat: A LaTeX Quick Hit @ http://coyote.works//posts/QuickBits20190630-1/


[14:56] <riky123123> anyone can suggest  a good free web builder?
[15:00] <knome> gedit
[15:08] <riky123123> does it have an admin where i can modify it ?
[15:28] <knome> ..it's a text editor.
[15:30] <SiDi> riky123123: if you are looking for something like dreamweaver, my ideals about the web will unfortunately prevent me from answering you :P
[15:30] <SiDi> otherwise gedit isnt that bad. If you do XML/XSLT, Oxygen is good but im not sure if they have a linux version
[15:51] <knome> gedit has nice color highlighting :P
[20:14] <jpds> AH! Where's newz?
[21:48] <MT-> jpds: I think he said he's been traveling a lot lately so no reliable connection
[21:48] <jpds> MT-: So I read later on.
[21:48] <MT-> :)
[21:48] <MT-> jpds: since you have nothing to do without him for the moment.... fix my site :)
[21:50] <jpds> MT-: Howso? :)
[21:51] <MT-> This error - Fatal error: Cannot redeclare udcountdown_install() (previously declared in /home/michael/ubuntu-drupal-dev/countdown/udcountdown.install:9) in /home/michael/ubuntu-drupal-dev/iebanner/udiebanner.install on line 9
[21:51] <MT-> no explanation why it's happening.. the thing shouldn't be looking at the install file and there's no reason for the file to be called twice
[21:53] <knome> where's the module source?
[21:54] <MT-> /home/michael/ubuntu-drupal-dev/countdown/
[21:54] <knome> i have no /home/michael? ;)
[21:54] <MT-> If I remember the first function, it complains about the next one being duplicated
[21:56] <jpds> MT-: Sorry, I don't really do PHP.
[21:56] <MT-> jpds: you do now, now fix it
[21:56] <knome> i can try to help, if somebody points me to the source
[21:56] <knome> ...
[21:56] <knome> the internet source, not the global :P
[21:56] <MT-> I think I just managed to get it. I removed the file, ran update.php, then moved the file back
[21:57] <knome> okay.
[21:57] <MT-> knome: thanks though - https://edge.launchpad.net/ubuntu-drupal-countdown
[21:57] <knome> okay, might look at it anyway.
[21:57] <knome> is there a module for wordpress ors hould somebody write one?
[21:58] <MT-> it would have to be written
[21:59] <knome> okay.
[21:59] <knome> is there any interest toward one?
[21:59] <MT-> not for me, I use Drupal for my blogs
[22:00] <MT-> You could sure grab that are try to make one :)
[22:01] <knome> "try" ;)
[22:01] <knome> i think that is only matter of doing or not doing :)
[22:02] <MT-> knome: well, if you're going to redo that, then you need a cron - I didn't think wordpress had a built in cron
[23:01] <knome> hm.
[23:01] <knome> suppose it doesn't. but does drupal do then?
[23:02] <MT-> knome: yup
[23:02] <MT-> there's a _cron hook that you just toss in the module
[23:02] <knome> right..
[23:02] <knome> i have used drupal in a few client projects
[23:03] <knome> i don't remember seeing a cron or then it wasn't good enough so i had to install some cron module
[23:04] <MT-> when did you use it last?
[23:04] <MT-> idk about D4, but D5 and D6 both do
[23:04] <knome> umm... i think it's about 3 months, but the last time i looked at the cron stuff it must've been like 6 months.
[23:04] <knome> i used 5
[23:05] <MT-> The whole point of the cron is so that it can pull the latest source for banner options. I'm guessing you saw that already though
[23:06] <knome> didn't look at the source code yeat
[23:06] <knome> *yet
[23:06] <knome> i suppose there is wp cron plugins
[23:40] <MT-> knome: the module itself is really simple. Check if a value changed, if it does it downalods and unpacks a tarball - the admin section lets you pick an option
[23:40] <knome> right
[23:40] <MT-> you looked already?
[23:40] <knome> nope.
[23:40] <knome> but understood already:)
[23:40] <MT-> oh
[23:41] <MT-> that's about all there is to it
[23:42] <knome> yep
[23:42] <knome> i might look at it soonish


[04:20] <pitti> Good morning
[04:51] <RAOF> pitti: Hey, I'm testing colord 1.0.1. Does adt
[04:51] <RAOF> pitti: Hey, I'm testing colord 1.0.1. Does adt-run-test support Restrictions: build-needed? Because it seems to not be doing that.
[04:54] <pitti> hey RAOF
[04:55] <pitti> RAOF: it does, but ATM it does it wrongly, see debian bug 711209
[04:55] <ubot2`> Debian bug 711209 in autopkgtest "autopkgtest: build-needed restriction doesn't actually run tests in built tree" [Normal,Open] http://bugs.debian.org/711209
[04:55] <pitti> RAOF: that bites me in umockdev as well, so today I'll look for a workaround
[04:55] <pitti> RAOF: or rather, fix that in adt-run
[05:07] <RAOF> pitti: So, with that caveat, you may enjoy the debian/1.0.1-1 tag in colord's collab-maint git repository.
[05:07] <pitti> RAOF: yay
[05:08]  * pitti checks whether the keyring update in Debian has happened by now
[05:08] <pitti> RAOF: ah, seems it didn't yet, so I can't upload yet
[05:09] <RAOF> Heh. Fair 'nuff.
[07:04] <jibel> good morning
[07:09] <didrocks> salut jibel, ça va?
[07:12] <jibel> salut didrocks , bien et toi?
[07:14] <pitti> bonjour didrocks
[07:15] <didrocks> bonjour pitti, ça va?
[07:15] <didrocks> jibel: ça va, semaine qui démarrre en fanfarre, mais bon :)
[07:15] <pitti> didrocks: ça va très bien ! j'ai eu un bon week-end
[07:15] <didrocks> pitti: tu as fait quoi?
[07:16] <pitti> didrocks: I'm going to blog/G+ about it RSN, watch out :)
[07:18] <didrocks> pitti: heh, will do! :)
[07:34] <seb128> good morning desktopers
[07:35] <didrocks> salut seb128!
[07:36] <seb128> lut didrocks!
[07:36] <sil2100> Morning!
[07:36] <sil2100> didrocks: hi! How was your long weekend? :)
[07:37] <seb128> hey sil2100
[07:37] <didrocks> sil2100: hey, was hot in Lyon! :) Got to the spa on Friday morning
[07:37] <didrocks> was good, not too many people
[07:37] <sil2100> Excellent
[07:37] <didrocks> then, a lot of cycling (~30 kms) within the city
[07:38] <didrocks> how was yours?
[07:38] <sil2100> Ahh, I miss my bike, would love to ride a bit now that the weather is so nice
[07:39] <pitti> didrocks: done :)
[07:39] <pitti> bonjour seb128
[07:39] <didrocks> pitti: looking :)
[07:39] <sil2100> didrocks: not bad, only had one day for resting theoretically, but I bummed around as much as I could ;)
[07:39] <seb128> pitti, salut, ça va bien ?
[07:39] <sil2100> didrocks: btw. I see that the queue still has dbus-cpp and location-service waiting as (sync)
[07:39] <didrocks> sil2100: yeah, I waited to ask you for it
[07:40] <didrocks> it's from yesterday's right?
[07:40] <pitti> seb128: en effet, je vais très bien ! mon weekend était mervellieux
[07:40] <sil2100> didrocks: it was from Friday
[07:40] <didrocks> sil2100: oh, is seb128 to blame? :p
[07:40] <seb128> pitti, super, tu as fait quoi ?
[07:40] <sil2100> seb128: hi! Was there some issue with NEWing those two? ^
[07:40] <pitti> seb128: https://plus.google.com/107564545827215425270/posts/VtrGcA74wP9
[07:40] <didrocks> sil2100: I can NEW them, I reviewed them, apart if seb128 has some remarks on them
[07:40] <seb128> sil2100, no, they were just not in the queue at 7pm friday when I called it a week
[07:41] <didrocks> seb128: tsss, 7pm on Friday and you call it a week? How dare you! :p
[07:41] <sil2100> seb128: ok! didrocks: could you NEW ;) ?
[07:41] <didrocks> sure
[07:41] <seb128> haha
[07:41] <sil2100> Thanks, I'll check the stacks now
[07:41] <didrocks> sil2100: ok, so on the stacks they both are, maybe you should rebuild those components
[07:41] <didrocks> sil2100: once the merge back to trunk is done
[07:41] <sil2100> I think we missed some new packages, but since there were some issues with tests and releasing, we only got that many new ones out
[07:41] <didrocks> (for dbus-cpp and location-service)
[07:41] <didrocks> sil2100: otherwise, the changelog will be screwed
[07:42] <seb128> didrocks, I was not sure they would land there since we had issue earlier in the day due to the lillypilly checklist (I think)
[07:42] <didrocks> seb128: yeah, I saw a reject
[07:42] <seb128> didrocks, the copy there was not uptodate and not listing some of the components
[07:42] <didrocks> telepathy-ofono
[07:42] <didrocks> right?
[07:42] <seb128> and apparently trying to republish the same version doesn't work
[07:42] <seb128> yes
[07:42] <sil2100> Yes
[07:42] <didrocks> seb128: you have to cheat, it's possible to republish
[07:43] <didrocks> seb128: sil2100: so that you know how it works
[07:43] <seb128> we tweaked the changelog
[07:43] <seb128> to bump the version
[07:43] <didrocks> remember those .project files?
[07:43] <didrocks> this is what are used to track what we didn't publish yet and need to monitor
[07:43] <sil2100> didrocks: hm, so what should I do now with dbus-cpp and location-service? Should I rebuild those stacks and republish? Or merge something to their trunks?
[07:43] <sil2100> didrocks: remember those, yes
[07:43] <didrocks> as you can rebuild one part of the stack, we remove those .project file and recreate them
[07:43] <didrocks> but you can as well publish them multiple times
[07:43] <didrocks> (without rebuilding the whole stack)
[07:44] <didrocks> so they are renamed .project_<timestamp>
[07:44] <seb128> ok
[07:44] <didrocks> if you need to republish the same version again, you need to mv package.project_<timestamp> package.project
[07:44] <didrocks> then launching the publication
[07:44] <sil2100> Awesome to know
[07:44] <sil2100> \o/
[07:44] <sil2100> Cheating is awesome
[07:44] <didrocks> heh
[07:45] <didrocks> well, it's not that easy, but in practice, this is "only" for new components
[07:45] <seb128> pitti, that sounds like a fun sunday ;-)
[07:45] <didrocks> sil2100: so, yeah, once the changelog is merged back to dbus-cpp and location-service, please rebuild those
[07:45] <didrocks> (just those components)
[07:45] <didrocks> so get a real changelog :p
[07:46] <didrocks> pitti: waow, excellent!
[07:46] <sil2100> But but dbus-cpp and location-service already have 0.0.1daily<IP_ADDRESS>-0ubuntu1 in them ;p
[07:46] <didrocks> sil2100: oh oh, silly me :)
[07:46] <didrocks> yeah, it was "just" in NEW
[07:46] <didrocks> but the diff isn't correct
[07:46] <sil2100> Since those got published and just got stuck in the queue
[07:46] <didrocks> yep :)
[07:47] <didrocks> the only thing not "right" is the diff
[07:47] <didrocks> between distro and bzr
[07:47] <didrocks> to know if anything new was generated
[07:47] <pitti> seb128: indeed it was, Lieutenant!
[07:47] <seb128> pitti, ;-)
[07:47] <didrocks> sil2100: so, just wait them to be published in -proposed
[07:47] <didrocks> sil2100: and then relaunch them, maybe (I guess even :p) nothing new will be to be published
[07:48] <sil2100> \o/
[07:48]  * didrocks loves http://piware.de/fotos/Filmwelt-Bakede-Jun2013/slide_09.html
[07:48] <didrocks> with the red eyes, it seems to be on purpose
[07:50] <pitti> didrocks: je crois que Kirk n'ai pas des yeux rouges ?
[07:50]  * hyperair wonders if anyone here is having intermittent issues with gtalk authentication in empathy
[07:50] <didrocks> pitti: non, en effet, juste que je trouve que ça va bien dans le contexte tout de même :)
[07:50] <pitti> hyperair: I actually used to have, but it seems to have stabilized in the recent weeks
[07:50] <pitti> didrocks: :)
[07:51] <hyperair> pitti: in saucy?
[07:51] <didrocks> pitti: hum, it seems that Unity 7 became jaleous of the Unity 9 interface and decided to freeze :p
[07:51] <pitti> hyperair: yes (is there any other release? :) )
[07:51] <hyperair> heh
[07:51] <hyperair> that should mean there's an SRUable patch, shouldn't it?
[07:52] <pitti> hyperair: I had the impression it was due to changes on the google side
[07:52] <hyperair> no, i'm not sure it is.
[07:52] <hyperair> i just killed signonpluginprocess, and it worked again
[07:52] <pitti> hyperair: maybe you have something different
[07:52] <hyperair> previously i'd been removing and re-adding the google account in signon-ui
[07:59] <sil2100> didrocks, seb128: I'll jump out for a quick exercise now, since the weather is excellent
[07:59] <didrocks> sil2100: enjoy :)
[07:59] <sil2100> Be back in some moments!
[07:59] <seb128> have fun!
[08:00] <Laney> morning
[08:01] <hyperair> weather eh.. it's hazy as hell over here in singapore.
[08:35] <seb128> Laney, oh, I didn't notice your "morning" earlier, good morning! ;-)
[08:35] <Laney> heh
[08:35] <Laney> hey seb128!
[08:35] <Laney> it does seem quiet ;-)
[08:35] <pitti> hey Laney, good morning
[08:35] <seb128> everybody doing monday email catchup etc I guess
[08:36] <didrocks> hey Laney!
[08:37] <Laney> \o/
[08:44] <mlankhorst> morning
[08:44] <mlankhorst> i mean
[08:44] <mlankhorst> bonjour!
[08:44] <pitti> ça va mlankhorst ?
[08:44] <mlankhorst> very good
[08:44] <mlankhorst> I exhausted my french for this week :-)
[08:46] <mlankhorst> but the weather was nice saturday http://imgur.com/uVxApz4
[08:47] <didrocks> bonjour mlankhorst :)
[08:49] <pitti> mlankhorst: wow, that's a funny bike that you have there!
[08:51] <mlankhorst> aye, I haven't tried the max speed yet
[08:52] <Laney> bet it requires a lot more maintenance than a push bike :P
[08:54] <mlankhorst> yeah but I don't have to do most of it myself :-)
[09:02]  * mlankhorst is still using a conventional bike to get to the stables
[09:29]  * didrocks tries some reboots, bbiab
[09:31] <didrocks> sil2100: back from exercising? :)
[09:47] <didrocks> Laney: hum, you do have some upstart-session knowledge, right? :)
[09:47] <Laney> a small amount
[09:48] <didrocks> do you have time for a small experiment? I think I probably did something wrong and it will take more time for me to debug
[09:48] <didrocks> if you apt-get source unity
[09:48] <Laney> if I can't help then there are others who know more though :P
[09:48] <didrocks> and apply that patch: http://bazaar.launchpad.net/~unity-team/unity/trunk/revision/3364
[09:49] <didrocks> does it start the panel service on session startup for you?
[09:49] <didrocks> (it doesn't for me)
[09:49] <didrocks> I wonder if ted is relying on one of the new indicators to emit indicators-loaded
[09:49] <didrocks> and we don't have that signal
[09:49] <didrocks> (in a vanilla installation)
[09:50] <Laney> Looking at the file it could be that 'start on started' is too late
[09:50] <Laney> depending on what it needs
[09:50] <Laney> but let me try
[09:50] <didrocks> $ grep indicators-loaded /usr/share/upstart/sessions/*
[09:50] <didrocks> /usr/share/upstart/sessions/unity-panel-service.conf:emits indicators-loaded
[09:50] <didrocks> and nothing else
[09:50] <didrocks> Laney: yeah, keep me posted :)
[09:50] <didrocks> thanks!
[09:50] <Laney> that means that it sends a signal for others to look at
[09:51] <didrocks> yeah, I just realized I misread
[09:51] <Laney> shouldn't affect the emitting service being run
[09:51] <didrocks> I'll blame the hot weather :p
[09:51] <sil2100> Back ;)
[09:51] <didrocks> oh but, the other patch is "if we are under gnome-session… don't use the unity upstart job"
[09:52] <Laney> the other?
[09:52] <sil2100> Resuming loking at stacks this very instance! Had to freshen up, since it's a bit too sunny for exercising
[09:52] <didrocks> Laney: no, ignore me, the script exit 0, I think the event is emmitted
[09:52] <didrocks> (in unity.conf)
[09:53] <didrocks> sil2100: do you have time for a quick hangout to catch up?
[09:53] <Laney> didrocks: does 'status unity-panel-service' show it running?
[09:53] <sil2100> didrocks: how about in 7 minutes?
[09:53] <didrocks> sil2100: sure
[09:54] <didrocks> Laney: I ran it by hand, does it impacts it? I can try a guest session
[09:54] <didrocks> $ status unity-panel-service
[09:54] <didrocks> unity-panel-service stop/waiting
[09:54] <didrocks> $ status unity
[09:54] <didrocks> unity stop/waiting
[09:54] <Laney> I don't have a unity upstart job
[09:55] <didrocks> Laney: weird, I didn't revert that one AFAIK
[09:55] <didrocks> http://bazaar.launchpad.net/~unity-team/unity/trunk/revision/3361
[09:55] <didrocks> start on started gnome-settings-daemon and xsession SESSION=ubuntu
[09:55] <Laney> wait, I'm lying
[09:55] <didrocks> ah :)
[09:55] <didrocks> gnome-settings-daemon is started here
[09:55] <Laney> but it isn't running
[09:55] <Laney> unless I got it today
[09:56] <didrocks> Laney: no, not from today
[09:56] <didrocks> and not running here as well
[09:56] <didrocks> so "and xsession SESSION=ubuntu" is faly?
[09:56] <didrocks> falsy*
[09:56] <Laney> let me see
[09:56] <didrocks> ah, there is a stop in the script
[09:57] <Laney> aha, yes, it's tripping that
[09:57] <Laney> see ~/.cache/upstart/unity.log*
[09:57] <Laney> so your indicator event won't happen
[09:57] <didrocks> right
[09:57] <didrocks> grrr ted :p
[09:58] <didrocks> in fact the check should be in the exec part
[09:58] <Laney> that's the right way to do a conditional start
[09:58] <didrocks> yeah, but we still want to see the "unity" event started
[09:59] <didrocks> can this be expressed in some way? (I don't think we want a super long "exec" line)
[09:59] <Laney> kind of confused by this
[09:59] <Laney> when wouldn't gnome-session be used?
[09:59] <didrocks> Laney: touch
[10:00] <didrocks> (I know, no sense for unity7 without xmir for now)
[10:00] <didrocks> but I think ted wanted to implement it for the future
[10:00] <didrocks> (the day of releasing unity 7 of course, hence the revert I had to do :p)
[10:00] <sil2100> didrocks: https://code.launchpad.net/~sil2100/cupstream2distro-config/apps_extra_packages_for_gallery/+merge/169756 <- could you take a look?
[10:01] <Laney> I guess started unity is the wrong thing for us at this point
[10:02] <didrocks> sil2100: ok, making sense, thanks!
[10:02]  * Laney fires up the vm
[10:02] <sil2100> didrocks: this would unblock Apps, looking at Indicators but LP is taking its time today\
[10:03] <sil2100> didrocks: hanging out in a moment?
[10:03] <didrocks> Laney: do you mind tracking that once ted is back? you clearly have more knowledge on how we should build the sessions upstart once moving away from gnome-session to upstart to handle it
[10:03] <didrocks> sil2100: I'm ready right now, tell me when you are
[10:03] <didrocks> (I'll just exercice after this hangout)
[10:03] <Laney> I can probably figure out something to fix this up
[10:03] <sil2100> didrocks: I'll just finish indicators and ready
[10:03] <Laney> but I don't really have a handle on moving away from gnome-session completely
[10:03] <didrocks> thanks Laney :)
[10:04] <Laney> np
[10:04] <didrocks> sil2100: ok
[10:05] <sil2100> didrocks: ok, it seems that jbicha broke indicator-session on Saturday
[10:05] <sil2100> Will have to wait for him to pop up
[10:05] <didrocks> "nice", ok :/
[10:07] <sil2100> didrocks: do you have a hangout link ready by any chance ;)?
[10:08] <didrocks> sil2100: https://plus.google.com/hangouts/_/d9e1fb52de2cf1cc1d14d5aca163296f609ed875?hl=fr
[10:24] <seb128> sil2100, how did he break it?
[10:36] <Laney> didrocks: OK, got it
[10:36] <Laney> didrocks: try "start on started unity or desktop-start DESKTOP_SESSION=ubuntu" / "stop on desktop-end"
[10:52] <Laney> seb128: have you tried system-settings on the device?
[10:52] <seb128> Laney, no, I planned to do that today ... does it work?
[10:52] <Laney> it's a bit buggy
[10:52] <Laney> like I couldn't get back from the individual panels
[10:52] <seb128> it's a bit annoying that you can't just deploy from qtcreator as you do for pure qml programs
[10:52] <seb128> oh
[10:53] <seb128> I will have a look
[10:53] <Laney> it just flicked instead
[10:54] <Laney> do you think it's ok to merge the appearance stuff with the example content?
[10:54] <Laney> I don't think I can do much more without dconf or the content picker
[11:02] <didrocks> Laney: sorry, was in this hangout :)
[11:02] <Laney> np
[11:02] <didrocks> Laney: nice!
[11:02] <Laney> does it work?
[11:02] <didrocks> let me try
[11:03] <Laney> you can't have 'stop on stopping unity' because that is triggered by the job aborting itself
[11:03] <Laney> that one confused me for a bit
[11:03] <didrocks> started unity is true even if the job stopped I guess?
[11:04] <Laney> no
[11:04] <didrocks> ah or
[11:04] <Laney> but stopping is
[11:04] <didrocks> hum
[11:04] <Laney> pre-start -> stopping -> stopped I think
[11:04] <didrocks> I think ted wanted to start only if unity startede
[11:04] <didrocks> started*
[11:04] <Laney> that's what the desktop-start should do
[11:04] <Laney> it comes from gnome-session
[11:04] <Laney> so you have both
[11:04] <didrocks> yeah, it's a bit "uncrystalclear"
[11:05] <didrocks> but works in theory
[11:05] <didrocks> let me see :)
[11:05] <Laney> can comment it
[11:05] <didrocks> contrive* was the term I was looking for :)
[11:05] <Laney> it's new world and old world
[11:05] <didrocks> heh, right
[11:05] <Laney> you're going to get stuff like this until we are ... converged ...
[11:07] <didrocks> Laney: working fine :)
[11:07] <didrocks> (tried multiple starts)
[11:07] <didrocks> so yeah, please, add a comment and I'll approve it :)
[11:07] <Laney> I suppose you could simplify it further if you made the unity job emit that desktop-start signal
[11:07] <Laney> thanks!
[11:08] <didrocks> yeah, not sure if we can emits since the pre-start script though
[11:08] <didrocks> from*
[11:08] <Laney> you'd probably do it in post-start
[11:08] <Laney> see /usr/share/upstart/sessions/gnome-session.conf
[11:09] <didrocks> ah, so you mean, removing the unity signal, but have "destkop-start & session==…"
[11:09] <Laney> edit debian/unity.conf to have the same post-start and pre-stop as gnome-session does
[11:09] <Laney> then have unity-panel-service just listen for desktop-start/desktop-end
[11:10] <didrocks> not sure if it's semantically correct, it's like if we were telling the session is ready if unity is ready (and we don't care about the rest)
[11:10] <didrocks> as you wish, the best in your opinion :)
[11:11] <didrocks> if we tell "DESKTOP_SESSION" is used to detect we are using gnome-session, I'm fine with it
[11:12] <Laney> ok
[11:12] <Laney> where's the MP?
[11:13] <didrocks> Laney: oh, there is none, it's part from a revert, so reintroduce the revert + your additional commit I would say
[11:13] <Laney> sure
[11:13] <didrocks> (I had to revert it in a hurry the day we released unity 7 as having that + a segfault was enough :p)
[11:14]  * Laney meditates for a minute on what is better
[11:14]  * didrocks lights a candle for Laney
[11:16] <seb128> Laney, sorry, I was grabbing a bite ... merge the background panel makes sense yes
[11:17] <Laney> ok
[11:17] <Laney> I want to get a widget merged into the ui toolkit first, so will try that this afternoon
[11:18] <seb128> cool
[11:20] <xclaesse> is there a trick to restart unity and keep the workspace where each window are?
[11:20] <xclaesse> like gnome-shell does when doing alt-f2 r
[11:20] <xclaesse> if I just do unity --replace then all my windows goes to first workspace
[11:21] <seb128> hum, they should not, seems like a bug
[12:25] <sil2100> seb128: regarding the indicator-session, I just checked and my conclusions were too soon - jbicha did not break it, it broke itself probably due to changes in saucy
[12:25] <sil2100> seb128: as it's the same issue as with some other packages - pthread errors
[12:25] <seb128> sil2100, what's the error it hits?
[12:26] <seb128> oh, yeah, new binutils being pickier about incorrect linkage
[12:26] <sil2100> /usr/bin/ld: libgtest.a(gtest-all.o): undefined reference to symbol 'pthread_key_delete@@GLIBC_2.2.5'
[12:26] <sil2100> Yes
[12:30] <Laney> grr, silent rules!
[13:12] <seb128> Laney, how did you run the settings app on the device?
[13:24] <didrocks> sil2100: needing any packaging ack?
[13:33] <sil2100> didrocks: not yet, uno momentos
[13:37] <didrocks> tedg: hey! FYI, after some tests, there was still an issue with your panel-service + upstart branch, after talking to Laney, there is a solution that is merging right now (https://code.launchpad.net/~laney/unity/user-session-jobs/+merge/169771)
[13:38] <didrocks> tedg: basically, the issue was that unity event always stops when using gnome-session, so the event for starting unity-panel-service was never triggered
[13:39] <tedg> didrocks, Ah, cool!
[13:39] <tedg> didrocks, Great stuff!
[13:40] <didrocks> thanks Laney for providing an elegant solution :)
[13:40] <tedg> It should make debugging the indicator issues there *much* easier.
[13:40] <didrocks> and make it starting faster
[13:40] <didrocks> I can feel the difference, even on my beefy machine :)
[13:40] <tedg> Heh, great!
[13:40] <didrocks> stopping seems a little bit longer, but on startup, it feels like if unity was already started :)
[13:42] <tedg> didrocks, I think that's because not all of our stuff is responding to SIGTERM properly.
[13:42] <tedg> didrocks, So then upstart has to formally kill things after a 5 second timeout.
[13:43] <didrocks> tedg: I agree with you, we seem to timeout systematically
[13:43] <tedg> didrocks, I think we should look at some of the offenders, we have a SIGTERM handler in HUD that just shutsdown the mainloop gracefully, and it works with usptart well.
[13:43] <tedg> didrocks, Probably need to add that code around.
[13:44] <sil2100> didrocks: hmmm... still checking that, but the new package dependency of gir1.2-dbusmenu-glib-0.4 for raring is a bit fishy
[13:44] <didrocks> tedg: do you know if upstart has a way to tell "this is what timed out"
[13:44] <didrocks> at least to have a list
[13:45] <didrocks> sil2100: hum, didn't we decide to look at saucy first, making all possible publication and move on the SRU then?
[13:45] <sil2100> didrocks: since I checked all the obvious projects and the only place where the gir1.2-dbusmenu-glib-0.4 dependency was added was libdbusmenu, but for saucy
[13:45] <sil2100> didrocks: doing that too, was waiting for Apps to finish, I also re-ran Unity, will check the publications too
[13:46] <didrocks> ok :)
[13:46] <sil2100> didrocks: I'm just afraid that there might have been a stack publishing missing somewhere ;/
[13:46] <didrocks> sil2100: so let's ignore it
[13:46] <sil2100> FOr raring
[13:46] <tedg> didrocks, Hmm, not sure it has a way to see that.  It can give a reason that it was stopped, but I think the only cases now are pass/fail.  Perhaps we could add "timeout"
[13:46] <didrocks> sil2100: I wonder if it's not part of the "this used to work"
[13:46] <didrocks> (ignored by UTAH checks)
[13:46] <didrocks> and now otto really checks it
[13:47] <didrocks> tedg: yeah, that would be interesting for debugging
[13:47]  * didrocks proposes a shutchart :)
[13:49] <Laney> seb128: I installed and launched it from the terminal
[13:49] <Laney> don't know why it didn't appear in the app lens
[13:49] <seb128> Laney, do you know how to get an icon for it?
[13:50] <Laney> it has a desktop file
[13:50] <seb128> kenvandine, hey, do you know what would be needed for system settings to get an icon on ubuntu touch.
[13:50] <seb128> ?
[13:51] <Laney> didrocks: that was one of the issues ;-) The other one was that the condition for gnome-session was never fired so you never got it started on the desktop
[13:52] <didrocks> indeed :)
[13:53] <Laney> ooh, britney/autopkgtest is coming
[13:53] <Laney> so everyone will really have to make sure tests work ;-)
[13:54]  * mlankhorst still can't push xorg-integration-tests :(
[13:56] <mlankhorst> it won't compile until x1.14 lands
[13:58] <sil2100> didrocks: maybe... are you ready for some ACK's for publishing? ;)
[13:59] <didrocks> sil2100: I fully am!
[13:59] <kenvandine> just need to reference an icon that is installed
[14:00] <kenvandine> right now it is using one from a theme that isn't installed
[14:00] <kenvandine> seb128, ^^
[14:00] <sil2100> didrocks: platform: http://<IP_ADDRESS>:8080/view/cu2d/view/Head/view/Platform/job/cu2d-platform-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_qtubuntu_0.51daily13.06.17-0ubuntu1.diff/*view*/ <- but here I see a small problem with the changelog
[14:00] <sil2100> didrocks: as one entry is duplicated by Tim and Ken
[14:00] <didrocks> sil2100: it's not an issue, it means that both contributed to the branch that was merged
[14:00] <didrocks> (they did each one at least one commit)
[14:01] <sil2100> Awesome, then it's all ok in my eyes
[14:01] <didrocks> sil2100: fine for me as well, feel free to publish :)
[14:01] <seb128> kenvandine, ok, I will do a MR to fix that then ;-)
[14:03] <sil2100> didrocks: published, now sdk:
[14:03] <sil2100> http://<IP_ADDRESS>:8080/view/cu2d/view/Head/view/SDK/job/cu2d-sdk-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_dee-qt_3.0daily13.06.17-0ubuntu1.diff/*view*/
[14:03] <sil2100> (no deps, just packaging)
[14:04] <kenvandine> seb128, cool
[14:04] <didrocks> sil2100: good good! :)
[14:04] <Laney> seb128: kenvandine: I thought there was a touch icon theme?
[14:04] <Laney> Some of the panels in there don't have icons either
[14:05] <seb128> Laney, ubuntu-mobile-icons
[14:05] <seb128> Laney, but it's not complete
[14:05] <Laney> so the ones we chose are just what it will be?
[14:06] <seb128> you mean? the icon names? no, I tried to pick available icons as place  holders
[14:06] <seb128> we will need to update that once design provides the icons
[14:06] <didrocks> sil2100: on the indicator with binutils being pickier, this is fixed/merging or do we need help?
[14:07] <sil2100> didrocks: published, settings now: http://<IP_ADDRESS>:8080/view/cu2d/view/Head/view/Settings/job/cu2d-settings-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_ubuntu-system-settings_0.1daily13.06.17-0ubuntu1.diff/*view*/
[14:08] <sil2100> didrocks: I think it's not being worked on yet, but I guess I could quickly fix that
[14:09] <didrocks> sil2100: +1
[14:09] <didrocks> (we can notice seb128 writing commit message of 3 kms long :))
[14:09] <seb128> heh
[14:10]  * Laney approves of that!
[14:10] <seb128> I'm writing nice details for you to read ;-)
[14:10] <didrocks> seb128: that's kind of you :p
[14:10] <didrocks> seb128: "settings": is there anything else? it's the name of the panel?
[14:10] <didrocks> the settings panel of system settings?
[14:10] <sil2100> didrocks: cyphermox fixed the indicator-session thing, so it's getting merged now
[14:10] <didrocks> \o/
[14:11] <cyphermox> moo
[14:11] <didrocks> thanks cyphermox :)
[14:11] <sil2100> ;)
[14:11] <seb128> didrocks, no, it's the settings app itsel ... you can notice some are "about: ..." which is the about panel
[14:11] <cyphermox> didrocks: I was surprised Laney didn't beat me to it like for indicator-datetime :)
[14:11] <Laney> I got the wrong impression that those were all fixed
[14:11] <Laney> otherwise I would have ;P
[14:12] <cyphermox> Laney: ahah ;)
[14:12] <didrocks> cyphermox: oh, he did merge back his commit for it now?
[14:12] <didrocks> Laney: did you? ^
[14:12] <cyphermox> hmm, I should double-check
[14:12] <Laney> did I what?
[14:12] <Laney> oh hey, datetime is stuck in proposed
[14:12] <cyphermox> yup
[14:12] <Laney> oh, /that/
[14:12] <Laney> now I remember
[14:12] <didrocks> and it's not in trunk
[14:12] <cyphermox> yes, it's fine
[14:12] <didrocks> so the daily release is sad and complaining:
[14:12] <didrocks> A version (12.10.3daily13.06.07-0ubuntu2) is available at the destination for that component but is not in trunk which is still at 12.10.3daily13.06.07-0ubuntu2. Ignoring that component for source: indicator-datetime, branch: lp:indicator-datetime, series: saucy.
[14:12] <cyphermox> didrocks: sure it is?
[14:13] <Laney> I didn't do this to the archive
[14:13] <didrocks> interesting
[14:13] <Laney> I only touched trunk ;-)
[14:13] <cyphermox> oh, but UNRELEASED
[14:13] <didrocks> ah!
[14:13] <didrocks> so my system works \o/
[14:13] <cyphermox> yup
[14:13] <didrocks> hum, I thought sil2100 fixed it IIRC
[14:13] <didrocks> or maybe I'm misleading with something else?
[14:14] <sil2100> What what?
[14:14] <cyphermox> unmerged still
[14:14] <Laney> it should be fine if you can somehow tell it to ignore that
[14:14] <didrocks> sil2100: do you remember that you backported a commit?
[14:14] <didrocks> ah, unmerged :p
[14:14] <Laney> the one in saucy is effectively a no-change rebuild
[14:14] <cyphermox> sil2100: needs fixing: https://code.launchpad.net/~sil2100/indicator-datetime/include_direct_push/+merge/169255
[14:14] <didrocks> Laney: no, it's on my list of enhancement
[14:14] <didrocks> Laney: but yeah, would be cool
[14:14] <sil2100> uuuh
[14:14] <didrocks> I prefer to be too strict for now :)
[14:15] <sil2100> Ok, so libical-dev
[14:15] <didrocks> ah, it was that one :)
[14:15] <sil2100> It should work now
[14:15] <sil2100> I'll reapprove, as 1.0 is in ubuntu now
[14:15] <Laney> hrm, not sure I like calling it a bad idea
[14:15] <Laney> the FAQ says it's fine ;-)
[14:15] <didrocks> Laney: sorry, what about a bad idea?
[14:16] <Laney> "Include the missing version that got directly pushed to the distro... which is generally a bad idea. Someone pushed directly to distro and now we have to fix that."
[14:16] <Laney> on that MP ^
[14:16] <didrocks> Laney: I think the "bad idea" that sil2100 is telling is about not taking care of Vcs-Bzr :p
[14:17] <didrocks> (or at least asking)
[14:18] <sil2100> ;)
[14:18] <sil2100> Yep, it's generally a bad idea to workaround our daily-release machinery ;p
[14:18] <didrocks> sil2100: have you touch to the .project files for dbus-cpp and location-service?
[14:18] <sil2100> Without letting us know that is
[14:19] <didrocks> 2013-06-17 14:16:08,599 ERROR A manual upload of location-service (0.0.1daily<IP_ADDRESS>-0ubuntu1) to distro has been done after the current daily release was prepared (it was at 0) at this time.Ignore uploading 0.0.1daily13.06.17-0ubuntu1.
[14:19] <didrocks> 2013-06-17 14:16:12,870 ERROR A manual upload of dbus-cpp (0.0.1daily<IP_ADDRESS>-0ubuntu1) to distro has been done after the current daily release was prepared (it was at 0) at this time.Ignore uploading 0.0.1daily13.06.17-0ubuntu1.
[14:19] <sil2100> didrocks: hm, I don't think so
[14:19] <didrocks> ah no, that's normal
[14:20] <didrocks> as it wasn't in distro and we NEW them afterwards
[14:20] <didrocks> there has been an intermediate upload to distro for it
[14:20] <didrocks> that's why it ignored it
[14:20] <didrocks> sil2100: you didn't relaunch a build for them as we discussed this morning, right?
[14:26] <sil2100> didrocks: oh shit, hoho, dammit, I did not relaunch, I just published the platform stack
[14:26] <didrocks> sil2100: no worry, it's just creating a dummy commit upstream
[14:26] <didrocks> (with a revision from today)
[14:27] <didrocks> it will never surface to distro, just pollute upstream (well, low level pollution) :)
[14:27] <didrocks> sil2100: thanks for testing my protection code btw :p
[14:29] <sil2100> didrocks: in the meantime while your coffee is being made! apps stack: http://<IP_ADDRESS>:8080/view/cu2d/view/Head/view/Apps/job/cu2d-apps-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_gallery-app_0.0.67daily13.06.17-0ubuntu1.diff/*view*/
[14:30] <didrocks> sil2100: +1
[14:56] <sil2100> didrocks: heh, funny thing - I just wanted to add the missing gir1.2-dbusmenu-glib-0.4 to packages in raring, but it's there already!
[14:56] <sil2100> didrocks: just a redeploy was missing
[14:56] <sil2100> didrocks: can I redeploy?
[14:56] <didrocks> sil2100: sure sure, if the stack is not running
[15:03] <didrocks> sil2100: so, with all those publishing, it seems I didn't break the traditional "copy to distro" case, at least, right?
[15:07] <sil2100> didrocks: right, at least I see that gallery-app got uploaded properly, so it should work alright
[15:07] <didrocks> sil2100: ok, let's see what will happened once you publish the SRUs :)
[15:17] <sil2100> huh
[15:19] <sil2100> bleh...
[15:19] <sil2100> didrocks: in the meantime, media looking good:  http://<IP_ADDRESS>:8080/view/cu2d/view/Head/view/Media/job/cu2d-media-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_camera-app_2.9.1daily13.06.17-0ubuntu1.diff
[15:20] <didrocks> sil2100: sounds fine
[15:24] <sil2100> didrocks: btw. I checked wrongly and my indicator-datetime merge can't go in still, since libical-dev 1.0-0ubuntu1 is still in -proposed, not in saucy ;(
[15:25] <sil2100> s/go/get
[15:32] <jbicha> sil2100: ical won't migrate to saucy until after indicator-datetime is built with the new ical
[15:35] <sil2100> jbicha: that might be hard to do, as because of someone's direct push to the archive, indicator-datetime cannot be released before we get the changelog entry back into trunk manually, which is failing to merge - one solution would be to merge in directly without the merger, as the merger does not have -proposed enabled
[15:35] <sil2100> jbicha: but I'll merge it in manually then
[15:35] <sil2100> didrocks: you fine with that? ^
[15:36] <jbicha> like I said last week, I think you guys would have /less/ problems if you just built against -proposed than requiring manual overrides every time there is a transition
[15:36] <didrocks> sil2100: I'm fine with that
[16:03]  * Sweetsha1k improved the general build time of LibreOffice by 10% on all platforms at the Hackfest it seems ...
[16:40] <mlankhorst> it now takes 55 minutes instead of 50?
[16:42] <sarnold> lol
[16:54] <Sweetsha1k> mlankhorst: on Windows it now takes 89 minutes instead of 99 minutes on a i7-4470K with 16GB RAM. on big bertha it takes 2min10sec instead of 2min25sec to build from scratch ....
[17:09] <rickspencer3> kenvandine, hey, I think that maybe gallery -> facebook uploads broke?
[17:09] <rickspencer3> it seemed to not work for me over the weekend
[17:10] <kenvandine> rickspencer3, i haven't been able to test it on saucy yet
[17:10] <kenvandine> rickspencer3, i'll check it out today
[17:13]  * didrocks waves good evening
[17:17] <rickspencer3> thanks kenvandine
[17:17] <rickspencer3> kenvandine, is there anyway to automate it?
[17:17] <rickspencer3> I know that the web apps team have some automated tests to catch when web integration breaks
[17:20] <kenvandine> not without storing credentials in a public place
[17:20] <kenvandine> we do have autopilot tests for webcred
[17:20] <kenvandine> friends itself hasn't changed, i think there are problems with the webcred saucy stack on the device
[17:21] <kenvandine> works on the desktop fine
[17:21] <kenvandine> and i just got saucy flashed to my phone
[17:21] <kenvandine> so i'll test
[17:59] <kenvandine> rickspencer3, confirmed, sharing works with the version of signon-ui in saucy-proposed
[17:59] <kenvandine> we just need to get that published, blocked on the lack of powerpc build
[17:59] <rickspencer3> kenvandine, ok, I'll try it later this week ;)
[17:59] <rickspencer3> lack of powerpc build?
[17:59] <rickspencer3> er
[17:59]  * rickspencer3 shakes fist at PowerPC
[18:00] <kenvandine> yeah
[18:00] <kenvandine> it depends on qtdeclarative
[18:00] <kenvandine> which doesn't support ppc
[18:00] <kenvandine> so anything qml lacks ppc builds
[18:00] <kenvandine> and for signon-ui to work on the phone... we have to use the qtdeclarative
[18:01] <rickspencer3> hmmmm
[18:01] <kenvandine> rickspencer3, also of interest... i just added my facebook account with  ubuntu-system-settings
[18:01] <rickspencer3> I don't think we want to hold up all phone development for PPC
[18:01] <kenvandine> rickspencer3, indeed... it's been a real pain
[18:01] <rickspencer3> kenvandine, well, we should find a way to decouple it
[18:01] <kenvandine> yes
[18:02] <rickspencer3> aiui we only support PPC for the Xubuntu flavor community
[18:02] <kenvandine> we've been working on that everywhere we've hit this
[21:00] <Laney> so it seems that nautilus double signal handler disconnect wasn't the bug ;-)
[22:24] <xnox> Is there a ppa or something for me to try gtk 3.9+?
[22:26] <jbicha> xnox: ricotz/testing has a git snapshot; it's not been packaged elsewhere that I know of
[22:28] <xnox> jbicha thanks =)


[00:02] <bryceh> I'm going to update -ati to a newer snapshot; anyone know of any glaring issues in the -ati we have in -edgers currently?  Else I'll snag that snapshot for lucid.
[00:07] <ScislaC> bryceh: Does this have all of the info you need for a decent report? https://bugs.edge.launchpad.net/ubuntu/+source/xf86-input-wacom/+bug/511844 (I'm not asking you to fix my bug, I'm asking about the quality of the report)
[00:08] <ScislaC> wasn't expecting that, you guys think of everything :)
[00:13] <bryceh> ScislaC, maybe also syslog... like boot with it plugged in, capture that syslog to the bug report, then unplug it, note whatever new stuff shows in the log, then plug it in again, and get that as well
[00:13] <bryceh> ScislaC, this may be a general usb hotplug issue unrelated to X, it's probably a kernel issue, but the syslog output would (hopefully) be informative of what is going on
[00:14] <bryceh> another thing which might be of interest is to look at the output of lsusb for the three configurations as well
[00:14] <bryceh> in theory the first and third cases should have identical lsusb output
[00:15] <ScislaC> bryceh: wrt general hotplug, would a wireless usb mouse with a usb receiver suffice to test?
[00:16] <bryceh> I don't know, try it
[00:16] <ScislaC> I did and it has no issues on multiple plugs
[00:16] <bryceh> but from what I've seen the usb issues can be hardware-specific
[00:16] <ScislaC> ahhh
[00:16] <bryceh> e.g. I have a keyboard with a similar usb issue, but a usb mouse connected to the same port works fine
[00:16] <bryceh> and on another machine it's vice versa
[00:17] <bryceh> (and varies depending on what kernel I boot into)
[00:18] <ScislaC> bryceh: you're not giving me confidence that any amount of information I provide will help to make the bug report any more useful ;)
[00:23] <bryceh> ScislaC, it would only be false confidence I could supply in any case; my bet is it's not an X bug but rather a kernel issue
[00:24]  * ScislaC shakes his fist at the kernel
[00:26] <Sarvatt> regarding ati - none that I know of bryce, just alot of fixes people were having to use edgers to get and thats why I was recommending it.
[00:26] <bryceh> Sarvatt, great - know of particular bugs the xorg-edgers version solves?
[00:27] <Sarvatt> not LP bugs I'm afraid, lets see if any stand out :)
[00:28]  * bryceh looks too
[00:30] <ScislaC> bbiab... going to collect that syslog and lsusb info
 [22:16:55] might be a good time to update ati soon, quite alot of bug fixes in the past 2 months on master like signifigant speedups for r600 2D, low memory EXA fixes (and fixing NoAccel to work with KMS), a ton of dpms/incorrect resolution fixes, and a fix for a VT problem I've seen people having
[00:31] <Sarvatt> (some symptoms to help narrow it down)
[00:31] <bryceh> thanks
[00:37] <Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/494672
[00:37] <Sarvatt> fixed
[00:37] <Sarvatt> http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=3a30210d50b27f8772fc5045133940246764fce9
[00:38] <Sarvatt> possibly of course
[00:38] <bryceh> lp 333377 fixed too
[00:39] <bryceh> lp 487204 is fixed by mesa 7.7
[00:40] <bryceh> ditto 500607 I guess
[00:43] <RAOF> Argh.  I *always* miss xutils-dev when building nouveau orig.tar.gzs.  Where does it go?!
[00:45] <Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/511520  -- already fixed, exact same version that was in the archives :D
[00:45] <Sarvatt> what do you mean RAOF? I have 7.5+2 in edgers because we need the newer xorg macros
[00:46] <bryceh> 465958 -> heh, not an -ati bug, how'd that get here
[00:46] <bryceh> lp 465958 -> heh, not an -ati bug, how'd that get here
[00:46] <Sarvatt> oh it doesnt get added to your debian/control? I'm not sure, it works fine with auto-xorg-git
[00:47] <RAOF> Sarvatt: Building the nouveau original tarballs requires that I have xutils-dev installed, because I autoreconf to build the tarball.
[00:47] <RAOF> Sarvatt: And each time I go to do that it seems that xutils-dev has been uninstalled...
[00:47] <Sarvatt> oh you install it with apt-get build-dep and it gets autoremoved later? do you use aptitide/synaptic?
[00:48] <Sarvatt> do you get it installed via apt-get build-dep I mean
[00:48] <RAOF> I don't know.  It's possible that I just reinstall frequenly enough that I seem to always be missing xutils-dev :)
[00:49] <RAOF> Or maybe it's my multiple laptops.
[00:57] <Sarvatt> huh, this bug is confusing
[00:57] <Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/507000
[00:57] <Sarvatt> hes crashing with the kernel that enables KMS globally, but his logs show it trying to use XAA
[00:58] <Sarvatt> is there still a force XAA patch in the ubuntu -ati?
[00:59] <Sarvatt> he has no xorg.conf
[01:00] <Sarvatt> ahhh
[01:00] <Sarvatt> he got hit with the xserver trashing libdri/libglx.so during the alternatives switch a few weeks ago
[01:01] <bryceh> ah
[01:02] <bryceh> yeah close that bug and ask him to retest and reopen if it's still an issue
[01:02] <Sarvatt> doing that now
[01:02] <bryceh> hrm, I see my automatic xorg bug repackager has been a bit too aggressive at refiling bugs against -ati
[01:05] <ScislaC> bryceh: bug updated with that info, thank you for telling me what might be of use :)
[01:09] <bryceh> I bet lp 493057 is fixed from the r6xx performance improvements
[01:10] <Sarvatt> so many incorrect resolution in X bugs on ati that could possibly be fixed now
[01:11] <Sarvatt> dont think so Bryce, thats a x1600 and the huge 2D speed improvement was only R600
[01:11] <bryceh> ah right
[01:11] <Sarvatt> 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc M56P [Radeon Mobility X1600] [1002:71c5]
[01:11] <bryceh> x1600 is an R5xx
[01:18] <bryceh> Sarvatt, btw if you run into bug reports which you know have been fixed by upstream code (e.g. a fix is confirmed in xorg-edgers packages), then if you mark the bug report Fix Committed, that clues us for the changelog in when we update the package
[01:18] <bryceh> ok, uploading new -ati
[02:10] <Sarvatt> huh, your logs are confusing ScislaC, that XorgLog.gz shows hotplug working, that syslog looks fine too
[02:11] <ScislaC> Sarvatt: I know... that's why I'm especially confused...
[02:13] <Sarvatt> is that all over the same boot?
[02:13] <ScislaC> Sarvatt: given that I don't know how things work internally, is there anything in particular that would make the pen not work after the tablet is replugged? (I don't know if it ties the pen to a device id of sorts on first use)
[02:15] <ScislaC> Yep, I followed bryce's instruction on how to do it. Booted w/ tablet plugged in, captured syslog, unplugged, grabbed change from syslog, replugged, grabbed change from syslog again (I did attempt to use the pen on the three times, it worked for the first only)
[02:20] <Sarvatt> first time as in before you unplugged it the first time? because it looks like it loaded right on boot and the first unplug/replug at least
[02:21] <Sarvatt> maybe try rmmod wacom after you unplug before you plug it in again to see if its any different?
[02:24] <Sarvatt> it looks like the kernel sides working though, maybe watching what happens with sudo udevadm monitor might be interesting?
[02:24]  * Sarvatt isn't sure
[02:29] <Sarvatt> have you ever had that kind of issue with any other usb devices on that system?
[02:34] <Sarvatt> did you try plugging it in and such before the wacom driver got updated? curious if it was having the same problem with evdev
[02:36] <Sarvatt> i tried my 2 tablets on 4 systems now and hotplugging works fine multiple times on them all :(
[02:41] <RAOF> I'm scared and confused.  Why does my 2.6.32-10-generic initramfs have a nouveau kernel module?
[02:44] <Sarvatt> installed it with dkms ever? it installs to the latest 2 kernels
[02:44] <RAOF> Ah, I probably just hadn't rebuilt the initramfs after removing dkms.
[02:45] <RAOF> Man we pack the kitchen sink into our initramfs.
[02:45] <Sarvatt> especially now with plymouth!
[02:45] <Sarvatt> pango and such
[02:46] <RAOF> There are probably *some* kernel modules that don't end up in there... :)
[02:47] <Sarvatt> i dread anything calling update-initramfs because it takes a good 5-10 minutes here :D
[02:47] <johanbr> pango?! yikes...
[02:48] <johanbr> at least it's better after dpkg triggers were implemented
[02:48] <Sarvatt> i have it set to rebuild all every time
[02:48] <RAOF> And you've got every kernel since Warty installed?
[02:49] <Sarvatt> nah i build my own weekly and forget to remove them until it annoys me enough, removing just one takes forever
[02:50] <Sarvatt> rebuilds all initrd's twice and calls update-grub twice.. silly kernel-package hooks
[02:51] <RAOF> Gah.  Why does the nouveau DDX think l-b-m-n's kernel module doesn't have KMS enabled?
[02:51] <Sarvatt> stopped doing that though and am just living with having to remount my SD every resume, wish the ubuntu kernels had mmc unsafe resume enabled
[02:52] <Sarvatt> weird it should *only* have kms by now?
[02:52] <RAOF> Yes.
[02:52] <RAOF> Also, that's why X isn't starting; the UMS code just isn't there.
[02:53] <RAOF> It's mis-detecting KMS.
[02:53] <RAOF> At least I get a 210x65 console to debug from.
[02:54] <Sarvatt> did you build it against lucid's libdrm 2.4.17? i thought the ddx needed a post 2.4.17 update to even build anymore
[02:56] <Sarvatt> could something be screwy with the lbm-* module renaming?
[02:57] <RAOF> I built it against xorg-edgers 2.4.17+git20101020
[02:57] <RAOF> You're right, it does need to be built against > 2.4.17.
[02:57] <RAOF> I'm just checking how it checks for kms.
[02:58] <bryceh> ouch, it needs a git snapshot of libdrm?
[02:58] <bryceh> hope we can cherrypick what it needs
[02:59] <RAOF> I'd be surprised if we couldn't; I'm fairly sure it's just #defines in the nouveau headers again.
[03:00] <Sarvatt> cant cherrypick i dont think because it adds a new symbol
[03:01] <Sarvatt> well could and define that symbol in libdrm-nouveau1.shlibs I guess, i'm slow
[03:01] <RAOF> We've done that before.
[03:04] <Sarvatt> whats the error in Xorg.0.log? [drm] KMS not enabled?
[03:04] <ScislaC> Sarvatt: Yes, first time as in before it was unplugged. I've never had issues like this on this system, and it worked as expected in Karmic. I will try your suggestions after I eat. :)
[03:08] <Sarvatt> ahh i better get off the pc, wife wants to watch a few house episodes before we pass out :D will try the nouveau stuff out tomorrow, i'll try making NVPciProbe() always assume KMS is enabled and see if it works that way too
[03:12] <RAOF> I *think* the problem is that we've renamed the drm directory under /sys/stuff to lbm-drm.
[03:28] <RAOF> Well, dropping the KMS check makes everything work nicely.
[10:12] <tseliot> bryceh: are you around?
[14:18] <Cobalt> Hello. Does anyone know if Xorg Edgers has a IRC channel?
[14:20] <tseliot> you can ask here
[14:21] <tseliot> Cobalt: maybe ask Sarvatt and RAOF
[14:22] <Cobalt> tseliot: Thanks.
[14:26] <Cobalt> Sarvatt, RAOF: It's regarding a change made to the Intel Xorg driver after xserver-xorg-video-intel_2%3a2.9.1~git-0ubuntu0tormod_i386.deb. I noticed there's a bug filed for this on Launchpad: #502663. I'm having the exact same problem, with the latest packages (from 20100127). Is there any information I can supply that might help fix this issue?
[14:27] <Cobalt> That is, any package made after that one causes a crash, back to the log-in screen. It always crashes, but the amount of time it takes to do that varies.
[15:47] <Sarvatt> [drm:i915_gem_object_bind_to_gtt] *ERROR* Invalid object alignment requested 4096
[15:47] <Sarvatt> thats the error you get?
[15:47] <Sarvatt> I have gotten that at one point before but only on the 2.6.31 kernel, it didn't happen on the 2.6.32 kernel
[15:48] <Cobalt> Sarvatt: It is, I just wrote an entry in the bug report.
[15:49] <Sarvatt> can you try with a mainline kernel? I recommend <IP_ADDRESS> http://kernel.ubuntu.com/~kernel-ppa/mainline/v<IP_ADDRESS>/
[15:49] <Cobalt> I am on 2.6.31-18-generic. I ought to look into how to upgrade to .32, test that and report back.
[15:50] <Cobalt> Sarvatt: I'm going out right now, I'll do that when I get back.
[15:50] <Cobalt> How different is the mainline kernel from the -generic Ubuntu one, do you know?
[15:50] <Sarvatt> I have to run too, if you dont have any luck with it I'll see it in the irc logs though and come back when I can :)
[15:51] <Cobalt> Sarvatt: No worries, this is a lot better than no interaction at all. Thanks for the pointers.
[15:51] <Sarvatt> its basically the newest upstream kernel with the karmic kernel configuration
[15:51] <Sarvatt> upstream stable kernel that is
[15:57] <Cobalt> That's nice. I'm definitely getting it. Hope that solves some the nasty bluetooth pairing issues I've been having with my aluminium Mac keyboard at the same time.
[15:58] <Cobalt> It's downloading, I'll install and test after I get back. Laters. And thanks again.
[19:00] <ScislaC> Sarvatt: So, I did the couple of things you recommended last night (rmmod wacom & udevadm monitor), everything looked fine. I even tried a dummy test to have the tablet plugged in, NOT use the pen, and then on replug to test if the pen works... nope, it truly will only work on the first plug only.
[19:09] <bryceh> ScislaC, :-(
[19:12] <ScislaC> bryceh: Yeah... it is SO strange. As mentioned, with the X stuff from Karmic (because that is the one piece I held off on upgrading), it all worked as expected.
[19:13] <ScislaC> brb
[19:17] <ScislaC> yay for a newer ati driver :)
[19:28] <bryceh> ScislaC, did it solve any issues for you?
[19:35] <ScislaC> bryceh: the transition from plymouth to gdm looks less scary (before the whole screen was corrupted, this last start was only about 25% of it). I haven't done much more yet to know.
[19:35] <bryceh> ok
[19:36] <bryceh> ScislaC, if you post bugs about those issues, sub me to them and also include a photo
[19:37] <ScislaC> bryceh: ok... I will reboot in a bit with my camera available. There is also interruption of plymouth on shutdown that I don't know if it's known or expected right now.
[19:42] <tjaalton> ScislaC: try with a 2.6.33-rc package
[19:43] <tjaalton> it's likely something in the kernel drm driver, since it's using kms anyway
[19:43] <ScislaC> tjaalton: is there a ppa I should use?
[19:43] <tjaalton> ScislaC: http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.33-rc5/
[19:44] <ScislaC> brb :)
[19:44]  * bryceh waves to tjaalton
[19:45] <tjaalton> hi bryceh, nice nick :)
[19:59] <ScislaC> tjaalton: No plymouth at all with that kernel... also no wacom action either (I had to test)
[20:02] <tjaalton> ScislaC: you have to boot it with the kernel option to turn kms on
[20:02] <tjaalton> can't remember what it was
[20:05] <tjaalton> option radeon modeset=1
[20:06] <tjaalton> radeon.modeset=1 on the kernel cmdline
[20:06] <tjaalton> sauna ->
[20:45] <ScislaC> tjaalton: when you say kernel cmdline, would that be the line in grub?
[20:47] <ScislaC> well, that's what I'll try... brb
[20:58] <ScislaC> tjaalton: I had no plymouth on boot, but it showed up on shutdown.
[21:14] <tjaalton> ScislaC: do you have kms on boot, better vt's etc?
[21:14] <ScislaC> vt's?
[21:14] <tjaalton> virtual terminal
[21:14] <tjaalton> c-a-fN
[21:15] <ScislaC> I added radeon.modeset=1 in grub... I'm back in my 32 kernel at the moment (it seemed that video acceleration wasn't working for me in 33)
[21:15] <tjaalton> ok
[21:16] <ScislaC> I will test again in a bit to see about the vt's though
[21:57] <RAOF> bryceh: Oh, I do have something I'd like a pointer towards - how to make nouveau the first autoprobed driver in X.
[21:58] <tjaalton> see what the nvidia/fglrx patches do
[21:58] <tjaalton> though they are disabled
[21:58] <bryceh> right
[21:58] <RAOF> In the xorg-server package?
[21:58] <tjaalton> yes
[21:58] <bryceh> RAOF, yes
[21:58] <bryceh> basically there's a case statement that selects a driver by chip manufacturer id
[21:59] <bryceh> so look for the line with "nv" and change it to "nouveau"
[21:59] <RAOF> We're in a bit of a bind with the combination of nouveau (a) not being a part of the base kernel and (b) not working *at all* when its kernel module isn't available, so I think the best way to reliably get to X is to have it try to autoload nouveau, then fall back on nv (then VESA, or whatever).
[21:59] <tjaalton> rather put it above nv
[21:59] <bryceh> actually what we really want is to try "nouveau" first and then "nv" if it's unavailable
[21:59] <bryceh> however I'm not sure that fallback function will work
[22:00] <tjaalton> it works if nouveau fails to init
[22:00] <RAOF> I'll have a look & give it a try.
[22:00] <jcristau> does it only work if probe fails, or also if preinit fails?
[22:01] <tjaalton> at least when the driver doesn't support the chip
[22:02] <tjaalton> not sure what stage that is
[22:03] <RAOF> nouveau fails fairly early in the init when its kernel module is unavailable
[22:03] <RAOF> I can test it out & see.
[22:12] <RAOF> *After* I bisect the kernel to work out when suspending started to work again in 2.6.33
[22:15] <tjaalton> gimp crashes when wacom is unplugged, nice
[22:16] <tjaalton> on karmic though, don't know about lucid
[22:28] <Sarvatt> tjaalton: pretty sure thats fixed in xserver 1.7, i had the same issue all during karmic and it didnt happen with the early pre-1.7 releases
[22:39] <tjaalton> Sarvatt: ok, good
[22:46] <Cobalt> Sarvatt: Using the mainline kernel you gave me a link to fails to load proper ath5k modules, get no wifi, and hence can't test for the most usual test case and reproduce the crash (ie, opening pages in Firefox). As an aside, apparmor profiles also fail to load, and /proc/mount fails to mount as well.