[00:51] <uvirtbot`> New bug: #423856 in ec2-init "[FFE] ec2-init should check for image upgrades" [Wishlist,In progress] https://launchpad.net/bugs/423856
[08:00] <uvirtbot`> New bug: #407935 in ubuntu-on-ec2 "ec2-init: init.d startup script list invalid options" [Low,Confirmed] https://launchpad.net/bugs/407935


[13:27] <bluesabre> knome: The test cases are now updated (and newer ones available).  Want to review them?
[19:39] <knome> bluesabre, sure, i'll do that later today
[19:40] <knome> Noskcaj, can you explain what is the reason you forwarded the mail from the lubuntu-devel list to xubuntu-devel? i'm unsure what the problem is
[19:43] <Noskcaj> knome, no real problem, just some stuff to learn from, and trying to help cross-team work
[19:44] <knome> Noskcaj, in that case i'm unaware what the awesome thing is to learn?
[19:44] <Noskcaj> i have no idea
[19:45] <knome> that makes no sense
[19:45] <knome> you send a message to our list that we could learn from others, but you don't know what?


[02:19] <[reed]> sebner++
[12:22] <gnomefreak> it is confirmed i hate doctors and computers
[12:25] <gnomefreak> crimsun: libasound2-plugins needs to be built, i did stupid distupgrade without looking and it removed ubuntu-desktop and pulseaudio and its not fixable atm
[12:27] <gnomefreak> asac: anyway to tell what emails thunderbird supports? i found it doesnt support lavabit nor gmx
[12:27] <gnomefreak> both are outgoing issues (doesnt send under its email address it uses my default email to send)
[12:38] <gnomefreak> bug 405951
[12:38] <gnomefreak> debian 405951
[12:44] <gnomefreak> where the hell is apearence
[12:47] <gnomefreak> oops forgot ie was seamonkey
[12:56] <gnomefreak> im getting other peoples mail :(
[12:58] <asac> hi
[12:58] <fta> hi
[12:59] <gnomefreak> hi
[12:59] <asac> i have the feeling that holidays are more exhausting than working ;)
[12:59] <directhex> lies. i'm on holiday!
[12:59] <asac> yeah ;)
[13:00] <asac> its just that when i open my screen that i have pings on all channels ;)
[13:01] <gnomefreak> what the hell is PLD Linux?
[13:05] <gnomefreak> how is kde support going with Mozilla?>
[13:06] <asac> gnomefreak: i think 3.1 has qt support ... i doubt that this is really supported yet
[13:06] <gnomefreak> bug 266946 is most likely caused by no QT support, as i recall this was fixed by moving ubufox but still has gtk apps being installed and they think its bloat (it kind of is)
[13:08] <asac> gnomefreak: the prob is apturl ... which isnt supported with kde packages only atm
[13:09] <gnomefreak> oh
[13:12] <gnomefreak> ok added apturl task :)
[13:12] <gnomefreak> asac: thnaks
[13:15] <fta> Bug 226425
[13:15] <fta> Bug 296185
[13:17] <gnomefreak> !info winbind intrepid
[13:18] <gnomefreak> ok winbind is samba :(
[13:29] <gnomefreak> asac: we never updated lang packs for hardy 3.0.x build of firefox. see bug 295873
[13:47] <gnomefreak> anyone know how to redirect a wiki to another one
[13:59] <fta> strange, the rss feature in ff3.1 is broken here
[14:00] <fta> i get tons of Error: uncaught exception: [Exception... "Component returned failure code: 0x80004002 (NS_NOINTERFACE) [nsISupports.QueryInterface]"  nsresult: "0x80004002 (NS_NOINTERFACE)"  location: "native frame :: <unknown filename> :: <TOP_LEVEL> :: line 0"  data: no]
[14:01]  * gnomefreak just built an addon for that a couple of months ago i think, still waiting for it to be pushed
[14:02] <gnomefreak> it works here in 3.0. if 3.1 gets into archive ill fix it for 3.1 same with all the other plugins i have
[14:03] <gnomefreak> asac: all my extensions are ready except firegpg but ill be looking at that this week depends on how my day goes
[14:04] <gnomefreak> dont update bzr in jaunty if you use bzr-builddeb
[14:06] <fta> works fine here
[14:07] <gnomefreak> upgrading bzr removed bzrtools and bzr-builddeb
[14:07] <gnomefreak> The following packages will be REMOVED: bzr-builddeb bzrtools
[14:07] <fta>        bzr |    1.6.1-1 | http://archive.ubuntu.com jaunty/main Packages
[14:07] <fta> bzr-builddeb | 2.0.2~0ubuntu2 | http://archive.ubuntu.com jaunty/universe Packages
[14:08] <gnomefreak> bzr:
[14:08] <gnomefreak>   Installed: 1.6.1-1
[14:08] <gnomefreak> bzr-builddeb: Installed: 2.0.2~0ubuntu2
[14:08] <gnomefreak> thats odd
[14:09] <gnomefreak> using upgrade holds back bzr dist-upgrade removes bzr-builddeb and bzrtools
[14:09] <gnomefreak> but bzr-builddeb doesnt have a Candidate nor does bzr
[14:10] <gnomefreak> so its up to date AFAICT
[14:10] <gnomefreak> thats weird
[14:11] <gnomefreak> trying upgrade again
[14:11] <fta>        bzr |      1.9-1 | http://archive.ubuntu.com jaunty/main Packages
[14:12] <fta> Package: bzrtools
[14:12] <fta> Depends: python (>= 2.4), python-central (>= 0.6.7), bzr (>= 1.6~), bzr (<< 1.7~), patch
[14:12] <fta> that's why
[14:12] <fta> gnomefreak, just wait for the new bzrtools
[14:13] <gnomefreak> ah but still would have thought a canadate would have been listed
[14:13] <asac> gnomefreak: the langpack bug should be void
[14:13] <gnomefreak> asac: why we dont backport them?
[14:13] <fta> Error: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIINIParserFactory.createINIParser]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: file:///usr/lib/xulrunner-1.9.1b2pre/components/nsUpdateService.js :: getLocale :: line 524"  data: no]
[14:13] <fta> Source File: file:///usr/lib/xulrunner-1.9.1b2pre/components/nsUpdateService.js
[14:13] <fta> Line: 524
[14:14] <asac> gnomefreak: no need to
[14:14] <asac> gnomefreak: all fine for langpacks from what i know
[14:14] <asac> gnomefreak: i closed a bug with a comment explaining it
[14:14] <gnomefreak> ah ok i was gonna do that thats why i asked why
[14:15] <gnomefreak> asac: thanks
[14:15] <asac> fta: sounds a bit like it could be because we have matchOS for locale detection
[14:15] <asac> what code is at that placeß
[14:15] <asac> ?
[14:16] <fta> asac, http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/src/nsUpdateService.js.in#502
[14:16] <gnomefreak> ill be back in a bit i think ill start on firegpg. oin the ones in my PPA just need to have ~jjv removed and intrepid changed to jaunty (i cant do that in my PPA)
[14:16] <fta> getlocale()
[14:17] <fta> Error: uncaught exception: [Exception... "Cannot modify properties of a WrappedNative"  nsresult: "0x80570034 (NS_ERROR_XPC_CANT_MODIFY_PROP_ON_WN)"  location: "JS frame :: chrome://global/content/bindings/autocomplete.xml :: onxblpopuphiding :: line 839"  data: no]
[14:22] <asac> fta: hmm ... couldnt find anything locale related in the createiniparser codepath
[14:22] <asac> but could be that its mxr that is broken
[14:22] <asac> oh
[14:22] <asac> dumb me
[14:23] <asac> we need updater.ini ?
[14:23] <asac> at least thats the file its looking for
[14:23] <asac> in APPDIR
[14:23] <asac> will figure that later ... have to go back to holiday now according to my gf
[14:23] <fta> :)
[14:23] <asac> probably its harmless ;)
[14:24] <fta> asac, one question before you leave
[14:25] <fta> asac, how should i name the google chrome package ? i started with chromium, but we already have a game named like that
[14:25] <fta> and it seems what i built is more than just chromium
[14:25] <fta> it's chromium plus a bunch of other repo, making it look like the full google chrome
[14:26] <fta> not sure it's really full though
[14:26] <fta> so, i renamed the package 'chrome' for now
[14:29] <fta> Nov 07 23:27:53 <fta>   http://paste.ubuntu.com/69026/
[14:43] <gnomefreak> is there an ETA on PPA jaunty?
[15:27] <fta> gnomefreak, see -devel
[15:27] <gnomefreak> thanks
[15:28] <gnomefreak> already is as i understand right?
[15:29] <fta> read the last ~20 lines
[15:29] <fta> it was not, i asked, now it is
[15:30] <gnomefreak> ok thanks
[15:30] <gnomefreak> i read last 10 lines or so
[15:34] <gnomefreak> damnit i have to build chroot again :(
[15:40] <gnomefreak> i guess by days end or tomorrow it will support jaunty
[16:06] <gnomefreak> ok i got time to wait ill be back a bit
[16:07] <gnomefreak> ook
[16:47] <asac> fta: what does that chrome package compromise=?
[16:47] <asac> i mean the sources
[16:48] <asac> fta: imo we have a bunch of packages
[16:48] <asac> chrome/ is just one of that
[16:50] <fta> asac, http://paste.ubuntu.com/69026/
[16:51] <fta> asac, that plus a lot of 3rd party directly in chromium :(
[16:52] <fta> asac, so far, i just packaged the whole thing in one big package, there's no point in fighting with the details just yet, it's far from usable/ready
[16:53] <fta> asac, there's not even support for x64, meaning ugly hacks like http://code.google.com/p/chromium/wiki/LinuxBuild64Bit
[16:54] <fta> gasp, ia32-libs is a 607MB source archive
[17:00] <sebner> HI asac! how are the holidays?
[17:01] <asac> good ;)
[17:01] <sebner> heh
[17:02] <sebner> asac: if you are bored you can add a comment on my applicaton :P
[17:02] <asac> fta: i think we should use chromium- as prefix
[17:02] <asac> e.g. chromium-v8 => source package for v8
[17:03] <asac> chromium-browser => chrome source package (trademark?)
[17:03] <asac> otherwise just chromium-chrome
[17:03] <fta> iirc, chromium + google breakpad + google something = google chrome
[17:03] <asac> fta: err
[17:03] <asac> fta: chromium is the project for all of these
[17:03] <asac> chrome is the name of the browser subtree
[17:04] <fta> different repos, different bug systems afaics
[17:04] <asac> no idea
[17:04] <asac> from what i understood breakpad was always a chromium thing ... and also is not in the chromium project
[17:05] <fta> ok, i have a contact in google, i will ask him
[17:05] <asac> anyway ... whatever is in the chromium project should be prefixed with chromium imo
[17:05] <asac> chromium-
[17:05] <fta> yep
[17:05] <asac> so probably we would even have chromium-webkit
[17:06] <asac> and stuf like that
[17:06] <asac> fta: you could try to get the chromium-prject meta project finally set up
[17:06] <asac> i think owner is now mozillateam of that
[17:07] <asac> sebner: your application?=
[17:07] <sebner> asac: for super moo powers
[17:08] <asac> mm
[17:08] <asac> how am i supposed to answer?
[17:08] <asac> did i get an email?
[17:09] <sebner> asac: nope, I didn't CC'ed you :P but if you are bored enough to write something ...
[17:11] <asac> not today ;)
[17:12] <asac> i will look tomorrow. but unlikely i would comment without me having the mail in first place ;)
[17:13] <sebner> asac: hehe, you always complained that you don't know what to write so I didn't CC you. no worries, actually 2 people are annoying me with questions so you have enough time to answer .. :P
[17:14] <fta> asac, what i have so far: http://paste.ubuntu.com/70074/
[17:21] <fta> asac, i wanted to have something usable before i start to cut that into pieces
[17:30] <sebner> asac: I have a question related to NM(-applet)
[17:30] <sebner> or maybe wlan
[17:30] <asac> fta: ok. i dont like the idea to start with a big chunk ;) ... but if it helps you its fine.
[17:30] <sebner> asac: I have a laptop and if I (zuklappe ^^) then NM-applet disconnects. But it's different. It can happy after 2 minutes or 2 hours
[17:31] <asac> sebner: not sure what you mean by disconnect. applet wont disconnect if laptop doesnt suspend
[17:31] <asac> if it seems like it does disconnect even though it doesnt power down, its almost certainly just a coincidant
[17:31] <asac> and unrelated
[17:32] <sebner> asac: ok, thx
[18:25] <fta> jcastro, could you hand over https://edge.launchpad.net/chromium-project to m-t please ?
[18:28] <asac> [ANN] nspluginwrapper 1.1.4
[18:28] <asac> i guess we should see if it helps and then even attempt a SRU
[18:28] <asac> from what i got on the ML it fixes a bunch of rather important bugs for firefox
[18:30] <jcastro> fta: she's all yours!
[18:30] <jcastro> fta: so did you finish porting chromium over the weekend? ;p
[18:30] <fta> jcastro, thanks
[18:30] <fta> jcastro, lol no, i just have an initial package, but it's a looooooooooooooooooooooog shot
[18:31] <jcastro> initial package?
[18:31] <fta> jcastro, http://www.sofaraway.org/ubuntu/tmp/chrome.png
[18:31] <jcastro> does it even run?
[18:31] <jcastro> hah, nice
[18:31] <fta> it's just the test_shell
[18:34] <fta> jcastro, if we don't solve that http://code.google.com/p/chromium/wiki/LinuxBuild64Bit it will be even longer for x64 users :P
[18:34] <fta> -be+take
[18:35] <jcastro> whew, good thing I'm on i386
[18:35] <jcastro> heh
[18:35] <asac> fta: we could give 32bit on 64bit a try
[18:36] <fta> asac, a native build stops there: http://paste.ubuntu.com/70027/
[18:37] <fta> hence the need for the 32bit nss reported in that google doc
[18:37] <fta> same for nspr and sqlite
[18:37] <fta> but upstream wanted that in hardy
[18:37] <fta> wants
[18:38] <fta> bug 246911
[18:38] <fta> fixed in intrepid, not hardy
[18:39] <fta> asac, ^^
[18:40] <asac> yeah
[18:41] <asac> fta: i dont think its a technical problem to fix ia32 libs everywhere
[18:41] <asac> let me check bug
[19:21] <fta> excluded = [c[1:] for c in load if c.startswith('-')]
[19:21] <fta> who said python was easier to read than perl ??
[19:29] <asac> lol
[19:30] <asac> but i guess thats  most likely the  hardest code python can do ;)
[19:31] <fta> in perl: @excluded = grep {/^-/} @c
[19:32] <fta> well, not exactly
[19:33] <fta> @excluded = grep {s/^-//} @c
[20:00] <asac> ok off for a while
[20:53] <fta> The program 'firefox-3.1' received an X Window System error.
[20:53] <fta> This probably reflects a bug in the program.
[20:53] <fta> The error was 'BadIDChoice (invalid resource ID chosen for this connection)'.
[20:53] <fta>   (Details: serial 64544849 error_code 14 request_code 156 minor_code 4)
[20:53] <fta>   (Note to programmers: normally, X errors are reported asynchronously;
[20:53] <fta>    that is, you will receive the error a while after causing it.
[20:53] <fta>    To debug your program, run it with the --sync command line
[20:53] <fta>    option to change this behavior. You can then get a meaningful
[20:54] <fta>    backtrace from your debugger if you break on the gdk_x_error() function.)
[20:54] <fta> (ff3.1)
[23:36] <asac> fta: reproducible? compiz?
[23:36] <fta> no, no


[01:19] <bluesabre> astraljava: I've got a bunch of fixes lined up for the screensaver that I'm testing currently... will hopefully have a release this weekend that makes everything work way better
[01:21] <JackFrost> Huh, there appears to be a new xfce4-panel-profiles.  Should I get to packaging things?
[01:22] <bluesabre> Sure, go for it :)
[01:22] <bluesabre> Been hard at coding the last few days
[01:23] <JackFrost> Oh hey, I forgot to link https://lists.debian.org/debian-devel-announce/2020/01/msg00002.html
[01:24] <bluesabre> Looks relatively painless
[02:04] <JackFrost> Disco is EOL, just removed that (and cosmic) from all PPAs.
[02:43] <genii> Isn't 19.10 good until July?
[04:06] <JackFrost> `distro-info -f -yeol --supported` no longer lists it, but true I didn't see an official announcement, only flavor.
[06:51] <astraljava> bluesabre: Oh, that's great news! I'll be busy most likely the whole weekend, but early next week I can beta test it if you need.


