[04:42] <pitti> Good morning
[04:43] <pitti> darkxst: hm, we use it in saucy's debian/patches/logind_support.patch; did you disable that patch?
[04:43] <pitti> darkxst: i. e. you have to drop this patch if you update to 3.8
[04:43] <darkxst> Pitti, nm, it started working again after a reboot
[04:45] <darkxst> pitti, this is 3.8, so dont have that patch
[04:45] <darkxst> pitti, http://paste.ubuntu.com/5876334/
[04:46] <pitti> darkxst: but that patch works in 3.6, so the lid inhibitor works
[04:46] <darkxst> yeh its working with above patch now
[04:49] <pitti> ah, good; the patch looks fine to me
[05:14] <pitti> RAOF: hey
[05:15] <pitti> RAOF: did you look at the colord autopkgtest failure?
[05:15] <RAOF> pitti: Yo!
[05:15] <RAOF> Oh, it fails even when the autopkgtest bug doesn't apply?
[05:15] <pitti> RAOF: that again uses that rather misdesigned (IMHO) parallel test runner which doesn't give you any information on failure :/ so might be useful to cat the log on non-zero exit
[05:15] <pitti> RAOF: yes, you should have gotten mail about it
[05:16] <pitti> https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-colord/
[05:16] <pitti> RAOF: it runs, but there is one failure
[05:16] <RAOF> Hm. I don't appear to have received any mail about that.
[05:17] <pitti> maybe it was already broken before we started that mail thing
[05:17] <pitti> it's been broken for quite a while indeed
[05:21] <RAOF> Oh man, that log output is entirely unhelpful, isn't it.
[05:23] <pitti> RAOF: yes, taht's what I meant with misdesigned parallel test runner
[05:37] <RAOF> pitti: Is the adt-run-tests bug that prevents me from testing the autopkgtests locally fixed yet?
[05:37] <pitti> RAOF: it's not, but you can run it with run-adt-test -sP colord
[05:37] <pitti> my run of that just finished
[05:38] <pitti> meh, there are debhelper logs from the package build, but no test suite logs?
[05:39] <pitti> so I guess one would need to run run-adt-test -skP colord and then login and run the tests manually
[05:40] <pitti> RAOF: running "make check" in the VM should work too, as the autopkgtest doesn't do anything different
[05:40] <chrisccoulson> good morning
[05:40] <pitti> hey chrisccoulson
[05:40] <chrisccoulson> hi, pitti, how are you?
[05:40] <RAOF> pitti: I was just going to check that my "cat log on failure" works :)
[05:40] <RAOF> chrisccoulson: Yo!
[05:40] <pitti> chrisccoulson: quite fine, thank you! we went climbing on the weekend, that was great
[05:41] <chrisccoulson> pitti, are you having nice weather at the moment as well?
[05:41] <chrisccoulson> hi RAOF!
[05:41] <pitti> chrisccoulson: yes, it's been splendid for two weeks now
[05:42] <chrisccoulson> pitti, yeah, it's been nice here as well for a change :)
[05:45] <chrisccoulson> the kids seem to like the nice weather too http://www.flickr.com/photos/67705534@N06/sets/72157634635880076/with/9281651263/ ;)
[05:48] <pitti> chrisccoulson: hah, who doesn't
[07:08] <jibel> good morning
[07:10] <didrocks> salut jibel, passé un bon week-end?
[07:11] <jibel> Salut didrocks,ça a été. Principalement plage et glaces et feux d'artifice le soir avec les enfants, et toi ?
[07:13] <didrocks> bien aussi, piscine du rhône et feu d'artifice le soir ;)
[07:13] <didrocks> ils viennent de refaire la piscine principale de Lyon (ouverture la semaine dernière):
[07:13] <didrocks> http://www.google.com/imgres?sa=X&biw=2078&bih=1104&tbm=isch&tbnid=9Zo7kdYfOvIj5M:&imgrefurl=http://www.lyon.fr/actualite/projets-urbains/la-metamorphose-de-la-piscine-du-rhone.html&docid=xP57nQViE_-o_M&imgurl=http://www.lyon.fr/cs/Satellite%253Fblobcol%253Durldata%2526blobkey%253Did%2526blobtable%253DMungoBlobs%2526blobwhere%253D5000005565171%2526ssbinary%253Dtrue&w=620&h=413&ei=9aDjUdHfJ4330gXh3IGYC
[07:13] <didrocks> Q&zoom=1&ved=1t:3588,r:1,s:0,i:83&iact=rc&page=1&tbnh=174&tbnw=257&start=0&ndsp=40&tx=96&ty=111
[07:13] <didrocks> hum, let me get an url shortner
[07:14] <didrocks> http://goo.gl/VUMMp and http://goo.gl/XJsAQ
[07:20] <jibel> nice
[07:39] <seb128> good morning desktopers
[07:40] <seb128> seems like this w.e was "upload manually stuff rather than wait for them to land through the system" days
[07:40] <didrocks> salut seb128!
[07:40] <seb128> didrocks, lut ;-)
[07:40] <didrocks> seb128: yeah, not sure what's the urgency was…
[07:40] <seb128> speaking of unity?
[07:41] <seb128> because ogra did one for powed as well, but he explaining in the changelog
[07:41] <seb128> unity, seems like it was breaking/blocking upgrades
[07:42] <darkxst> seb128, hi
[07:42] <seb128> darkxst, hey
[07:42] <darkxst> so I fixed the lid close actions, now need someone to test wacom panel
[07:43] <didrocks> seb128: interesting, they are doing transition over a week-end…
[07:44] <didrocks> seb128: I don't know why ogra_ didn't ping sil2100 to know why this important change wasn't daily release on Friday
[07:44] <didrocks> I think there are reasons like tests or failure to build…
[07:44] <didrocks> and then, using that apportunity to rant in the changelog "nice"
[07:44] <didrocks> ogra_: quite disappointed about your reaction TBH
[07:45] <seb128> what stack is powed in?
[07:45] <didrocks> as long as the changes were merged back upstream, it's fine anyway (as it seems it was)
[07:45] <didrocks> sil2100: hey, do you know why powerd wasn't released on Friday?
[07:46] <sil2100> didrocks: hi! hm, let me see, but I don't remember we had any stack red besides unity?
[07:46] <seb128> sil2100, indicator qa apps are atm
[07:46] <seb128> hud and webapps are yellow
[07:46] <seb128> where is powerd?
[07:47] <sil2100> It's in the platform stack, and i think it got published on Friday, but let me check
[07:47] <didrocks> platform, let's wait for sil2100's analysis
[07:47] <didrocks> but my bet is that the merge was after the daily (as Friday morning)
[07:47] <didrocks> nobody asked for a daily within the day
[07:47] <didrocks> and the following day, the publication was manual du to packaging changes
[07:47] <didrocks> ogra_: FYI ^
[07:47] <seb128> and next day was saturday
[07:47] <seb128> do we land on w.es?
[07:48] <didrocks> ogra_: the manual publication for packaging change is a requirement from the release team FYI
[07:48] <didrocks> seb128: did you read/received what I wrote?
[07:48] <seb128> didrocks, yeah, why?
[07:48] <sil2100> didrocks: seb128: the platform stack got normally released on Friday
[07:49] <sil2100> So maybe indeed the change got in later, after the daily release already
[07:49] <didrocks1> ok, let's see now
[07:49] <didrocks1> 09:48:30   didrocks | seb128: did you read/received what I wrote?
[07:49] <seb128> didrocks1, yes
[07:49]  * didrocks is lagging…
[07:49] <didrocks1> sil2100: yeah, that's what I wrote
[07:49] <didrocks> basically, it was merged after 00 UTC
[07:49] <didrocks> nobody reask for a daily
[07:49] <seb128> the commit was on 4:40UTC on friday
[07:50] <didrocks> and the day after, it was in manual publication
[07:50] <didrocks> because of packaging change
[07:50] <seb128> well, next day was saturday anyway
[07:50] <didrocks> and as told:
[07:50] <didrocks> 09:47:48   didrocks | ogra_: the manual publication for packaging change is a requirement from the release team FYI
[07:50] <sil2100> didrocks: btw. do we run daily-release on weekends? Since I see the publishing job got fired on Saturday, and it was manual publishing because of a packaging change
[07:50] <seb128> we don't land on w.es do we?
[07:50] <didrocks> sil2100: yes we do
[07:50] <didrocks> seb128: well, we run the stacks
[07:50] <seb128> but don't sync to the archive right?
[07:50] <didrocks> but we don't work on Saturday/Sunday to manual publish if needed
[07:50] <didrocks> if it publishes, it's getting synced to the archive
[07:51] <seb128> oh ok
[07:51] <seb128> I though we avoided landing stuff on w.e when nobody was around
[07:51] <didrocks> it's just packaging changes -> manual publication
[07:51] <didrocks> seb128: not the case anymore, on ogra_'s team request
[07:51] <seb128> right
[07:51] <seb128> makes sense
[07:51] <seb128> didrocks, thanks ;-)
[07:51] <ogra_> didrocks1, well ... i didnt ping anyone because a) nobody was around, b) could it be documented in the PPA description whom to ping (i wouldnt have known it is sil2100) c) i had simply assumed the fix would have been in after 16h and rolled a (then broken) image which we needed to fix urgently d) we have nop QA for the images atm so the broken image would have stayed on cdimage for the whole weekend
[07:51] <didrocks> but every worked as expected
[07:51] <didrocks> yw seb128 :)
[07:52] <didrocks> ogra_: daily release FAQ, I promoted that a lot, you should know the links now…
[07:52] <ogra_> oh ... and e) you explicitly said *several* times that emergency uploads would be no probelm
[07:52] <didrocks> ogra_: yeah, emergency uploads is not a problem. ranting on a changelog isn't a nice behavior IMHO though
[07:52] <ogra_> dunno what you see as a rant there
[07:52] <didrocks> ogra_: https://wiki.ubuntu.com/DailyRelease/FAQ#I_want_to_upload_a_change_to_a_package_under_daily_release_process
[07:53] <didrocks> again, everything is documented on who to ping, and so on…
[07:53] <sil2100> didrocks: I'll ping you with some packaging ACKs in a moment if you don't mind...
[07:53] <ogra_> great thanks ... and no i didnt see that page before
[07:53] <didrocks> sil2100: no worry
[07:54] <didrocks> ogra_: waow, you are maybe the only one, people are getting tired I reference the FAQ for everything :p
[07:54] <ogra_> anyway why wasnt the MP promoted after 30h ?
[07:54] <ogra_> any idea about that ?
[07:54] <didrocks> ogra_: did you read the scrollbar?
[07:54] <didrocks> scrollback?
[07:54]  * didrocks will repeat once again
[07:55] <didrocks> so, your changed was merged at 4am UTC on Friday
[07:55] <didrocks> so after 00 UTC
[07:55] <didrocks> so not on Friday dailies
[07:55] <didrocks> right?
[07:55] <didrocks> then, on Saturday, the change was picked, built, tested
[07:55] <didrocks> but it was set in manual publication mode
[07:55] <didrocks> because of packaging change
[07:55] <didrocks> which is a requirement from the release team
[07:55] <ogra_> sorry, but you are a day off
[07:56] <didrocks> (to not give packaging changes upload right to upstream)
[07:56] <didrocks> I'm not
[07:56] <ogra_> it was committed on thu
[07:56] <ogra_> before 00:00
[07:56] <ogra_> wasnt in on fri
[07:56] <didrocks> revno: 67 [merge]
[07:56] <seb128> ogra_, do we speak of http://bazaar.launchpad.net/~phablet-team/powerd/trunk/revision/67 ?
[07:56] <ogra_> which we noticed firday evening
[07:56] <didrocks> timestamp: Fri 2013-07-12 04:40:33 +0000
[07:56] <didrocks> on trunk
[07:56] <seb128>  Date: 2013-07-12 04:40:33 UTC
[07:56] <ogra_> didrocks, i approved it on thui evening
[07:56] <ogra_> and jenkins too
[07:56] <didrocks> ogra_: 00 UTC is trunk
[07:57] <didrocks> ogra_: daily release is only interested in trunk's state, I know nothing about the upstream merger
[07:57] <ogra_> well, so why was it not picked up by saturday then
[07:57] <didrocks> ogra_: do you read? :/
[07:57] <didrocks> it was
[07:57] <seb128> ogra_, did you change the mp status?
[07:57] <seb128> ogra_, or just comment approved?
[07:58] <didrocks> 9:55:28   didrocks | then, on Saturday, the change was picked, built, tested
[07:58] <didrocks> 9:55:39   didrocks | but it was set in manual publication mode
[07:58] <didrocks> 9:55:46   didrocks | because of packaging change
[07:58] <didrocks> 9:55:51   didrocks | which is a requirement from the release team
[07:58] <didrocks> 9:55:58      ogra_ | sorry, but you are a day off
[07:58] <seb128> ogra_, https://code.launchpad.net/~sforshee/powerd/fix-power-button/+merge/174203 says iicardo approved the mp on friday
[07:58] <didrocks> 9:56:02   didrocks | (to not give packaging changes upload right to upstream
[07:58] <didrocks> ogra_: it was picked on Saturday ^ blocked by distro rules though
[07:58] <ogra_> seb128, hmm
[07:58] <seb128> ogra_, seems like you misclicked to approve and ended up not approving it
[07:58] <seb128> then ricardo came and did it on friday
[07:58] <ogra_> seb128, i was pretty sure i did, since itz was breaking images for several days
[07:59] <seb128> well the mp is set as "Approved by: 	Ricardo Salveti on 2013-07-12 "
[07:59] <ogra_> yeah
[07:59] <didrocks> not what launchpad tells
[07:59] <ogra_> i guess LP doesnt lie
[07:59] <ogra_> funjily i have the page open here without relaod and the UI shows approved
[07:59] <didrocks> ogra_: maybe the previous build failed?
[08:00] <didrocks> as I see a jenkins run in the comments showing failures
[08:00] <ogra_> hmm, the commit was changed once
[08:00] <didrocks> and so in that case you have been reverted from approve -> needs review
[08:00] <ogra_> iirc
[08:01] <didrocks> maybe someone pushed and reverted then
[08:01] <didrocks> because IIRC, the upstream merger tells something about the rejecoitn
[08:01] <didrocks> like "not the approved commit is the latest"
[08:01] <ogra_> ok, that could be it then
[08:02] <didrocks> but so, nothing was stuck or behaving strangely apparently
[08:03] <Laney> morning!
[08:03] <didrocks> ogra_: I have nothing opposed that someone with upload rights like you can access and force the publication if needed
[08:04] <didrocks> ogra_: the only thing is that you will have to learn the jenkins' workflow (I would have prefer to have the dashboard worked on before so that you can get a better easier view)
[08:04] <ogra_> didrocks, anyway, the changelog entry wasnt a rant, please dont see it like that, asac asked me to document the issues we find with the process (it doenst say "didrocks is a sucker i upload manually because i dont like him" ... i just wanted to note down the time here and explain why i did a manual upload, dont feel attacked)
[08:04] <seb128> Laney, good morning, had a good w.e ?
[08:04] <didrocks> ogra_: ok, the "approved for 30h and …" was maybe misleading
[08:04] <ogra_> well, i didnt know it was re-approved
[08:05] <Laney> seb128: yes thank you, bit sun burned now though :P
[08:05] <seb128> hehe
[08:05] <didrocks> ogra_: so, just tell me if you want to spend some time knowing about the system, how it works, and so that we can give you access to jenkins publication
[08:05] <seb128> that's summer for you ;-)
[08:05] <Laney> you?
[08:05] <didrocks> hey Laney ;)
[08:06] <ogra_> didrocks, and after all i still think a possible 24h delay is to much and binding the trigger on people is wrong, i would propose some kind of trigger button on LP for fast-pathing singel packages if needed
[08:06] <seb128> Laney, I had an excellent w.e thanks, lot of sun and fireworks (yesterday was our national day, they had fireworks on saturday and sunday nights in the big cities next here)
[08:06] <Laney> great!
[08:06] <seb128> indeed ;-)
[08:07] <didrocks> ogra_: yeah, we already discussed that, I can only propose a button for daily release to upstream, with status and so on, I don't know about the upstream merger and launchpad side
[08:07] <ogra_> didrocks, there are way to often cases where we quickly need to fix the images now that we're supposed to always have them usable
[08:07] <didrocks> ogra_: daily release supports single component rebuild btw
[08:07] <seb128> ogra_, you can always manually upload and send a merge back for trunk
[08:07] <ogra_> waiting for the next daily is often to long in tehse cases
[08:08] <pitti> hey seb128
[08:08] <didrocks> and ask our team to have that managed (not on week-end though), as per the FAQ
[08:08] <ogra_> seb128, well thats what i did (even with documenting why) and now we have an angry didrocks and a discussion
[08:08] <pitti> bonjour didrocks
[08:08] <pitti> hello Laney
[08:08] <seb128> pitti, salut, ça va bien ?
[08:08] <didrocks> ogra_: I was more angry about the changelog that I saw as a rant TBH
[08:08] <didrocks> salut pitti!
[08:08] <ogra_> yeah, wasnt meant like that
[08:08] <Laney> morning pitti
[08:09] <pitti> seb128: oui ! nos avons eu un bon week-end avec escalader
[08:09] <didrocks> ogra_: otherwise, uploading and backporting to trunk is always possible
[08:09] <didrocks> (as you can see, since Sunday, the system for the platform stack is telling "nothing to do")
[08:09] <seb128> pitti, tu fais de l'escalade maintenant ?
[08:10] <pitti> seb128: oui, https://plus.google.com/107564545827215425270/posts/cieRV8axPSN
[08:10] <pitti> seb128: well, rope-climbing, not free-climbing
[08:11] <seb128> pitti, nice!
[08:12] <seb128> though  bit scary :p
[08:12] <Laney> nice!
[08:15] <pitti> seb128: nah, you are well-secured there
[08:17] <darkxst> pitti, via ferrata's?
[08:20] <pitti> darkxst: yes, indeed (that word was new to me)
[08:21] <sil2100> didrocks: can you check? http://10.97.0.1:8080/view/cu2d/view/Head/view/HUD/job/cu2d-hud-head-3.0publish/46/artifact/packaging_changes_hud_13.10.1+13.10.20130715-0ubuntu1.diff
[08:21] <didrocks> sil2100: +1 for me
[08:25] <sil2100> didrocks: and another one - I guess robru knows what he's doing ;p http://10.97.0.1:8080/view/cu2d/view/Head/view/WebApps/job/cu2d-webapp-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_webapps-applications_2.4.16+13.10.20130715-0ubuntu1.diff
[08:26] <darkxst> pitti, always want to try them, but probably might find them boring compared to real climbing!
[08:27] <didrocks> sil2100: hum, I'm a little bit unconvince it shouldn't be a conflicts insteads, but anyway, webapps, that's not that bad, so +1
[08:27] <pitti> darkxst: yeah, likely; but I don't do "real" climbing
[08:27] <didrocks> sil2100: can you ask him to use a versionned conflicts later on?
[08:27] <sil2100> didrocks: will do, let me note that down
[08:28] <didrocks> thx!
[08:30] <Laney> you probably want Replaces in that situation too
[08:30] <Laney> http://www.debian.org/doc/debian-policy/ch-relationships.html#s7.6.2
[08:32] <darkxst> pitti, you should try it someday, its pretty amazing, although probably a fair bit slower than your via ferrata adventures
[08:32] <sil2100> Thanks!
[08:32] <pitti> darkxst: I've done in-door bouldering quite a few times
[08:32] <Laney> trad leading is scary!
[08:33] <sil2100> hmmm, strange thing
[08:33] <darkxst> Laney, well that is all part of the game!
[08:33] <Laney> I know someone who looked down to find the last three or so pieces of gear had come out, just before he had to do a blind slap around a corner
[08:34] <Laney> got it fortunately :P
[08:34] <sil2100> I don't see any new glib2.0 pushed anywhere lately, and indicator-session FTBFS because of /usr/bin/gdbus-codegen: not found, which is provided by libglib2.0-dev
[08:35] <darkxst> Laney, I pretty sure that happens to everyone at some stage!
[08:35] <Laney> I stick with sport and bouldering :P
[08:37] <highvoltage> Does (or will) Unity 8 still use compiz?
[08:38] <seb128> sil2100, the issue is not that the binary is not found, it's "sh: 1 ... not found", which is the shebang, which is python
[08:38] <seb128> sil2100, you need to build-depends on python for gdbus-codegen
[08:38] <seb128> libglib-dev doesn't do it for you
[08:38] <darkxst> we are lucky to have Mt arapiles not far away (well 4 hours drive). its probably one of the best trad climbing spots in the world for lower grades (say in the 10-20 bracket)
[08:39] <sil2100> seb128: oh! Nice catch! ;) That makes sense indeed, thanks!
[08:39] <seb128> sil2100, yw
[08:40] <seb128> sil2100, btw you already did that in https://launchpad.net/ubuntu/+source/indicator-power/12.10.6+13.10.20130628-0ubuntu1
[08:40] <seb128> sil2100, so you should know about it ;-)
[08:41] <sil2100> seb128: completely forgot about that, and the error message again made me go the wrong way ;p
[08:43] <sil2100> https://code.launchpad.net/~sil2100/indicator-session/fix_gdbus-codegen_python_dep/+merge/174669
[08:44] <sil2100> seb128, didrocks: ^
[08:45] <didrocks> sil2100: approved, thanks!
[08:48] <sil2100> Thank you ;)
[08:53] <RAOF> highvoltage: No; it's currently using SurfaceFlinger, about to transition to Mir.
[09:01] <didrocks> interesting that vuds is just during feature freeze
[09:01] <didrocks> rickspencer3: hey, was that considered? ^
[09:02] <rickspencer3> didrocks, I don't know, I wasn't involved in setting that date
[09:02] <highvoltage> RAOF: cool, thanks
[09:04] <didrocks> sil2100: did you work on the QA stack? It seems to be a 3 minute-fix (wrong list of packages to install)
[09:04] <sil2100> didrocks: https://code.launchpad.net/~sil2100/cupstream2distro-config/qa_extra_package/+merge/174672 <- can you take a lookie? ;)
[09:04] <didrocks> ahah :)
[09:04] <sil2100> didrocks: ;D
[09:05] <didrocks> sil2100: approved, you can deploy and run please :)
[09:06] <didrocks> sil2100: on the apps stacks, it's the new qtwebkit which doesn't ship anymore private headers
[09:06] <didrocks> sil2100: before sponsoring, I asked Mirv if he checked that nothing was using them, he told me it was the case, wrongly it seems :/
[09:06] <sil2100> didrocks: ah, I poked oSoMoN about that
[09:06] <didrocks> sil2100: is he around? Is that normal that we are using private headers?
[09:07] <sil2100> didrocks: he didn't respond to my question on #ubuntu-touch, but I guess once he's online he should see it - I'll check what those are used for, but I would prefer him to check that too
[09:07] <seb128> didrocks, did they announce vUDS again without using the mailing lists?
[09:08] <didrocks> seb128: seems so, I read it on g+ (linked by a community better)
[09:08] <seb128> k
[09:08] <didrocks> sil2100: yeah, same here, keep me posted then, I won't reexpose them until we are sure they are really needed
[09:38] <mlankhorst> Laney: how do I try that failing sequence manually?
[09:49] <Laney> mlankhorst: don't know :(
[09:49] <Laney> I did `apt-get install --dry-run u-boot-linaro-omap4-panda u-boot-tools pvr-omap4 xserver-xorg-video-omap-revert xserver-xorg-input-evdev-omap-revert ubuntu-desktop' and it works here ...
[09:50] <Laney> that's the list of added packages from livecd-rootfs + ubuntu-desktop
[09:51] <Laney> mlankhorst: ah. wait....
[09:52] <Laney> mlankhorst: Stick a ^ on ubuntu-desktop
[09:52] <mlankhorst> what's that?
[09:52] <Laney> Task: ubuntu-desktop instead of the package ubuntu-desktop
[09:52] <mlankhorst> ah..
[09:54] <Laney> can you reproduce it?
[09:56] <Laney> yeah, works on shedir too
[10:09] <Laney> Just re-read that: works as in "reproducing the brokenness works", not "installing the packages works". Yay for non-confusing sentences.
[10:15] <mlankhorst> unsurprisingly..
[10:15] <mlankhorst> xserver-xorg-core is part of ubuntu-desktop task
[10:37] <sil2100> didrocks: could you take a look at 2 merges?
[10:37] <sil2100> https://code.launchpad.net/~sil2100/unity/merge_manual_versions/+merge/174718
[10:37] <sil2100> https://code.launchpad.net/~sil2100/unity-lens-applications/merge_in_manual_publish/+merge/174724
[10:39] <didrocks> sil2100: both approved
[10:39] <sil2100> \o\
[10:39] <sil2100> /o/
[10:40] <sil2100> Hope those are correct
[10:40] <mlankhorst> Laney: can I add something to make it not install certain packages?
[10:41] <Laney> mlankhorst: no idea
[10:45] <didrocks> sil2100: I checked the diff, they are, thanks!
[10:52] <mlankhorst> Laney: well that's the real problem, unless I somehow overwrite stuff :P
[10:53] <mlankhorst> have a replaces on xorg-server-core, evdev and omap
[10:53] <mlankhorst> but no conflicts
[10:54] <Laney> do you Provides: the packages?
[10:57] <mlankhorst> yeah
[10:57] <Laney> hmm
[10:57] <mlankhorst> but because ubuntu-desktop^ would pull in the real packages, I guess that's causing the issue
[10:57] <mlankhorst> how does the lts cd solve it?
[10:57] <Laney> I thought it might see that the package is already satisfied
[10:58] <Laney> dunno
[11:10] <Laney> mlankhorst: looks like it was seeded for precise
[11:10] <Laney> ogra_: any insights?
[11:10] <Laney> If you install pvr-omap4 first and then the task it's all OK
[11:11] <ogra_> i dont think we have a way to install anything earlier than other stuff
[11:11] <ogra_> at least not easily
[11:12] <Laney> is there a way to remove the normal xorg stuff that's pulled in by the task?
[11:12] <Laney> remove it from the list of packages being installed
[11:18] <mlankhorst> hm maybe if we remove the conflicts part
[11:18] <mlankhorst> but that will leave you with a broken desktop if you remove it
[11:18] <mlankhorst> ah well
[11:24] <mlankhorst> hm, has the nexus7 desktop kernel been removed in saucy?
[11:36] <mlankhorst> it's the only device I have that's touch capable
[11:40] <mlankhorst> tkamppeter_: can you test xorg-server in saucy from https://launchpad.net/~canonical-x/+archive/x-staging?field.series_filter=saucy ? (building atm)
[11:42] <mlankhorst> that package should fix a touch bug I was hitting on my nexus7, but it probably won't fix all touch bugs remaining..
[11:48] <mlankhorst> oh and when I'm trying it I get WARNING: can not find package 'ubuntu-desktop^' in cache, ignoring
[11:48] <mlankhorst> Laney: ^
[11:48] <Laney> 'it'?
[11:49] <mlankhorst> that line
[11:49] <Laney> so you don't reproduce?
[11:49] <mlankhorst> I guess the schroot thing doesn't work like a real apt-get..
[11:50] <Laney> (saucy-armhf)laney@shedir:~$ apt-get install --dry-run u-boot-linaro-omap4-panda u-boot-tools pvr-omap4 xserver-xorg-video-omap-revert xserver-xorg-input-evdev-omap-revert ubuntu-desktop^
[11:50] <Laney> […
[11:50] <Laney> Note, selecting 'xserver-xorg' for task 'ubuntu-desktop'
[11:50] <Laney> etc
[11:54] <mlankhorst> Laney: what if you add xserver-xorg-core-omap-revert to that line?
[11:54] <Laney> still broken of course
[11:54] <Laney> that's already pulled in by deps of pvr-omap4
[11:54] <mlankhorst> tried? :P
[11:55] <Laney> yes
[11:55] <Laney>  xserver-xorg-core-omap-revert : Conflicts: xserver-xorg-core
[11:56] <mlankhorst> hm, can I reset the schroot?
[11:56] <Laney> mlankhorst: ah, the can not find thing comes from the weird restricted apt they have there
[11:56] <Laney> do it with --dry-run without sudo
[11:56] <mlankhorst> ah..
[11:57] <Laney> or make a chroot on your nexus
[11:58] <mlankhorst> I want to reset my schroot :S
[11:58] <Laney> don't know what that means
[12:02] <mlankhorst> my chroot is a pigs mest and I want to hide the evidence it ever existed :)
[12:07] <Laney> mlankhorst: remove the bad packages
[12:07] <Laney> Also those chroots porter are shared ;-)
[12:07] <Laney> mlankhorst: Also, for checking this stuff locally it's enough to use chdist to set up a fake apt configuration that uses armhf
[12:08] <Laney> chdist --arch=armhf create saucy-armhf http://ports.ubuntu.com saucy "main universe restricted multiverse"
[12:09] <Laney> then chdist apt-get saucy-armhf update; chdist apt-get saucy-armhf --dry-run install pvr-omap4 ubuntu-desktop^
[12:29] <mdeslaur> seb128: if unity no longer properly handles desktop files with an absolute path for an icon, do I file a bug against unity, or would it be bamf?
[12:29] <seb128> mdeslaur, hey! not sure but I would guess bamf, check with Trevinho he knows for sure
[12:29] <mdeslaur> seb128: thanks
[12:29] <mdeslaur> Trevinho: ^ ?
[12:30] <Trevinho> mdeslaur yes...
[12:30]  * Trevinho reading
[12:32] <Trevinho> mdeslaur: it could be a Bamf issue, but it seems unlikely...
[12:32] <Trevinho> mdeslaur: I need to check
[12:32] <mdeslaur> Trevinho: ok, can I file a bug against bamf and you can reassign it if it turns out that's not it?
[12:32] <mlankhorst> Laney: ah..
[12:33] <Trevinho> mdeslaur: the side effect is just the ? Icon
[12:33] <mdeslaur> Trevinho: yes
[12:33] <mdeslaur> Trevinho: for instance, you can install "pasaffe" and start it, and notice that the icon in the launcher is the ? one
[12:33] <mdeslaur> or xdiagnose
[12:34] <Trevinho> mdeslaur: I can't check it now, but you can easily debug it using d-feet and see what contains the icon property for that app...
[12:34] <Trevinho> mdeslaur: is this a regression btw?
[12:34] <mdeslaur> Trevinho: yep, worked fine in raring
[12:36] <Trevinho> mdeslaur: I see... There have been both unity and Bamf changes in that codepath so could be both... I'll check that soon, please file a bug with both components for now...
[12:38] <mdeslaur> Trevinho: thanks. LP: #1201408
[12:38] <ubot2`> Launchpad bug 1201408 in unity (Ubuntu) "No longer handles absolute path icons" [Undecided,New] https://launchpad.net/bugs/1201408
[12:38] <Trevinho> mdeslaur: thank you
[12:39] <mdeslaur> Trevinho: thanks!
[12:40] <mlankhorst> Laney: meh, I guess I'll have to remove the conflicts and leave a broken desktop when any of the omap-revert packages are removed..
[12:41] <Laney> That'll let both x stacks be installed at the same time?
[12:42] <mlankhorst> yeah but it causes the omap-revert packages to overwrite the normal files, and on remove of the omap-revert the normal files stay gone
[12:42] <mlankhorst> until you manually reinstall
[12:42] <mlankhorst> but it doesn't look like there's a better way
[12:44] <mlankhorst> I'll try it in a ppa
[13:09]  * sil2100 is doing lunch, but...
[13:09] <sil2100> didrocks: https://code.launchpad.net/~sil2100/cupstream2distro-config/add_apps_tests_to_sdk/+merge/174733 whaddayathink?
[13:15] <didrocks> sil2100: sounds like a good range of tests to me
[13:15] <didrocks> sil2100: did you try deploying + running first? (to ensure the list is correct)
[13:15] <seb128> didrocks, sil2100: can you retry https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/4795420 just to see if the error is transient
[13:16] <didrocks> seb128: we got it twice IIRC, but retrying
[13:16]  * seb128 wishes we would have a ppc porter box
[13:16] <mlankhorst> hm i should have used the x-staging ppa for the test build, would have been faster than emulated armhf builds
[13:22] <desrt> good morning, freedom fighters!!
[13:22] <didrocks> good morning desrt!
[13:22] <sil2100> didrocks: I did a manual test run on the AP-job
[13:23] <sil2100> Didn't redeploy, just put the parameters manually ;)
[13:23] <seb128> desrt, hey
[13:23] <didrocks> sil2100: excellent! approving then m:)
[13:23] <desrt> how goes the war?
[13:23] <sil2100> seb128: I already re-ran this build twice
[13:23] <sil2100> seb128: the failure happened once again on the second run, but let's see how this one goes
[13:23] <didrocks> sil2100: oh, no in fact
[13:23] <didrocks> sil2100: you shouldn't list apps packages
[13:23] <didrocks> (apart from the autopilot ones)
[13:24] <sil2100> Ah, could be the same error I made some time ago?!
[13:24] <didrocks> sil2100: we want to ensure it's backward compatible and working with older versions
[13:24] <didrocks> so don't change packages:
[13:24] <didrocks> for testpackages:
[13:24] <didrocks> share-app notes-app webbrowser-app gallery-app
[13:24] <didrocks> -> shold be -autopilot
[13:24] <didrocks> for each of those :p
[13:25] <sil2100> hmm, but are those Apps installed on the images by default?
[13:25] <sil2100> Ah, the testpackages: will pull in all the deps?
[13:29] <didrocks> seb128: failed again
[13:29] <didrocks> sil2100: ah good point, yeah, they are not installed
[13:29] <didrocks> sil2100: but if you install the -autopilot ones
[13:29] <didrocks> they will be pull as deps
[13:29] <didrocks> (no strict check needed)
[13:29] <seb128> didrocks, yeah, I noticed, I'm asking around if there is a ppc box we can access to debug
[13:30] <didrocks> ok ;)
[13:30] <seb128> didrocks, otherwise what about breaking ppc a bit more and publishing even if it's broken there? ;-)
[13:31] <didrocks> seb128: it won't migrate from proposed to the release pocket
[13:32] <seb128> that's a good point :/
[13:32] <didrocks> seb128: remember, that's not the dailies blocking us :p
[13:33] <didrocks> TBH, you can maybe remove powerpc from arch:
[13:33] <didrocks> if we don't have any rdepends
[13:33] <seb128> didrocks, well, I would rather make it not fail on failing tests for ppc
[13:33] <didrocks> seb128: I was just giving a fix along the solution you were heading for :p
[13:33] <seb128> ;-)
[13:34] <seb128> infinity is helping charles to get access to a ppc box
[13:34] <mlankhorst> weird, I'm not getting anything displayed correctly after I upgraded my nexus7 to saucy
[13:34] <seb128> let's see if we can get the test to pass first
[13:34] <didrocks> ok, let's cross fingers :)
[13:37] <infinity> seb128: Given that things failing on one arch usually point to bad C, I'd certainly prefer looking for a fix first, but yeah, disabling tests (or the arch entirely) are other options.
[13:38] <seb128> infinity, right, it's just that not having access to the hardware limits the debugging ... thanks for helping there ;-)
[13:52] <sil2100> didrocks: updated the MR!
[13:53] <didrocks> sil2100: approved!
[13:56] <Sweetshark> youtube is down with a error 500.
[13:56] <Sweetshark> "Sorry, something went wrong. A team of highly trained monkeys has been dispatched to deal with this situation. If you see them, show them this information: <some base64 encoded token>"
[14:11] <happyaron> jasoncwarner_: ping
[14:50] <kenvandine> larsu, have you had a chance to try to figure out that lmm issue on phablet?
[15:23] <seb128> didrocks, is the problem with ppa builds and translation import still on your list? I just refresh a bunch of templates for indicators and lenses manually to fix some of the current saucy issues but we should really fix the infra this cycle...
[15:24] <didrocks> seb128: well, it's on my list to discuss with pitti
[15:24] <didrocks> seb128: but OTOH "ENOTIME"
[15:24] <didrocks> too many demands, I have already stuff for late in the week :/
[15:24] <seb128> it's going to bite us
[15:24] <didrocks> seb128: want to help there? :)
[15:24] <seb128> right, no worry/hurry
[15:24] <seb128> didrocks, I've been doing manual uploads, that's helping in my book :p
[15:25] <didrocks> seb128: also, I have to start the settings thing
[15:25] <didrocks> seb128: well, I think we should just talk with pitti about it
[15:25] <didrocks> and see what can be done
[15:25] <didrocks> I think the fix isn't really on the daily release side
[15:25] <pitti> didrocks: (in hangout ATM)
[15:25] <didrocks> or it will be hackish
[15:26] <seb128> didrocks, but sure, I can try driving discussion forward
[15:26] <seb128> I'm just unsure if that's a lp/infra/cu2d issue
[15:26] <seb128> didrocks, ok, I'm going to see what I can do, thanks
[15:26] <seb128> pitti, hey! ;-)
[15:26] <seb128> pitti, (no hurry, tomorrow works as well)
[15:27] <seb128> pitti, it's about importing translations/templates from the daily builds infrastructure, we still don't do that which means we have outdated templates/translations for everything under daily landing
[15:32] <pitti> seb128: not directly related, but FYI: wgrant enabled saucy LP exports today, so this week we can hopefully build some saucy langpacks
[15:33] <seb128> pitti, great!
[15:34] <pitti> seb128, didrocks: please remind me, do these actually build on the distro builders? (I think so)
[15:34] <seb128> pitti, yes
[15:34] <seb128> pitti, we do direct copies to the archive, including the binaries
[15:34] <didrocks> pitti: yes, they do
[15:34] <seb128> pitti, that wouldn't be an option if we were not using the archive builders
[15:34] <pitti> didrocks: do you happen to have a link to some build which has translations?
[15:35] <pitti> seb128: right, I figured so; just wanted to confirm
[15:35] <didrocks> seb128 has the ones he uploaded manually I think :) (I bet the scopes?)
[15:35] <seb128> didrocks, let me answer pitti's questions
[15:35] <seb128> didrocks, scopes and some indicators
[15:35] <seb128> pitti, well, just pick builds in https://launchpad.net/~ubuntu-unity/+archive/daily-build
[15:36] <pitti> seb128: hm, so e. g. https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/4788475 doesn't build a translation tarball
[15:36]  * pitti looks
[15:37] <pitti> so pkgstriptranslations is installed, but doesn't want to strip; presumably because it's "Purpose: PPA"
[15:37] <seb128> pitti, https://launchpadlibrarian.net/143969180/buildlog_ubuntu-saucy-i386.unity-lens-applications_7.0.0%2B13.10.20130702-0ubuntu1_UPLOADING.txt.gz
[15:37] <seb128> pitti,
[15:38] <seb128>  6f5c028c7d70b5f4123c53f7a6b97492772aa71f 2882 unity-lens-applications_7.0.0+13.10.20130702-0ubuntu1_i386_translations.tar.gz
[15:38] <seb128> the .changes has the tarball there?
[15:38] <seb128> that's https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/4763305
[15:38] <pitti> ah, then maybe gallery-app is special
[15:38] <seb128> pitti, ^ that one is an example of one of the default lenses
[15:38] <seb128> the gallery-app is in universe anyway
[15:39] <pitti> unity-lens-applications_7.0.0+13.10.20130702-0ubuntu1_i386_translations.tar.gz
[15:39] <pitti> purrfect
[15:39] <pitti> so we actually do build them already, so they are not lost
[15:39] <pitti> seb128: so it seems I just need to extend langpack-o-matic to also fetch tarballs from that PPA archive in addition
[15:46] <seb128> pitti, do you want a bug report to track that?
[15:47] <pitti> seb128: please (still in meeting)
[15:47] <pitti> seb128: against the langpack-o-matic project
[15:47] <pitti> with above links
[15:50] <pitti> darn, PPAs don't have a getPackageUploads(), I need to discuss that with SteveK/wgrant
[15:55] <czajkowski> pitti: talk/give them lots of cake :)
[15:57] <pitti> czajkowski: ah, cake is the new beer?
[15:58] <czajkowski> Cake is always better than beer, only thing better is cake and beer :)
[15:58] <czajkowski> but lets not go over board :)
[16:00] <jbicha> seb128: hey, do you want me to go ahead and upload the ibus stuff to the desktop ppa?
[16:02] <seb128> jbicha, hey, if you are happy with it sure
[16:03] <seb128> jbicha, I was going to have a look today or tomorrow but the day has been pretty busy again
[16:08] <seb128> pitti, https://bugs.launchpad.net/langpack-o-matic/+bug/1201485
[16:08] <ubot2`> Ubuntu bug 1201485 in langpack-o-matic "Need to import translations for the unity daily builds" [Undecided,New]
[16:10] <jbicha> seb128: do you want me to use the lp:~ubuntu-desktop branches for the ibus-enabled g-c-c and g-s-d or something else for now?
[16:11] <seb128> jbicha, we are moving forward with those uploads so using the official vcs seems fine
[16:11] <jbicha> ok
[16:11] <seb128> jbicha, do you plan to merge attente's work?
[16:11] <seb128> jbicha, e.g don't redo it
[16:11] <seb128> g-s-d should be mostly dropping the revert
[16:11] <seb128> g-c-c has some extra work
[16:14] <jbicha> seb128: yes I'm merging his stuff, I think I'll redo the ibus one though to rebase against Debian experimental now that they're looking at ibus 1.5 again
[16:15] <seb128> jbicha, works for me
[16:26] <sil2100> didrocks: who from the SRU team usually takes care of Unity SRUs?
[16:26] <didrocks> sil2100: nobody in particular, just have to poke them individually
[16:26] <didrocks> sil2100: did you see my MP btw?
[16:27] <sil2100> didrocks: hm, backtracking but can't find it - did you ping it to me directly?
[16:27] <didrocks> yeah
[16:27] <didrocks> on #ubuntu-touch
[16:28] <didrocks> sil2100: https://code.launchpad.net/~didrocks/address-book-app/small-fixes/+merge/174812
[16:30] <sil2100> didrocks: approved! :)
[16:30] <didrocks> sil2100: thanks!
[16:30] <sil2100> Sorry for missing that!
[16:33] <didrocks> no worry!
[16:33] <didrocks> sil2100: can you look at other non daily releasing components?
[16:33] <didrocks> sil2100: I just finish unity-action-api
[16:33] <didrocks> let me enable that
[16:36] <sil2100> didrocks: I'll just wait for the unity merge to finish...
[16:36] <didrocks> sil2100: hum, what's linked to that? why do we have to wait for it to finigh? (I'm talking about the components that daily_release: False)
[16:37] <didrocks> sil2100: and please, my other cupstream2distro-config merge when you have time :p
[16:38] <didrocks> (still on #ubuntu-touch if you missed it)
[16:38] <sil2100> didrocks: yes yes, sooo - unity-action-api is ready already? Since I was informed that timp was to do something still
[16:38] <didrocks> sil2100: hum, it's wellark working on it
[16:39] <didrocks> sil2100: and he pinged me, a lot of time was taken for the soname and so on
[16:39] <didrocks> did a bunch of changes
[16:39] <didrocks> but should be fine now (the latest branch is merging)
[16:39] <sil2100> didrocks: I poked him last week and he said that I was to wait till this week for timp to integrate it to UITK or something
[16:39] <sil2100> But if he pinged you, this means it's all ok
[16:40] <sil2100> My notes said: "wait till next week, timp is working on integrating it to UITK"
[16:40] <didrocks> ok, apparently, it's ready
[16:40] <sil2100> Ok, I'll take care of the ted-related branches, like ubuntu-geoip, unity-greeter-session-broadcast and url-dispatcher - I already made packaging reviews for those
[16:41] <didrocks> great :)
[16:41] <sil2100> I just need to check if tests are there and/or they are needed ;p
[19:15] <dobey> what's the best way to get the architecutre in debian/rules with pure dh, to use in an if statement?
[19:16] <dobey> oops
[19:47] <asac> dobey: dh? dpkg-* not valid?
[19:47] <asac> guess thats rather oops :)
[19:47] <asac> and you didnt want to ask
[19:48] <Laney> There's something you can include
[19:48] <Laney> /usr/share/dpkg/architecture.mk
[19:52] <dobey> asac: slangasek answered in -devel (oops was becuase i meant to ask there); was hoping for a standard variable to use, but apparently it's not always set so setting it with dpkg-architecutre output is preferred
[19:52] <asac> kk
[19:52] <dobey> thanks though :)