[07:46] <didrocks> mmrazik: hey! do you know what is happening on https://code.launchpad.net/~robru/qtubuntu-cameraplugin-fake/packaging/+merge/153652/comments/339216 ?
[07:48] <mmrazik> didrocks: the package needs rocket-scientists PPA for some reason (need to find out for what dep) but the rocket scientists ppa has no raring packages
[07:48] <mmrazik> if it is just mir I can change it to mir-team...
[07:49] <mmrazik> didrocks: there are lots of raring related failures. sergiusens is going through them.
[07:49] <didrocks> mmrazik: can you please comment on the MP?
[07:50] <mmrazik> didrocks: sure
[07:50] <didrocks> thanks :)
[07:50] <mmrazik> didrocks: is it something that needs to be merged asap?
[07:50] <didrocks> mmrazik: no, that's fine
[07:50] <didrocks> mmrazik: I prefer that we start bootstrapping one after another all the packages in the stack
[07:50] <didrocks> from top to bottom
[07:51] <mmrazik> didrocks: sergio just decided to move everybody to raring right away to force the porting. IMHO also a valid approach (even though I would most likely do it differently too)
[07:52] <didrocks> mmrazik: right, I'm talking about creating the stack and have daily release/cleaned packaging
[07:53] <didrocks> mmrazik: oh also, we will probably start to move some stacks from head to raring/
[07:53] <didrocks> mmrazik: as long as upstream didn't fix their head though, we will just comment the branches
[07:54] <mmrazik> didrocks: all these failures are in the phablet directory
[07:54] <mmrazik> nothing in head
[07:54] <didrocks> mmrazik: yeah, that's not related, just warning you about that :)
[07:54] <mmrazik> k
[08:08] <didrocks> mmrazik: see rev 108
[08:17] <mmrazik> didrocks: ack
[08:30] <Saviq> tsdgeos, hey, I don't think phablet-mods-merged is feasible... 100k diff...
[08:31] <Saviq> tsdgeos, I'd rather "save" the current phablet-mods branch as legacy
[08:32] <Saviq> tsdgeos, and build on lp:unity by a) cherry-picking from phablet-mods (I believe there's only a handful of commits we're interested in)
[08:32] <tsdgeos> Saviq: you're going to have a huge diff anyways if we want to merge to lp:unity/phablet-mods
[08:32] <tsdgeos> what i can do is reduce the diff against lp:unity
[08:32] <Saviq> tsdgeos, no, we're going to move that away
[08:32] <Saviq> tsdgeos, and push lp:unity as new lp:unity/phablet-mods
[08:32] <Saviq> tsdgeos, and cherry-pick into it
[08:33] <tsdgeos> ok
[08:33] <Saviq> tsdgeos, it's gonna get maintainable at least
[08:34] <tsdgeos> Saviq: but to make it build in quantal i still need to comment lots of stuff in the CMakeLists, are we still ok with that?
[08:34] <Saviq> tsdgeos, yeah
[08:34] <Saviq> tsdgeos, but at least we'll see the diff
[08:35] <tsdgeos> Saviq: you can see the diff if you do bzr diff --old lp:unity
[08:35] <Saviq> tsdgeos, hmm I tried that,
[08:35] <Saviq> tsdgeos, it was huge, too?
[08:35] <tsdgeos> you get a huge thing because for some reason all the .po files are different
[08:35] <tsdgeos> and someone added lots of ADD_DEBUG_HERE
[08:35] <tsdgeos> but otherwise is "smallish"
[08:36] <Saviq> ah!
[08:36] <tsdgeos> Saviq_: what's the last thing you saw?
[08:36] <Saviq> my VPS is back
[08:36] <Saviq> tsdgeos, meaning?
[08:36] <tsdgeos> ah ok, no disconnection
[08:37] <Saviq> :)
[08:37] <Saviq> tsdgeos, still 40k diff ;)
[08:37] <tsdgeos> ok
[08:37] <Saviq> tsdgeos, thing is, lp:unity/phablet-mods
[08:37] <Saviq> tsdgeos, includes the changes that were made for Nux phone shell
[08:37] <tsdgeos> so i'll create a new branch and cherry-pick from it
[08:37] <tsdgeos> yes
[08:38] <tsdgeos> like making icons bigger and stuff
[08:38] <Saviq> tsdgeos, so let's cut that fruit
[08:38] <Saviq> it's gonna make our lives easier
[08:38] <tsdgeos> ok
[08:39]  * tsdgeos starts again :-)
[08:40] <Saviq> tsdgeos, sorry, I thought that was the plan from the get go, bad comm on /me
[08:41] <tsdgeos> no worries, my fault for not rechecking at middle journey yesterday
[09:21] <didrocks> dednick: sil2100: hey, FYI, last results are available for autopilot release testing
[09:21] <didrocks> dednick: sil2100: ignore nvidia, it's a UTAH issue
[09:24] <dednick> looks like there's still some wait time issues with dash results. may need to increase. would have thought 10 seconds for a category would be enough :S
[09:26] <mzanetti_> Saviq: hey
[09:26] <mzanetti_> Saviq: I was updating our build-deps and noticed there is still python2.7 in there
[09:30] <Saviq> mzanetti, you have a MR for that don't you?
[09:30] <mzanetti> Saviq: iirc you had one..
[09:30] <Saviq> mzanetti, remember we haven't merged anything since last week due to failing raring builds
[09:31] <mzanetti> ohhh... now I remember.. you fixed it in indicators
[09:31] <mzanetti> ok. makes sense again
[09:37] <sil2100> dednick: I bumped it to 25 seconds for shopping results, since that's the average time it takes sometimes to fetch a shopping result ;/
[09:38] <dednick> sil2100: how do you increase the result wasit timeout? is there a variant of Eventually?
[09:39] <dednick> sil2100: was just about to look into that
[09:39] <sil2100> dednick: you just add the timeout parameter to the Eventually call
[09:39] <dednick> sil2100: ahh
[09:40] <sil2100> So it's like Eventually(value, timeout=25)
[09:40] <sil2100> dednick: it's neat ;)
[09:40] <sil2100> Anyway I filled this in yesterday anyway https://bugs.launchpad.net/unity/+bug/1159989
[09:40] <Saviq> mzanetti, I wonder, though, if we should investigate why python2.7 is not enough...
[09:41] <sil2100> Maybe it's the same thing for all 100scopes results really
[09:41] <mzanetti> Saviq: probably... but I tried for a while and couldn't reproduce it anywhere... its only failing in the ppas
[09:41] <mzanetti> which makes it really hard to debug
[09:42] <Saviq> mzanetti, I can reproduce it locally in a clean sbuild
[09:42] <Saviq> clean as in _really_ clean - a bootstrap, really
[09:42] <davidcalle> sil2100, have you tried this morning build of libunity? It's a lot faster for all scopes.
[09:42] <mzanetti> Saviq: this is the line that needs to pass: python -c "from distutils.sysconfig import get_python_lib; print get_python_lib()
[09:43] <mzanetti> Saviq: so the question is, why does distutils.sysconfig not get pulled in there by python2.7 but by python
[09:43] <Saviq> mzanetti, it actually does get pulled in, AFAIK, but it doesn't work
[09:44] <Saviq> mzanetti, ah
[09:44] <Saviq> mzanetti, there's no python in $PATH
[09:44] <Saviq> mzanetti, so the correct fix is to go with `python2.7 -c "from distutils.sysconfig import get_python_lib; print get_python_lib()"`
[09:45] <Saviq> mzanetti, instead of s/python2.7/python/ in build deps
[09:46] <mzanetti> Saviq: ah ok... makes sense. sergio said we shouldn't use a harcoded python version anyways.
[09:47] <mzanetti> Saviq: My experience with python is not good enough to give a qualified opinion. It works both now, but I don't know which one is more future proof.
[09:49] <Saviq> mzanetti, not using a hardcoded version might mean that suddenly python3 will become default and it will stop working most probably
[09:50] <mzanetti> Saviq: yep... just tested it with python 3.3... fails for invalid syntax
[09:51] <mzanetti> Saviq: ok. lets make it 2.7 then. cheers
[09:51] <Saviq> mzanetti, "print(thing)" instead of "print thing"
[09:51] <Saviq> mzanetti, but that's not even that
[09:51] <Saviq> mzanetti, if you run it with python3
[09:51] <Saviq> mzanetti, it will return /usr/lib/python3/dist-packages
[09:52] <mzanetti> Saviq: that would be ok
[09:52] <Saviq> so the autopilot tests would get installed _for_ python3
[09:52] <Saviq> mzanetti, assuming the tests work with python3 ;)
[09:52] <mzanetti> Saviq: right...
[09:52] <mzanetti> yeah. full ack. 2.7 it is
[10:03] <sil2100> davidcalle: hm, didn't upgrade yet, will try thanks! :)
[10:03] <sil2100> If it helps, then it would be awesome
[10:03] <sil2100> davidcalle: is it in the experimental PPA?
[10:03] <davidcalle> sil2100, yes
[10:03]  * sil2100 upgrades
[10:12] <Saviq> mzanetti, TBH CMake is nasty, then - instead of failing on the command it just went over and said the text was empty...
[10:12] <mzanetti> Saviq: yeah... doesn't make it any easier to debug
[10:17] <Saviq> mzanetti, http://www.cmake.org/cmake/help/cmake2.6docs.html#command:execute_process - we should check RESULT_VARIABLE and ERROR_VARIABLE
[10:27] <sil2100> davidcalle: ok, so I tried the latest libunity and even though normal results appear indeed faster now, I have the same problem with shopping results sadly ;/
[10:32] <davidcalle> sil2100, so, everything is fine :p IIRC libunity team were investigating it this morning.
[10:32] <sil2100> I even wonder what's wrong with the unity.tests.test_shopping_lens.ShoppingScopeTests.test_application_scope_has_shopping_results test failing
[10:33] <sil2100> Since on jenkins searching for 'Text Editor' in the app scope seems to return no results at all!
[10:33] <sil2100> Big huh
[10:34] <mzanetti> Saviq: https://code.launchpad.net/~mzanetti/unity/phablet-better-cmake/+merge/155451
[10:37] <didrocks> + [mrazik] Prepare a list of stacks: DONE
[10:38] <didrocks> mmrazik: this is something I took action on btw in coordination with upstream ^
[10:38] <didrocks> mmrazik: I think it will changed from current configuration
[10:38] <didrocks> (and will be in the head release btw)
[10:43] <mmrazik> didrocks: ack and agreed. The "done" here more or less means the projects have been identified and "somehow" stacked. There is still some work to do (I think sergio even added some TODOs into the cfgs)
[10:44] <didrocks> mmrazik: ok, sounds good :-)
[11:29] <kaleo_> Saviq: hey can I ask you a favor?
[11:29] <Saviq> kaleo_, you can try
[11:30] <kaleo_> Saviq: can you check unity is fine with Qt 5.0.1?
[11:31] <Saviq> kaleo_, which PPA?
[11:31] <kaleo_> Saviq: https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta-proper/+packages
[11:38] <Saviq> kaleo_, yeah, Qt 5.0.1 seems fine
[11:43] <kaleo_> gret
[11:44] <Saviq> we do have a crash on every search now :/ but that seems unrelated to the version of qt
[12:07] <tsdgeos> Saviq_: Saviq: lp:~aacid/unity/phablet-mods-cherrypicked
[12:08] <Saviq> tsdgeos, thanks
[12:08] <mmrazik> didrocks: the "to_transition" thing breaks ci/autolanding :-/
[12:08] <mmrazik> didrocks: what is the intended use of that?
[12:08] <tsdgeos> Saviq: builds fine in quantal (device and VM), i'm checking raring VM now, any idea what to do with raring device? shall i try to update the device?
[12:08] <didrocks> mmrazik: how break? the idea is to ignore those projects
[12:08] <didrocks> mmrazik: they are in raring/* for now
[12:09] <didrocks> so you still have the references to the branches
[12:09] <mmrazik> didrocks: right -- the CI job generator ignores those projects
[12:09] <Saviq> tsdgeos, nah, that won't work probably
[12:09] <didrocks> mmrazik: that's the goal :)
[12:09] <didrocks> mmrazik: you have them in raring
[12:09] <mmrazik> didrocks: the goal is to have no autolanding for lp:mir?
[12:09] <mmrazik> oh
[12:09] <didrocks> mmrazik: ah, mir is an oversight, should be only in main
[12:09] <didrocks> mmrazik: let me fix that :)
[12:09] <tsdgeos> Saviq: that's what i thought too
[12:09] <mmrazik> didrocks: thanks (and got it)
[12:09] <didrocks> mmrazik: FYI https://wiki.ubuntu.com/DailyRelease/MovingNewRelease
[12:10] <didrocks> mmrazik: I didn't reread it yet
[12:10] <tsdgeos> Saviq: so? just dump it into the ppa builders?
[12:10] <didrocks> mmrazik: feedback welcome :)
[12:10] <didrocks> mmrazik: rev 116, back mir on head
[12:10] <Saviq> tsdgeos, I'll move the branches around, you'll MR your branch to lp:unity/phablet-mods
[12:10] <didrocks> (and removed from raring)
[12:10] <Saviq> tsdgeos, and we'll see what jenkins has to say
[12:10] <tsdgeos> ok
[12:11] <tsdgeos> i tried MR-ing it against lp:unity/phablet-mods right now i get billions of conflicts
[12:11] <tsdgeos> since it's not based in that branch
[12:11] <tsdgeos> so makes sense :D
[12:12] <mmrazik> didrocks: thx
[12:12] <Saviq> tsdgeos, done https://code.launchpad.net/~unity-team/unity/phablet-mods
[12:13] <didrocks> mmrazik: it's the easiest workflow I can think of, but I'm really interested in your feedback :)
[12:13] <Saviq> tsdgeos, that's lp:unity/phablet-mods now
[12:14] <tsdgeos> okidoki
[12:15] <mmrazik> didrocks: I find it a bit counter-intuitive to have stuff in stacks/raring while the projects target_branch is trunk
[12:15] <tsdgeos> Saviq: https://code.launchpad.net/~aacid/unity/phablet-mods-cherrypicked/+merge/155469 a diff that fits in the webpage! :
[12:15] <tsdgeos> :D
[12:16] <Saviq> tsdgeos, yup :)
[12:16] <mmrazik> didrocks: why aren't we branching to lp:$project/raring while doing the cp?
[12:16] <didrocks> mmrazik: this is step 2
[12:16] <didrocks> mmrazik: step1 is better done in one shot
[12:16] <didrocks> then, everyone responsible for his stack can go over step2
[12:17] <mmrazik> ok. need to go through the whole thing
[12:18] <Saviq> tsdgeos, why don't we comment out the whole of hud, panel, dash etc?
[12:18] <Saviq> tsdgeos, only leaving UnityCore and the tests that make sense?
[12:18] <mmrazik> didrocks: did you push the mir changes?
[12:18] <mmrazik> I don't see it
[12:18] <tsdgeos> Saviq: tried to keep the diff as minimal as possible regarding files not built
[12:19] <Saviq> tsdgeos, mhm
[12:19] <tsdgeos> basically to run the tests
[12:19] <tsdgeos> even if probably they don't "apply"
[12:19] <didrocks> mmrazik: oh sorry, diverged branch
[12:20] <Saviq> tsdgeos, did you try to search anything in the dash lately?
[12:20] <tsdgeos> nope
[12:21] <didrocks> mmrazik: 117
[12:21] <mmrazik> didrocks: thx
[12:21] <didrocks> yw :)
[12:23] <Saviq> tsdgeos, crash in QQuickVisualDataModel::_q_itemsRemoved
[12:24] <Saviq> tsdgeos, every time
[12:24] <tsdgeos> ouch
[12:25] <tsdgeos> Saviq: when did that start?
[12:25] <Saviq> tsdgeos, not sure
[12:25] <tsdgeos> we didn't do anything there, did we?
[12:25] <tsdgeos> hmmm, wait i think mzanetti did some refactor in the history of searchs
[12:25] <mzanetti> yes
[12:26] <mzanetti> however, the crash has been there already before
[12:26] <mzanetti> at least for me
[12:26] <tsdgeos> i could make it crash "sometimes"
[12:26] <tsdgeos> not always
[12:26] <tsdgeos> i guess always is better? :D
[12:26] <mzanetti> I can't use the search at all. crashes 100%
[12:26] <Saviq> in a sense, yes
[12:26] <Saviq> mzanetti, yup, same here
[12:26] <mzanetti> and for me just starting the shell crashes too
[12:26] <mzanetti> in 80% of the cases
[12:27] <mzanetti> if I pass -geomtry 1600x1200 it gets more stable
[12:27] <mzanetti> it seems the faster the hardware, the more it crashes
[12:27] <tsdgeos> weird
[12:27] <tsdgeos> never happened here
[12:27] <mzanetti> doesn't crash in slow jenkins at all
[12:28] <tsdgeos> Saviq: ok, build on raring VM too, so unless you want me to do a "bigger cut" of things we built, it should be ok from my side
[12:28] <tsdgeos> let's see what CI says :D
[12:28] <Saviq> tsdgeos, looking at launcher/CMakeLists.txt for example...
[12:29] <Saviq> tsdgeos, there's barely anything left
[12:29] <tsdgeos> half of the files
[12:29] <tsdgeos> yeah
[12:30] <tsdgeos> no binary but the files still get linked to the tests
[12:37] <Saviq> tsdgeos, mzanetti it's the carousel - r478
[12:37] <mzanetti> interesting...
[12:43] <tsdgeos> weird
[12:43] <tsdgeos> lunch
[13:14] <luv> mardy: hey! did you get my messages yesterday? ... only relevant library i have installet in the system is libsignon-plugins-common.so but it exports different symbols than oauth plugin is asking for
[13:15] <luv> http://pastebin.blesmrt.net/3103/
[13:16] <mardy> luv: yes, I proposed a fix: https://code.launchpad.net/~mardy/signon/packaging/+merge/155425
[13:16] <luv> you guys are fast :-) great job, thanks!
[13:17] <luv> im afraid installing .a wont be enough, because it uses -lsignon-plugins to link - maybe oauth needs to be changed to link statically against signog-plugins?
[13:17] <luv> signon
[13:19] <luv> anyway, i can try when i get back home and eventually fix oauth plugin accordingly
[13:20] <Saviq> tsdgeos, you saw it failed?
[13:47] <tsdgeos> Saviq: yes but afaik was CI itself failing no?
[13:47]  * tsdgeos looks again
[13:47] <Saviq> tsdgeos, possibly, I restarted
[13:48] <tsdgeos> Saviq: ok, one was ccache failing for some weird reason
[13:48] <tsdgeos> there's two more that have
[13:48] <tsdgeos> test-gtest-xless: /build/buildd/ubuntu-platform-api-0.18/src/android/ubuntu_application_api.cpp:51: {anonymous}::Bridge::Bridge(): Assertion `lib_handle && "Error loading ubuntu_application_api"' failed.
[13:48] <tsdgeos> that i have no idea why may be happening
[13:49] <dandrader> greyback, would you have some time to review this? https://code.launchpad.net/~dandrader/unity/phablet_tst_Stage/+merge/155489
[13:49] <dandrader> Tests for Stage.qml
[13:50] <tsdgeos> mzanetti: mmrazik: any idea why test-gtest-xless: /build/buildd/ubuntu-platform-api-0.18/src/android/ubuntu_application_api.cpp:51: {anonymous}::Bridge::Bridge(): Assertion `lib_handle && "Error loading ubuntu_application_api"' failed.  may be happening in the arm machines on running unity tests?
[13:50] <greyback> dandrader: tbh you've caught me at a terrible time. Can someone else take it?
[13:50] <dandrader> greyback, sure
[13:51] <greyback> sorry
[13:51] <mzanetti> tsdgeos: cant really follow...
[13:51] <mmrazik> tsdgeos: absolutely no clue :-/
[13:51] <mzanetti> dandrader: I'll take it
[13:51] <dandrader> mzanetti, thanks!
[13:53] <dednick> didrocks, sil2100: more ap test fixes. https://code.launchpad.net/~nick-dedekind/unity/smart-scopes.autopilot-build-18/+merge/155491
[13:53] <dednick> sil2100: can you review please?
[13:55] <Saviq> tsdgeos, try ricmm
[13:55] <mmrazik> mzanetti: ps-quantal-server-amd64-1 is back in the pool
[13:55] <mmrazik> mzanetti: and it looks like qmluitests were just scheduled there
[13:55] <mzanetti> mmrazik: thanks a bunch
[13:56] <mmrazik> mzanetti: mhm... is the failure my bug?
[13:56] <mmrazik> mzanetti: http://s-jenkins:8080/job/unity-phablet-qmluitests/13/console
[13:56] <mzanetti> mmrazik: no. its mine
[13:56] <mmrazik> ok
[13:56] <mzanetti> mmrazik: I'm still experimenting
[13:57] <mzanetti> mmrazik: right now the qmluitests just stall forever when jenkins executes them, but if I log in and execute the exact same pbuilder call everything is fine
[13:57] <mzanetti> sometimes I really wonder...
[13:58] <sil2100> dednick: aye!
[14:07] <tsdgeos> Saviq: i think it may have to do with the fact that the CI machine is *not* a device thus the ubuntu_application_api thing fails
[14:10] <mmrazik> didrocks: regarding https://wiki.ubuntu.com/DailyRelease/MovingNewRelease -- I would find it more logical to have the "to_transition" stenza in the new stack rather then head (as thats something that needs to be created while the head is there all the time). OTOH I get that it is more logical from your/distro POV do it this way
[14:10] <mmrazik> and in the end the result is the same
[14:11] <mmrazik> didrocks: I guess I just need to add stuff to the "redeploy all stacks" as you need to create the autolanding jobs for the new branches too
[14:11] <mmrazik> other than that looks good to me
[14:11] <mardy> luv: it should work, the linker -l resolves static libraries as well
[14:16] <sil2100> dednick: commented and approved, good catch!
[14:17] <didrocks> mmrazik: if you do that, you will need to deploy the stack 2 more times
[14:17] <dednick> sil2100: thanks
[14:17] <didrocks> mmrazik: and you can end up in more cases with "same data in both stack"
[14:18] <didrocks> mmrazik: rather than once raring and then transitionning
[14:18] <didrocks> mmrazik: I started the way you mentionned
[14:18] <didrocks> mmrazik: then, got 20 steps and started to revise to have something less error-prone :)
[14:18] <didrocks> hence the current proposed way
[14:18] <mmrazik> ok
[14:18] <mzanetti> Saviq: hey, I think it would make sense to include om26er in our standup. Can you update it please? I can only invite guests which doesn't put it in his calendar etc
[14:19] <Saviq> mzanetti, hum? you should be able to add just fine?
[14:19] <Saviq> mzanetti, they're all guests :D
[14:19] <mzanetti> oh... ok
[14:19] <mzanetti> it does look a bit differnt tho
[14:19] <Saviq> mzanetti, but done anyway
[14:19] <mzanetti> cheers
[14:20] <dednick> sil2100: i just pushed another 1 liner and bumped the approve. hope you dont mind ;)
[14:21] <sil2100> dednick: that's cool ;)
[14:21] <dednick> sil2100: just wanted to make sure that at least one cycle of wait_for_result_settle would get executed if dash was empty to start off
[14:23] <didrocks> dednick: thanks! will be in the next next rebuild (so tomorrow morning)
[14:23] <didrocks> dednick: but if we get the current build quick enough, I can maybe relaunch one (just unity)
[14:23] <om26er> mzanetti, now they appear in my calendar
[14:24] <dednick> didrocks: did the changes mhr3 was talking about get in?
[14:24] <mzanetti> om26er: ok, great
[14:24] <Saviq> mzanetti, remember that you have to save after adding a guest
[14:24] <Saviq> maybe that was why it didn't show up?
[14:24] <mzanetti> Saviq: haha... I guess thats it indeed
[14:24] <sil2100> dednick, didrocks: regarding the shopping scopes and the scopes long-time-to-display-results, pstolowski told me it's being worked on right now
[14:24] <mzanetti> yay for webapps!
[14:24] <didrocks> dednick: you mean https://code.launchpad.net/~mhr3/libunity/handle-scope-flags/+merge/155465?
[14:25] <mzanetti> I just love how consistent usability is among them
[14:25] <didrocks> dednick: it's in if you speak about them :)
[14:25] <didrocks> sil2100: nice :)
[14:25] <dednick> didrocks: yep, i think that's the ones.
[14:25] <dednick> ta
[14:27] <mzanetti> dandrader: really cool stuff :)
[14:27] <mterry> fginther, what's the story with the ci job trying to build in raring for merges against unity/phablet ?  They seem doomed to fail?
[14:27] <mzanetti> dandrader: why do you change the ApplicationScreenshots to properties?
[14:28] <dandrader> mzanetti, so that I can replace them with mock implementations in the test
[14:28] <fginther> mmrazik, can you answer mterry ^ ?
[14:29] <didrocks> mterry: hey! hot from the press: https://wiki.ubuntu.com/DailyRelease/MovingNewRelease
[14:29] <didrocks> mterry: I'm interesting in feedback
[14:29] <didrocks> kenvandine: as well ^
[14:29] <kenvandine> didrocks, i'll read :)
[14:29] <didrocks> thanks :)
[14:30] <mmrazik> mterry, fginther: its more of an question for sergiusens but they are not doomed to fail. You can just fix them :)
[14:30] <mmrazik> mterry: Ibelieve that is the motivation behind it  -- to force people to migrate to raring
[14:31] <mterry> mmrazik, but it has the effect of blocking all merges, right?
[14:31] <mmrazik> mterry: yup
[14:32] <mmrazik> mterry: if you have any specific concerns/something urgent to merge then talk to sergiusens. He is the guy behind this.
[14:34] <mterry> mmrazik, I just didn't think we had the pieces in place yet to handle raring, and the fault wasn't that unity devs were dragging their feet, but that distro people like me and didrocks were too busy with releassing raring to get to phablet on raring
[14:34] <mterry> mmrazik, so we're blocking people that have no power to unblock themselves...
[14:34] <mmrazik> mterry: can't comment on that
[14:35] <mmrazik> mterry: but nobody complained so far :)
[14:35] <mmrazik> or at least not to me
[14:35] <mterry> mmrazik, I just did.  ;)  I'll poke sergiusens
[14:35] <nic-doffay> Saviq, gonna have to skip standup today busy discussing Infographics. Still need someone to review the test case though.
[14:35] <Saviq> nic-doffay, k
[14:36] <mmrazik> mterry: there is actually a thread on this on the phablet mailing list
[14:36] <didrocks> mterry: btw, the page I pointed it the first step to have "head" and thus phablet ppa :)
[14:36] <mmrazik> mterry: where nobody really complied
[14:36] <mmrazik> err
[14:36] <mmrazik> complained
[14:40] <Saviq> om26er, can you hear us?
[14:41] <om26er> i could hear you all
[14:41] <om26er> Saviq, seems my mic is not working
[14:41] <om26er> for mumble only (?)
[14:41] <dednick> you got push to talk enabled?
[14:41] <Saviq> om26er, or your push-to-talk button?
[14:42] <mterry> didrocks, why does the plan involve disabling head, then re-enabling it one by one?  Don't our stack dependencies ensure that things will be built correctly in a fresh PPA?
[14:42] <mterry> Not to mention build-waiting
[14:43] <didrocks> mterry: we disable head because we are basically taking a snapshot of head and put that into raring
[14:43] <om26er> Saviq, i don;t think so. push to talk is not enabled
[14:44] <didrocks> mterry: if we don't do that, we'll have to tweak the deps on every stack we push to dep on "head", "qa"?
[14:44] <mterry> didrocks, sure, that's what the "raring" release is for (vs "head")
[14:45] <mterry> didrocks, I'm not sure I follow that last statement
[14:45] <didrocks> mterry: ok, let's discuss it in a hangout
[14:45] <mzanetti> om26er: hehe, that didn't really work out :)
[14:45] <mzanetti> om26er: when you think your mumble is working, let me know so we can test
[14:45] <om26er> mzanetti, it should, tomorrow
[14:46] <didrocks> mterry: in an hour?
[14:46] <om26er> mzanetti, i am installing it on a different machine right now
[14:46] <mterry> didrocks, sure
[14:46] <om26er> mzanetti, and i;ll poke you to test call
[14:46] <mzanetti> om26er: ok
[14:46] <mzanetti> om26er: and no worries. I don't know anyone yet that hasn't ever had an issue with mumble in the standup
[14:48] <MacSlow> Saviq, there you go https://code.launchpad.net/~macslow/unity/phablet-notification-renderer/+merge/155512
[14:50] <dandrader> tsdgeos, I got this error, which is unrelated to my merge proposal changes: http://pastebin.ubuntu.com/5649560/
[14:51] <dandrader> tsdgeos, from https://code.launchpad.net/~dandrader/unity/phablet_tst_Stage/+merge/155489/comments/339607
[14:51] <Saviq> MacSlow, cheers
[14:51] <dandrader> tsdgeos, have you seem anything similar
[14:51] <dandrader> ?
[14:51] <tsdgeos> dandrader: yes
[14:51] <Saviq> MacSlow, I'll try and post feedback today/tomorrow
[14:51] <tsdgeos> dandrader: that's the thing i've been working the last to days
[14:51] <tsdgeos> dandrader: we are stuck on raring merges at the momet
[14:51] <tsdgeos> +n
[14:52] <MacSlow> Saviq, great thanks... but it's not done yet :)
[14:52] <dandrader> tsdgeos, ah,ok. will that block merges for the time being?
[14:52] <Saviq> MacSlow, that's fine, just want to make sure you're not following some paths that will bite you later
[14:52] <MacSlow> Saviq, yup
[14:52] <tsdgeos> dandrader: unfortunately
[14:53] <dandrader> :(
[14:54] <tsdgeos> yep
[14:54] <tsdgeos> our merges are piling up
[14:54] <tsdgeos> i "think" i'm almost done
[14:54] <tsdgeos> CI is almost finished and then i'll nudge Saviq
[14:55] <tsdgeos> Saviq: kgunn: do we have a blueprint item for "port phablet-mods to a newer unity"? Given we've spent a considerable amount of time in it i think it should probably logged
[14:56] <Saviq> tsdgeos, it's more of a "migrate to raring" item, and no, we don'
[14:56] <Saviq> 't
[14:57] <Saviq> tsdgeos, I'll add
[14:57] <dandrader> mzanetti, the instability fix: https://code.launchpad.net/~dandrader/unity/phablet_tst_DashPreview_instability/+merge/155515
[14:58] <tsdgeos> Saviq: see https://code.launchpad.net/~aacid/unity/phablet-mods-cherrypicked/+merge/155469 along with my last comment, we can say CI has passed
[14:59] <mzanetti> dandrader: thanks a lot
[14:59] <dandrader> mzanetti, yw
[15:00] <Saviq> tsdgeos, yup, looks good, will wait for the CI to finish and look through the diff quickly
[15:01] <tsdgeos> oka
[15:01] <Saviq> tsdgeos, we'll need a release bump to v 7.80, too
[15:01]  * tsdgeos does
[15:02] <kgunn> any takers on https://code.launchpad.net/~nicolas-doffay/unity/page-header-test/+merge/155242
[15:04] <tsdgeos> Saviq: done http://bazaar.launchpad.net/~aacid/unity/phablet-mods-cherrypicked/revision/3259
[15:05] <Saviq> tsdgeos, cheers
[15:06] <Saviq> kgunn, not that easy, you need to point at people ;)
[15:07] <tsdgeos> kgunn: added a comment about why the raring part is broken if that's what you meant
[15:08] <kgunn> tsdgeos: thanks...no, was just wanting to get nick some review/feedback is any
[15:08] <kgunn> oops/is/if
[15:09] <kgunn> dandrader: would you mind reviewing https://code.launchpad.net/~nicolas-doffay/unity/page-header-test/+merge/155242
[15:10] <dandrader> kgunn, not at all. but didn't Saviq just do it
[15:10] <dandrader> ?
[15:10] <Saviq> kgunn, dandrader I mostly did...
[15:11] <Saviq> dandrader, please only mark things DONE in the bp when they're merged
[15:11] <dandrader> Saviq, ah, ok. sorry
[15:11] <kgunn> Saviq: dandrader stale webpage....sorry :)
[15:11] <kgunn> dandrader: plus Saviq said point at people...so i did
[15:11] <kgunn> :)
[15:13] <tsdgeos> kgunn: Saviq: mzanetti: i see i have the "HUD testing" blueprint item in both https://blueprints.launchpad.net/ubuntu/+spec/client-1303-unity-hud-2-ui and https://blueprints.launchpad.net/ubuntu/+spec/client-1303-unity-ui-testing does it really make sense to have it twice?
[15:13] <Saviq> tsdgeos, no, just leave one of them in
[15:14] <tsdgeos> ok
[15:14] <tsdgeos> Saviq: https://code.launchpad.net/~aacid/unity/phablet-mods-cherrypicked/+merge/155469 CI appoved
[15:16] <didrocks> mterry: kenvandine: cyphermox: I have half an hour now, ok for a hangout with this deployment doc?
[15:17] <cyphermox> yeah
[15:17] <didrocks> mterry: kenvandine cyphermox: https://plus.google.com/hangouts/_/4340e3dc7f93270210e58a9d8fd05d667f23b13a?authuser=0&hl=en
[15:19] <Saviq> tsdgeos, huh? libunity-2d-private? wth?
[15:19] <Saviq> where did it build that from :D
[15:20] <tsdgeos> Saviq: from thin air :D
[15:20] <tsdgeos> Saviq: i guess someone decided unity should build empty unity-2d packages now that we don't package unity-2d anymore
[15:20] <tsdgeos> or something
[15:20] <Saviq> tsdgeos, ar right
[15:32] <Saviq> tsdgeos, it's alive! ;)
[15:36] <tsdgeos> Saviq: :)
[15:36] <Saviq> tsdgeos, another ccache failure is incoming, though
[15:36] <tsdgeos> oh my
[15:37] <Saviq> hopefully autolanding will be fine
[15:48] <mterry> didrocks, does Enter activate the first search result for you with 100 scopes?
[15:48] <mterry> didrocks, doesn't seem to for me, which is a regression
[15:49] <mterry> Hrm... It does, but only after all results are in, maybe?
[15:49] <tsdgeos> Saviq: any idea when/if autolanding triggers?
[15:50] <Saviq> tsdgeos, good question
[15:50] <Saviq> mterry, yeah, I have a similar experience
[15:51] <mterry> Saviq, hrm.  do you have a guess who to ping about it?
[15:51] <mterry> tsdgeos, ^?
[15:52] <tsdgeos> mterry: no idea sorry
[15:52]  * mterry files bug
[15:52] <Saviq> mterry, yup, do that
[15:52] <Saviq> mterry, add 100scopes as tag
[15:53] <tsdgeos> mmrazik: mzanetti: do you know when/if autoloanding triggers for the phablet-mods MRs?
[15:53] <Saviq> tsdgeos, already pinged mmrazik
[15:53] <mmrazik> tsdgeos: */15 * * * *
[15:53] <tsdgeos> oki, sorry :-)
[15:53] <mmrazik> + some time to process your particular branch
[15:53] <mmrazik> tsdgeos: the branch was locked. released it so it should be picked in ~7mins
[15:54] <tsdgeos> mmrazik: ok, tx
[16:04] <mmrazik> didrocks: in case you have a sec: https://code.launchpad.net/~mrazik/cupstream2distro-config/webcred/+merge/155541
[16:04] <mmrazik> didrocks: just to confirm I'm using the to_release correctly
[16:14] <didrocks> mmrazik: why account-plugins is not in to_transition?
[16:14] <mmrazik> didrocks: it has both trunk and 13.04 branch
[16:14] <didrocks> mmrazik: we'll do that thursday if you don't mind
[16:14] <didrocks> mmrazik: I need to deploy the stacks
[16:14] <didrocks> mmrazik: and I want to do a check before and then after
[16:15] <didrocks> mmrazik: but yeah, the idea is good otherwise :)
[16:15] <didrocks> just I'm not a huge fan of:
[16:15] <didrocks> signon-keyring-extension:
[16:15] <didrocks>    target_branch: lp:signon-keyring-extension
[16:16] <didrocks> is the repetition needed?
[16:16] <didrocks> I handle that as "default"
[16:16] <didrocks> to avoid having too much lines in the config
[16:17] <mmrazik> didrocks: its because I expect people will just add /13.04
[16:17] <mmrazik> and delete in head
[16:17] <mmrazik> I can probably delete in head right away
[16:17] <mmrazik> I just did it for raring and then copied to head
[16:18] <mmrazik> didrocks: so should account-plugins stay in to_transition?
[16:18] <didrocks> mmrazik: well, and remove the 13.04 branch if possible
[16:18] <didrocks> for it
[16:18] <didrocks> just until thursday
[16:18] <didrocks> mmrazik|otp: I want to test the new procedure
[16:18] <didrocks> mmrazik|otp: but I'm not there tomorrow
[16:18] <didrocks> and a build thursday "normal"
[16:18] <didrocks> then deploying this
[16:19] <didrocks> and testing again :)
[16:19] <didrocks> mmrazik|otp: sounds good?
[16:23] <didrocks> kenvandine: FYI ^
[16:23] <kenvandine> didrocks, ok
[16:31] <rickspencer3> hey all
[16:31] <rickspencer3> my panel froze :/
[16:32] <rickspencer3> oh, it just unfroze :/
[16:32] <davidcalle> didrocks, do you mind looking at https://code.launchpad.net/~submarine/ubuntu-scopes/yelp-limit-results/+merge/155076 , the yelp scope is currently returning an unhealthy number of results.
[16:33] <didrocks> davidcalle: looking
[16:38] <mmrazik> didrocks: back to the accoung-plugins -- the thing is that if I move it back to "to_transision" I won't be able to generate ci/autolanding jobs for trunk
[16:39] <mmrazik> didrocks: I had hoped that with daily_release set to False it won't generate any job for the distro stuff
[16:39] <didrocks> mmrazik: it shouldn't
[16:39] <didrocks> mmrazik: but I would have hope to check the process once first :/
[16:39] <didrocks> mmrazik: do they really need those branches today?
[16:39] <didrocks> can't wait on thursday?
[16:40] <mmrazik> didrocks: I had an impression kenvandine wants to land something to the /13.04
[16:40] <mmrazik> didrocks: but I wonder why it needs to wait when it should have no effect on your stuff
[16:40] <didrocks> kenvandine: I told that we should wait on thursday, isn't it? ^
[16:40] <kenvandine> mmrazik, not really, mardy merged it i think
[16:41] <didrocks> mmrazik: I want to test a before run/after run
[16:41] <kenvandine> didrocks, not related to daily releases
[16:41] <didrocks> mmrazik: to ensure the workflow makes sense
[16:41] <didrocks> kenvandine: changing the stack config impact daily releases
[16:41] <kenvandine> mardy branched for 13.04 to add new features to trunk
[16:41]  * kenvandine wasn't changing the config :)
[16:41] <mmrazik> didrocks: how does what I proposed change the daily release?
[16:41] <didrocks> mmrazik: because this file is read by the daily releases
[16:42] <kenvandine> so mardy had me upload a bug fix proposed against their 13.04 branch
[16:42] <didrocks> kenvandine: urgh
[16:42] <mmrazik> didrocks: but all of it should be ignored due to "daily_release: False" or am I missing something?
[16:42] <didrocks> kenvandine: so you *need* to deploy the daily today right?
[16:42] <didrocks> kenvandine: to point to none trunk
[16:42] <kenvandine> didrocks, it isn't daily
[16:42] <didrocks> mmrazik: it should, but I'm not here today and I didn't test it
[16:42] <didrocks> tomorrow*
[16:42] <didrocks> kenvandine: ah, not that one
[16:42] <kenvandine> right :)
[16:43] <Saviq> tsdgeos, just so you know, don't worry if it doesn't merge today (although I know you'd rather push it to the end)
[16:43] <Saviq> tsdgeos, we'll take over
[16:43] <didrocks> mmrazik: it's just I was hoping we can just wait on me being back and not complicating things over for nothing :(
[16:43] <tsdgeos> Saviq: sure, just want to see it in :D
[16:43] <mmrazik> didrocks: the "daily_release: False" stuff is not new one. What needs to be tested?
[16:43] <didrocks> we already have too much on each ones plate to take risk
[16:44] <didrocks> mmrazik: well, it wasn't in any of the stack when having a target_branch
[16:44] <didrocks> so it wasn't taken into account
[16:46] <didrocks> mmrazik: if you are around tomorrow to fix the daily release if things go wrong, I don't care :-)
[16:46] <mmrazik> didrocks: TBH I still don't get it but as you wish
[16:46] <mmrazik> didrocks: what could possibly go wrong? We have jenkins jobs to daily release stuff we don't want to daily release?
[16:46] <didrocks> mmrazik: let's coordinate this on Thursday, it will be a nice "first example" to transition to this workaround
[16:46] <didrocks> s/workaround/workflow/
[16:47] <mmrazik> didrocks: I'm not here for most of the Thu (have an appointment at US embassy to get Visas)
[16:47] <didrocks> mmrazik: as we are deploying stuff, it's different folders used for daily release
[16:47] <mmrazik> didrocks: there is something broken here. We can't create autolanding jobs because of something daily-release related. These two things should be independent
[16:48] <didrocks> mmrazik: it should be fine and have no impact
[16:48] <didrocks> mmrazik: but as it's the first time, I want to confirm first
[16:48] <didrocks> and be here if things go wrong
[16:48] <mmrazik> ok
[16:49] <didrocks> mmrazik: we just deployed this common config, I think rather than arguing, we should try to mitigate and lower the impact :)
[16:49] <didrocks> it's just a "just in case thing"
[16:49] <didrocks> if this goes wrong, nobody will be able to fix it tomorrow
[16:50] <mmrazik> didrocks: ok
[17:01] <robru> didrocks, hangout?
[17:01] <didrocks> robru: yep, you should have the link in the invite :)
[17:04] <didrocks> kenvandine: cyphermox mterry : joining?
[17:04] <mterry> didrocks, coming, hold on
[17:05] <tsdgeos> Saviq: failed again :/
[17:06] <tsdgeos> Saviq: i have to go, will try to come back in a couple of hours or so
[17:30] <cyphermox> argh, I can't believe how hangouts crash all the time here
[18:01] <mterry> didrocks, so..  what's the PPA name again for the phablet auto-uploading bits? experimental-certified?
[18:02] <didrocks> mterry: it will be daily-build-next
[18:02] <didrocks> (the final one will be "next")
[18:03] <mterry> OK, nothing in there yet
[18:03] <rtdrury> Hi!  I just viewed the Unity page for the first time and the question stands out there: What is Unity?  The answer below does not answer the question What is Unity?  Instead it answers What Does Unity Do?
[18:04] <rtdrury> Could the Ubuntu team change the answer so that it answers the question What is Unity?
[18:04] <rtdrury> Is there anyone here who can take this request to the relevant people?
[18:06] <rtdrury> All silent?  Whay is this?  My expectation is of a nomal gathering of people interacting in ways to build a more common understanding of the wold, specifically of a linux distro?
[18:10] <sil2100> rtdrury: hi! I'm sure if anyone with the power to resolve this issue was around he/she would answer - you can't get angry because currently there is no such person online
[18:11] <rtdrury> So we want that up  is up and down is down, white is white, black is black.  So povide direct information.  Keep Madison Ave out of the communications in the frree software community.  Unity is probaby some merging of Gnome & KDE.  But the question wasn't answered.  People want to know what it is first.
[18:11] <sil2100> I will try to remember this and forward it to someone that could be able to resolve this issue
[18:12] <rtdrury> Oh thanks - you'e a lifesaver, sil2100.  Have a great day.  My anger is well under control.  Ubuntu is great.  I just want to keep it great.  Ya know?  How are you?
[18:13] <sil2100> Thank you, I'm rather fine, how about you?
[18:13] <sil2100> Just a bit busy maybe
[18:15] <rtdrury> Yeah, vey busy here too.  It's been a long time since enering a chat room.  I think these are great.
[18:17] <rtdrury> So I'm upgrading from Lucid Lynx I think it is.  I'd like to thank all the volunteers.  Do you code?  Do you know what volunteer help is needed most?
[18:19] <sil2100> rtdrury: oh, excellent - yes, I code most of the time, although I have some packaging tasks as well - help is welcome basically everywhere, as always!
[18:19] <sil2100> rtdrury: are you a programmer as well?
[18:20] <sil2100> If you're upgrading, Unity might seem a bit 'different' to you: there's a lot of things an usuall Gnome user needs to get used to
[18:20] <rtdrury> I did lots of C codle in the past, and these dats doing more C code, using Gnome, have a Java project, and lots of PHP, Javascript & Bash scripts.
[18:22] <rtdrury> Oh mainly need for Gnome to work - I mainly want to use Ardour music studio with my Gnome-based plugins.
[18:23] <rtdrury> Ah so Unity is a desktop environment?
[18:23] <mhall119> it's a shell for Gnome DE
[18:23] <mhall119> currently
[18:23] <mhall119> Unity Next will be a bit more than that
[18:25] <rtdrury> Great - I noticed Gnome's API is evolving rapidly with lots of depreciated classes.  GUI evolution.
[18:26] <rtdrury> Well, I think you guys are doing the world a huge service by just being available here to answer questions.
[18:26] <mhall119> Unity is currently Gnome - (Gnome Shell) + (Unity Shell)
[18:26] <mhall119> if that math makes sense :)
[18:27] <rtdrury> Sure, I can see that is a superposition - a fancy word for summation
[18:28] <rtdrury> So you have the two shells to choose from?
[18:29] <mhall119> two shells for Gnome DE, but also KDE, Xfce, LXDE, and many others
[18:31] <rtdrury> I'd glad that you can see the bigger picture, seeing different people using different graphical environments.
[18:31] <sil2100> rtdrury: with Unity set as the default environment
[18:31] <sil2100> But allowing switching at will, depending on preferences
[18:32] <rtdrury> Well that's great - look guys, I have a huge load of work to do - this chat session has been great - this is the future.  Access to real live humans when it's really needed.  Keep up the great work.
[18:32] <mterry> didrocks, is there going to be a separate MIR bug for the 100 scopes?
[18:33] <didrocks> mterry: depends on your preferences
[18:33] <sil2100> cyphermox: ping, are you still around?
[18:33] <mterry> didrocks, no rush, just ping me when you make it, I have comments ready
[18:33] <didrocks> mterry: as everything is listed in the FFe, that's fine by me
[18:33] <didrocks> mterry: if you prefer a separate MIR bug, I can do it
[18:33] <mterry> didrocks, I'd prefer separate, just so I don't pollute the status field of the FFe
[18:34] <mterry> Huh, qtpim never made it to raring
[18:34] <mterry> Nor did libtelepathy-qt5...
[18:34] <didrocks> mterry: ok, if I prepare it on thursday, that's fine?
[18:35] <mterry> didrocks, sure...  I think the only blocker was the privacy issue
[18:35] <didrocks> mterry: yeah, which is addressed now, isn't it pstolowski? ^
[18:35] <mterry> didrocks, the bug is still open.  bug 1158782
[18:35] <pstolowski> mterry, didrocks: right, it's supported now
[18:36] <didrocks> pstolowski: please close the bug! :)
[18:36] <pstolowski> it wasn't assigned to home scope nor libunity ;)
[18:37] <pstolowski> didrocks: updated (except for 'unity (Ubuntu)' - not sure)
[18:38] <didrocks> pstolowski: you can close it
[18:38] <didrocks> pstolowski: those bugs never ended up in the distro
[18:38] <didrocks> so fine to not list them
[18:39] <cyphermox> sil2100: yeah I'm around
[18:43] <mterry> didrocks, in which PPA should I put packages like qtpim and telepathy-qt5 that aren't upstreams we watch, but are not yet in raring?
[18:43] <didrocks> mterry: we will need them to build the touch stack in the end, right?
[18:43] <sil2100> cyphermox: aaactually, I think I found a solution already - but would you mind if I poke you with some packaging branches for a review?
[18:44] <mterry> didrocks, right, they are deps of at least phone-app
[18:44] <cyphermox> sil2100: sure
[18:44] <didrocks> mterry: so daily-build-next for now
[18:44] <mterry> didrocks, just manually copy them in there?  sure
[18:44] <didrocks> mterry: manual copy or upload :)
[18:44]  * mterry tries to find the source for telepathy-qt5
[18:44] <didrocks> mterry: do you mind noting those things in the whiteboard of the blueprint?
[18:44] <mterry> ok
[18:44] <didrocks> mterry: so that we don't loose track on them
[18:44] <didrocks> thanks :)
[19:00] <seb128> cyphermox, mterry: could you get https://code.launchpad.net/~seb128/indicator-datetime/systemd-packaging-update/+merge/155584 reviewed/acked
[19:00] <seb128> it's based on top of https://code.launchpad.net/~desrt/indicator-datetime/timedated/+merge/151560
[19:00] <cyphermox> ok
[19:00] <seb128> I will land the other places in raring in a bit
[19:00] <seb128> thanks
[19:00] <cyphermox> that's fixing a current bug in raring
[19:00] <seb128> but it would be good to have that in the vcs so we can autoland the indicator for the transition
[19:00] <mterry> cyphermox, thanks. I have to run out for an errand
[19:00] <cyphermox> should be targetted to indicator-datetime/13.04 instead
[19:01] <cyphermox> mterry: all good, it's my stack anyway :)
[19:01] <seb128> cyphermox, thanks
[19:01] <seb128> https://code.launchpad.net/~seb128/indicator-datetime/systemd-packaging-update/+merge/155585
[19:01] <seb128> target updated
[19:01] <cyphermox> seb128: how did you do this so fast?
[19:01] <cyphermox> I'm curious ;)
[19:02] <seb128> clicked "resubmit" in the launchpad web ui
[19:02] <seb128> changed the target, pressed the button
[19:02] <seb128> I did base my work on the right vcs
[19:02] <seb128> just launchpad ui got it wrong
[19:03] <cyphermox> oh, of course
[19:03] <cyphermox> duh
[19:04] <cyphermox> hmm
[19:04] <cyphermox> desrt's branch is failing to build, but not due to his changes
[19:32] <cyphermox> seb128: there's a conflict, can you fix it?
[19:47] <seb128> cyphermox, hey, was away for dinner, sure ... should I just merge the fixes into one mr?
[19:47] <cyphermox> or update the current
[19:48] <cyphermox> I'm still running desrt's branch in sbuild to make sure it's good despite what jenkins things
[19:48] <cyphermox> *thinks
[19:48] <cyphermox> it's just about done, running dh_makeshlibs
[19:53] <cyphermox> approved desrt's branch
[20:10] <seb128> cyphermox, what was the conflict?
[20:11] <seb128> cyphermox, jenkins said I forgot the commit message
[20:11] <seb128> oh, changelog, I see
[20:11] <cyphermox> ah it's good, it was saying text conflict in debian/changelog
[20:12] <seb128> cyphermox,
[20:12] <seb128> https://code.launchpad.net/~seb128/indicator-datetime/systemd-packaging-update/+merge/155585
[20:12] <seb128> updated
[20:12] <cyphermox> aye
[20:20] <cyphermox> seb128: approved, should get merged soon
[20:20] <cyphermox> release tomorrow, you know, all of that :)
[20:20] <seb128> cyphermox, thanks, I hope so, I'm uploading the other bits ;-)
[20:21] <cyphermox> hehe :)
[20:21] <seb128> they breaks on indicator-datetime << today
[20:21] <seb128> so the transition should stay in proposed until indicators land
[20:21] <cyphermox> like I said, will land tonight... should we make that go faster?
[20:21] <seb128> no, that's fine
[22:05] <seb128> cyphermox, hey again
[22:06] <seb128> cyphermox, can we get indicator-datetime to autoland?
[22:43] <seb128> cyphermox, sorry, unstable connection tonight here
[22:43] <seb128> cyphermox, can you get indicator-datetime to land?
[22:43] <seb128> I think I broke raring installability with my upload
[22:43] <seb128> the britney checks don't include ubuntu-destkop installability
[22:44] <seb128> so breaks don't block migration


[00:40] <ESphynx> xnox: awesome, it's in proposed :) Failed to build on ppc... Are those PPC builds 64 bit ? I'm guessing not?
[00:41] <xnox> ESphynx: it's 64bit kernel, but 32bit user-space.
[00:41] <ESphynx> I'm guessing amd64 is more important than ppc support?
[00:42] <ESphynx> I need to get myself the latest PPC mac or something :)
[00:42] <xnox> ESphynx: it failed in debian as well. https://buildd.debian.org/status/package.php?p=ecere-sdk&suite=experimental
[00:42] <ESphynx> I have a Sun sparc machine here that I haven't even tried to fire up too...
[00:42] <ESphynx> xnox: you mean ppc ?
[00:43] <xnox> ESphynx: i think i have access to porter box which is powerpc via debian network.
[00:43] <xnox> ESphynx: yeah, powerpc.
[00:43] <ESphynx> .03 worked on PPC :|
[00:44] <ESphynx> I'm gonna have to setup this SunSparc and test there with Big Endian...
[00:44] <xnox> ESphynx: yeah. And because it did, britney will not migrate ecere-sdk from raring-proposed to release.
[00:44] <ESphynx> it won't?
[00:44] <ESphynx> arg
[00:44] <xnox> ESphynx: on raring, you can do: mk-sbuild --arch powerpc
[00:45] <ESphynx> what does that do? run an emulator of some sort?
[00:45] <xnox> and that is suppose to setup a minimal chroot of powerpc with qemu-static binary. Thus you will get powerpc user-space and everything will be executed via qemu so will be very slow.
[00:46] <ESphynx> yeah... What are these PowerPC machine usually?
[00:46] <ESphynx> old macs?
[00:46] <xnox> on quantal there were reports that it doesn't work, segfaults and stuff.
[00:47] <ESphynx> Since I upgraded my PS3, I guess I can't setup Linux on there anymore either :S
[00:47] <xnox> ESphynx: old macs, and very nice IBM machines, or http://www.servergy.com/ servers.
[00:49] <ESphynx> xnox: i'm going to try to bid on a mac on ebay... for now I could try to get it going on this Sunsparc which is also big endian
[00:49] <ESphynx> xnox: Is there a way I can re-run a test build on Launchpad?
[00:49] <ESphynx> (Also, this is a major downer if it prevents .05 to be migrated to Raring :( any way around it?
[00:50] <xnox> ESphynx: i am ubuntu core dev, so i can hit a button to rebuild, but there is no shell access to distro builders / nor a way to manually run stuff.
[00:50] <xnox> one can only have PPAs (which are virtualised xen instances anyway)
[00:51] <ESphynx> xnox: just for testing the build once I believe I fixed it
[00:51] <ESphynx> i.e. if I get the same segfault on the sunsparc and fix it... I'd like to test it again
[00:51] <xnox> ESphynx: for that we can just upload. Some people do fix armhf/powerpc "blind" (e.g. without access to hardware to test)
[00:52] <xnox> ESphynx: i'm not sure how your build-logs will help you though, they are not verbose at all (they should be very verbose, especially for cases like this one)
[00:52] <ESphynx> xnox : I know what happened..
[00:53] <ESphynx> the boostrap ecp crashed trying to precompile ear.ec
[00:53] <ESphynx> which is probably due to a difference in struct size and/or alignment on PowerPC
[00:53] <ESphynx> goign to try to setup my Sunsparc this week
[00:54] <ESphynx> but I wished .05 could still make it into raring despite that :|
[00:54] <ESphynx> the number of AMD64 users is surely much greater than the number of PPC usesr?
[01:44] <ESphynx> well at least it built on armhf :P
[02:00] <aboudreault> Hi. I'm trying to fix that error: dpkg-shlibdeps: warning: couldn't find library libdnds.so needed by debian/dnds-client/usr/bin/dnc (ELF format: 'elf64-x86-64'; RPATH: '')
[02:01] <aboudreault> libdnds is build in this package too.
[04:51] <ESphynx> oh, guess I could always try to run it through Rosetta!
[04:51] <ESphynx> dunno if it's still supported on Lion though :|
[07:55] <dholbach> good morning
[11:13] <aboudreault> Hi. I'm trying to fix that error: dpkg-shlibdeps: warning: couldn't find library libdnds.so needed by debian/dnds-client/usr/bin/dnc (ELF format: 'elf64-x86-64'; RPATH: '')
[11:13] <aboudreault> libdnds is build in this package too.
[11:14] <geser> where does it get installed (during package build)?
[11:31] <aboudreault> geser, my make install install it in debian/tmp/usr/lib
[12:37] <aboudreault> geser, just in case you answer, haven't seen it. got disconnected from the bnc. it not, just ignore this message ;)
[12:49]  * Rhonda helpfully points aboudreault at http://irclogs.ubuntu.com/  :)
[12:50] <Rhonda> (updated hourly)
[12:51] <aboudreault> ;)
[12:56] <tumbleweed> I wish they were closer to real-time
[13:07] <xnox> Now that LoganCloud is motu, you should be sponsoring the hoards of uploads by mitya57
[13:07] <xnox> =))))
[19:15] <tumbleweed> diogobaeder: https://wiki.ubuntu.com/UbuntuBackports
[19:15] <diogobaeder> tumbleweed, thanks! :-)
[19:24] <diogobaeder> tumbleweed, so, I just have to issue a "requestbackport" and throw in the information regarding the version I need to have backported?
[19:26] <tumbleweed> yup, and explain why you want it backported
[19:27] <diogobaeder> tumbleweed, ah, nice, thanks :-)
[19:33] <diogobaeder> tumbleweed, do I need to do the testing now, and fill the checklist as I test?
[19:33] <diogobaeder> Or should I just fill in the description?
[19:33] <tumbleweed> or you can do it later
[19:33] <tumbleweed> but it has to happen
[19:35] <diogobaeder> tumbleweed, OK. I'll just send with the description, so that I can prepare my environment for the testing. Is it a good idea to setup an LXC container for each release, in order to test for each release I asked the backport for?
[19:35] <tumbleweed> that works
[19:36] <tumbleweed> chroots are enough for testing almost everything, though
[19:37] <diogobaeder> tumbleweed, do you think it would be easier with plain chroots than with LXC?
[19:38] <tumbleweed> most of us have chroots because we use them for building
[19:38] <tumbleweed> whatever is convenient
[19:38] <Unit193> And some of us have several, and use pbuilder.
[19:39]  * diogobaeder goes search what pbuilder is
[19:39]  * tumbleweed prefers sbuild (which means schroot)
[19:39]  * diogobaeder goes search how to use sbuild as well
[19:41] <Unit193> I really shouldn't be doing parallel builds on this computer.
[22:02] <chilicui1> Hi there, so if I want to migrate one package from using init.d to upstart I just add package.upstart to the debian/ dir?


[00:00] <alex_mayorga> hggdh: Thanks on looking BTW, I really appreciate it
[00:00] <alex_mayorga> hggdh: should I nuke the i386 packages?
[00:00] <hggdh> alex_mayorga: I do not know why they were installed, so I cannot really answer. I do not have them in my system, though
[00:01] <hggdh> another thing you can try is to bring down the amd64 ones to the same version as the i386 (apt-get install libattr1=1:2.4.46-5ubuntu1
[00:01] <alex_mayorga> I'd blame skype, but I don-t know any better really
[00:02] <hggdh> ah, maybe skype indeed
[00:02] <hggdh> but now I do have to go
[00:02] <alex_mayorga> E: Version '1:2.4.46-5ubuntu1' for 'libattr1' was not found
[00:03] <alex_mayorga> hggdh: It could wait I believe, the laptop still boots as is
[00:03]  * alex_mayorga wonders if another bug should be filled
[21:26] <idx0> iam using ubuntu 12.04 lts.when i close the lid of my computer it suspends and i program it from power manager do nothing
[21:40] <zh> idx0: So it actually suspends, or is it coming up with a mostly black screen asking for your password? You can turn off the lock screen in the brightness settings.
[21:41] <idx0> zh:when iam closing the lid the screen comes blank when iam open the lid again it ask for the password
[21:43] <zh> idx0: Sorry, I'm having a hard time understanding that sentence.
[21:44] <idx0> when iam closing the lid it suspends
[21:44] <idx0> when iam opening the lid again it ask for a password
[21:52] <zh> Well if it's not the lock screen then you should check LaunchPad, sounds like Bug #1022655, it's fairly new so you may want to suscribe to it for updates.
[21:52] <ubot2> Launchpad bug 1022655 in gnome-power-manager "Suspend on laptop lid close is off but still suspends" [Undecided,New] https://launchpad.net/bugs/1022655
[21:52] <zh> Gnome-power-manager is what handles it, here's the package page on LP: https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager


 https://lists.launchpad.net/kubuntu-council/msg00889.html
 I think so @RikMills though having an invoice would be good.
 Yeah, that has to be really
 See: https://jriddell.org/2022/08/26/kde-snap-packages-now-on-arm-and-kde-invent-ci/
 @Mamarok @Rick_Timmis @valorie @tsimonq2
[14:59] <Mamarok> +1 from me, with an invoice
[15:02] <RikMills> to be clear from me...
[15:02] <RikMills> +1 with an invoice
[15:02] <RikMills> also
 Can you +1 rather than 'think so' ;) (re @ahoneybun: I think so @RikMills though having an invoice would be good.)
 If that is ok
 +1 from me with invoice as well.
[15:08] <RikMills> ty :)
[19:20] <valorie> yes to the Pi!
[19:22] <valorie> +1
 +1 on the Pi for Scarlet
[19:30] <RikMills> kool. looks like that is carried :)
[20:11] <valorie> off to give blood


[01:12] <astory> Hi, I'd like to install a firefox extension on a fleet of Lucid machines, and the docs on packaging led me here.  Is there a way to package a .deb that still supports automatic (non-deb) updating?  It's unclear whether this is possible from the docs.
[12:59] <BUGabundo> bRoas
[16:58] <gnomefreak> it looks like thunderbird is installed by default :)  it replaced evo :)
[17:45] <chrisccoulson> oh, gnomefreak only just noticed that? we added it in dublin ;)