[15:40] <jrwren> DNS Cache Locking is a nice windows server feature. I'm not aware of equiv for any Linux DNS server.
[16:58] <jrwren> Noble Numbat (24.04) Kernel Feature Freeze already!
[16:58] <jrwren> pretty cool that this LTS is going to ahve 6.8 kernel


[00:23] <borix> hmm, not many users online
[00:23] <borix> just a question for the interested: I am currently using a Toshiba Satellite A series laptop running on WinXP
[00:24] <borix> I intend to install Ubuntu 9.10. Are there any known issues?
[00:24] <borix> if not or not yet, how can be of help in testing Ubuntu 9.10 in my Toshiba laptop?


[03:27] <FuLgOrE> rsalveti: because ogra is not here, do you know about the changes regarding mounting /persist in the new 4.4er images? It's not working, maybe we can have a look
[03:28] <FuLgOrE> also brightness control doesn't work
[04:59] <Mirv> chrisccoulson: see the specific instructions I posted on ubuntu-phone
[04:59] <Mirv> chrisccoulson: the touch multimedia fork packages don't clean themselves up, that's why
[05:21] <Mirv> (or https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta2 front page)
[06:51] <danny> will it be possible to run ubunto desktop apps on ubunto tablets?
[06:53] <danny222112> is it possible to run desktop apps on ubunto tablets?
[07:02] <tvoss> pitti, good morning :)
[07:02] <pitti> hey tvoss, how are you?
[07:02] <tvoss> pitti, pretty good, thank you :) travel was unevent-ful
[07:03] <tvoss> pitti, how are you?
[07:03] <pitti> tvoss: oh, you are already in London?
[07:03] <tvoss> pitti, oh, I spent Monday to Wednesday in London, now back home and in Brussels on Saturday
[07:04] <pitti> tvoss: ah, see you at FOSDEM then?
[07:04] <tvoss> pitti, I would think so :)
[07:04] <tvoss> pitti, when is your talk?
[07:05] <pitti> tvoss: I don't have any; I'm primarily going there to meet a few people again, I didn't really prepare much
[07:05] <pitti> tvoss: going there on my own dime and staying at a friend's in Leuven
[07:05] <tvoss> pitti, ah, now that's cool :)
[07:33] <dholbach> good morning
[07:44]  * FuLgOrE is available for testing on hammerhead
[08:07] <infinity__> need to know can i install ubuntu on my samsung galaxy note??
[08:08] <infinity__> is it stable can any one guide about this
[08:21] <pitti> lool: bonjour
[08:45] <M4dH4TT3r> support mips
[08:53] <pitti> xnox: hey Dimitry, already awake?
[08:58] <xnox> pitti: morning! Yes =) we are all in the office.
[08:58] <xnox> pitti: what's up? unless you are after ftpmaster.internal...
[08:58] <pitti> xnox: ah; good morning; I might have a question about your recent cmake upload, but need to verify something first
[08:59] <pitti> recently, "export CXX=g++-4.7" in debian/rules stopped working
[08:59] <pitti> which is why platform-api is now 'orribly broken
[08:59]  * pitti downgrades to previous cmake to verify
[09:00] <xnox> pitti: yeah, my cmake changes do not work with CXX=g++-4.7 =/
[09:00] <pitti> so, what I don't understand:
[09:00] <xnox> pitti: you can do -DCMAKE_C_COMPILER=gcc-4.7 -DCMAKE_CXX_COMPILER=g++-4.7
[09:00] <xnox> pitti: at the dh_auto_configure call, and that should work.
[09:00] <pitti> mkdir obj; cd obj; CXX=g++-4.7 cmake ..
[09:00] <pitti> that works
[09:00] <pitti> but above export doesn't (through dh_auto_configure)
[09:01] <xnox> pitti: right, my "crazy" patch-sets keys on variables exported by dpkg-architecture
[09:01] <pitti> argh
[09:01] <pitti> is that backwards compatible?
[09:01] <xnox> pitti: so CXX=g++-4.7 dpkg-architecture -aamd64 -c cmake => is probably broken at the moment.
[09:01] <j-b> 'morning
[09:02] <xnox> pitti: it's not backwards compatible with some existing debian/rules files, indeed.
[09:02] <pitti> xnox: I mean the -D syntax
[09:02] <xnox> pitti: why is platform-api using 4.7? to match hybris / android.
[09:02] <pitti> yes, 4.8 changed the float return ABI
[09:02] <xnox> pitti: -D is the standard cmake interface to provide configuration variables since forever.
[09:02] <pitti> it's apparenlty planned to change that soon, but it hasn't happened yet
[09:02] <pitti> xnox: yes, but export CXX has been the standard way for pakcages to set the compiler :)
[09:03] <pitti> xnox: anyway, that works for now; thanks
[09:03] <pitti> xnox: I take it  that is to be considered a workaround?
[09:03] <xnox> pitti: yeah, i guess i should invest into fixing / supporting $ENV{CXX}
[09:04] <pitti> at least we have something that unblocks that now
[09:04] <pitti> wow, that kept some four or five people busy for some hours :0
[09:04] <xnox> pitti: do you have more details about the "4.8 changed the float return ABI"? first time i hear about it.
[09:05] <pitti> xnox: I'm only parrotting, I'm afraid
[09:05] <xnox> pitti: well.... CMAKE_C_COMPILER / CMAKE_CXX_COMPILER are the _cmake standard_ way of setting compilers.... ;-)
[09:05] <pitti> xnox: but the effect is, if I build platform-api with 4.8 (which is what happened without us noticing), float return values are absolutely wrong
[09:05] <pitti> $ ./showsensors
[09:05] <pitti> accel: min 0 max 39.2266 res 0.00119019
[09:05] <pitti> ^ with current platform-api in trusty
[09:06] <pitti> accel: min 3.56854e+21 max 2.82612e+20 res 2.82612e+20
[09:06] <pitti> ^ with rebuilt platform-api (no change)
[09:06] <pitti> fortunately that has been caught by its new tests
[09:09] <pitti> didrocks: found it!
[09:09] <pitti> didrocks: err, "bonjour"
[09:09] <didrocks> pitti: \o/
[09:10] <didrocks> pitti: do you have a bug for it? I'm interested in the diff anyway
[09:10] <pitti> didrocks: and never again blame my tests! :-)
[09:10]  * didrocks hugs pitti
[09:10] <didrocks> I didn't blame your tests :p
[09:10] <pitti> didrocks: (just kidding)
[09:10] <pitti> didrocks: filing one now
[09:10] <pitti> didrocks: diff: http://paste.ubuntu.com/6842713/
[09:10] <pitti> didrocks: tvoss is applying it to his MP directly
[09:11]  * didrocks looks
[09:11] <pitti> didrocks: we were building with g++-4.8 without noticing
[09:11] <didrocks> perfect!
[09:11] <didrocks> oh
[09:11] <pitti> didrocks: I wrote a little test program that shows the actual (real iron) sensor data, and it was broken just the same way
[09:11] <pitti> didrocks: i. e. the tests were exactly right
[09:13] <didrocks> pitti: waow, it was an interesting… side-effect
[09:13] <didrocks> pitti: we are trying to release Mir, including platform-api
[09:13] <didrocks> I would appreciate a separate MP that we can bundle with the current rebuilds
[09:13] <didrocks> (if possible)
[09:14] <pitti> didrocks: but it won't build
[09:15] <didrocks> pitti: oh?
[09:15] <pitti> didrocks: as we don't have the previous dbus-cpp any more
[09:15] <pitti> didrocks: so we actually need to land
[09:15] <M4dH4TT3r> support mips
[09:15] <pitti> https://code.launchpad.net/%7Ethomas-voss/location-service/add_controller_and_service_configuration/+merge/199105
[09:15] <cyphermox> ChickenCutlass: https://code.launchpad.net/+branch/~mathieu-tl/+junk/nm-mms-support
[09:15] <didrocks> pitti: hum, it did build yesterday on the branch we sil2100 bundled ^
[09:15] <M4dH4TT3r> and gay marrige
[09:15] <didrocks> maybe this branch was part of the request
[09:15] <pitti> and https://code.launchpad.net/~thomas-voss/platform-api/expose_accuracy_and_service_status_to_platform/+merge/203298
[09:15] <pitti> didrocks: yes, that's what sil2100 told me
[09:15] <pitti> didrocks: hence tvoss will add the workaroud to the latter MP
[09:15] <tvoss> pitti, didrocks https://code.launchpad.net/~thomas-voss/platform-api/expose_accuracy_and_service_status_to_platform is updated
[09:15] <sil2100> pitti, didrocks: all was fine in our PPA, right?
[09:16] <sil2100> pitti: is the platform-api test issue fixed?
[09:16] <sil2100> :)
[09:16] <pitti> sil2100: yes
[09:16] <didrocks> sil2100: can you backlog first? :p
[09:16] <pitti> sil2100: http://bazaar.launchpad.net/~thomas-voss/platform-api/expose_accuracy_and_service_status_to_platform/revision/188 is the fix, tvoss just committed it
[09:16] <sil2100> \o/
[09:16] <pitti> sil2100: ugh, that was really confusing
[09:16] <didrocks> sil2100: apparently, it will fail to build though without tvoss's branch (what you didn't get in the ppa yesterday)
[09:16] <sil2100> Ok, so let me spin things!
[09:16] <pitti> sil2100: my tests showed a real problem \o/ :)
[09:16] <didrocks> pitti: nice catch btw, yeah, more than confusing :p
[09:17] <sil2100> didrocks: no proooblem, it's all under control
[09:17] <tvoss> pitti, didrocks we should file a bug against the cmake package in distro, too
[09:17] <sil2100> pitti, tvoss: just give me a moment and it will be all fine
[09:17] <pitti> tvoss, didrocks, sil2100, xnox : bug 1274430
[09:17] <M4dH4TT3r> really want ubuntu touch on my tablet
[09:17] <pitti> sil2100: let's please wait on the jenkins CI run on tvoss's updated branch, just to make sure?
[09:17] <xnox> pitti: i'll take it.
[09:17] <M4dH4TT3r> mips architecture
[09:18] <pitti> xnox: thanks
[09:18] <pitti> sil2100: but you can land https://code.launchpad.net/~thomas-voss/location-service/add_controller_and_service_configuration/+merge/199105 in the meantime, I guess
[09:21] <didrocks> pitti: I didn't know sil2100 already bundled tvoss's branch
[09:21] <didrocks> so now I understand :)
[09:21] <xnox> pitti: which package should I test my fix on?
[09:21] <didrocks> thanks again pitti! and well done :)
[09:21] <sil2100> pitti: all stuff will be bundled together, as one big coherent landing - no worries, it's *all* under control ;p
[09:21] <sil2100> pitti: thanks for fixing!
[09:22] <pitti> xnox: you can use current platform-api and check the cmake output; it should say "using g++4.7", not 4.8
[09:22] <xnox>  cool, thanks
[09:23] <pitti> -- The CXX compiler identification is GNU 4.8.2
[09:23] <pitti> xnox: ^ it currently says that
[09:23] <pitti> xnox: beware that current platform-api typoes "export C=gcc-4.7", should be "CC"
[09:24] <pitti> xnox: that's fixed in the MP, but you shold fix it locally to test your fix for CC too
[09:24] <pitti> sil2100: great
[09:24] <xnox> -- Check for working C compiler: /usr/bin/x86_64-linux-gnu-gcc -- works
[09:24] <xnox> -- Check for working CXX compiler: /usr/bin/g++-4.7 -- works
[09:24] <xnox> pitti: ^^^^
[09:25] <xnox> pitti: is that what you'd expect?
[09:25] <pitti> xnox: nice! and with C fixed to CC?
[09:25] <ogra_> rsalveti, bug 1160847
[09:26] <xnox> pitti: well, if CC or CXX or FC are in the environment, the will be honored.
[09:26] <pitti> xnox: right, that already worked
[09:27] <pitti> xnox: but for some reason not if debian/rules passes it through dh_auto_configure
[09:27] <xnox> pitti: that did not work, when running debuild.
[09:27] <xnox> =)
[09:27] <xnox> now it will again.
[09:27] <pitti> xnox: cheers, thanks for the fast fix!
[09:28] <pitti> xnox: not urgent any more for platform-api now, but I don't know know how many other packages use that
[09:28] <xnox> pitti: true.
[09:36] <tvoss> pitti, rsalveti pointed out that forcing gcc-4.7 might break cross build
[09:36] <tvoss> xnox, ^
[09:36] <pitti> tvoss: well, we don't even use gcc in platform-api, but we already force g++-4.7
[09:37] <xnox> tvoss: yes, it will. I can provide a patch to platform-api to do it properly.
[09:39] <xnox> tvoss: if one exports compiler, one should export compiler as $DEB_HOST_MULTIARCH-gcc-4.7 to be cross-compile safe.
[09:40] <cyphermox> ChickenCutlass: sbuild -d trusty -A --arch=armhf network-manager_<IP_ADDRESS>-0ubuntu2~mtrudel2.dsc
[09:42] <mardy> mzanetti, dpm: OK, so using the Evernote QML plugin I manage to get the username in the account plugin
[09:42] <mzanetti> mardy: \o/
[09:42] <dpm> excellent
[09:42] <mardy> mzanetti, dpm: is if OK if I file a merge proposal to merge the account plugin into the reminders app?
[09:43] <dpm> mardy, +100 (althouth I'd like to hear mzanetti's opinion)
[09:44] <cyphermox> ChickenCutlass: mk-sbuild trusty --arch=armhf
[09:44] <mzanetti> dpm: mardy: add another 100 :)
[09:44] <mardy> dpm, mzanetti: actually, I'm not sure how this would work with click; can we generate two click packages from the same repository?
[09:44] <mzanetti> mardy: thanks a lot. You're helping alot
[09:44] <mzanetti> mardy: yeah, we can
[09:44] <mardy> mzanetti: glad to be of help :-)
[09:45] <mzanetti> mardy: but: can we install account plugins through clicks already?
[09:45] <dpm> mardy, but we still can't run online account plugins off click, right? Wouldn't we build a debian package instead?
[09:45] <mzanetti> mardy: I thought that stuff still needs to be seeded with deb's
[09:45] <dpm> yeah, my thoughts too
[09:46] <mardy> mzanetti, dpm: right, currently we don't support having account plugins in click packages, but that will change soon
[09:46] <dpm> mardy, ack. Depending on how soon, we might still need to build a .deb package during the transition
[09:46] <mardy> mzanetti, dpm: however, you are right, it's probably better to wait for that to land, before merging the plugin
[09:46] <mzanetti> mardy: so given that click packages don't have any build recipe, we can do whatever we want
[09:46] <dpm> yeah
[09:47] <mzanetti> mardy: no... we can generate 2 debs from the repo too
[09:47] <mzanetti> please go ahead
[09:47] <mzanetti> mardy: just one thing: Check out the CMakeLists and in CLICK_MODE add install steps to install all of the plugins stuff to a separete new directory
[09:48] <mzanetti> then we can just add a second click create command for the second dir and we're good to go
[09:48] <mzanetti> right now we're also building .debs out of the app too
[09:48] <mzanetti> so everything is in place already
[09:50] <mardy> mzanetti: so, when the project is built as a deb, we should build: qtdeclarative-evernote-module, account-plugin-evernote and reminders app (with the latter to depending on the first). Correct?
[09:51] <mardy> mzanetti: when it's built as click packages, the qtdeclarative-evernote-module should be embedded in both the account plugin and reminders app
[09:51] <mzanetti> mardy: I for one wouldn't install the plugin as a module tbh
[09:51] <mzanetti> even with debs
[09:52] <tvoss> xnox, ack and thanks
[09:52] <mzanetti> mardy: hmm... well... given the fact we're sharing it between the plugin and the app... ok...
[09:52] <mardy> mzanetti: I'm not sure how we can install it in two debs... I guess I'll have to play with cmake a bit (I don't know cmake)
[09:53] <mzanetti> mardy: imo we should install it in the app/plugins data dir and set qml's import path to it
[09:53] <mzanetti> mardy: let me know if you need help with cmake
[09:54] <ChickenCutlass> cyphermox, http://pastebin.ubuntu.com/6842903/
[09:57] <barry> xnox: https://code.launchpad.net/~chris.gagnon/ubuntu-ui-toolkit/autopilot-python3-package/+merge/196358
[10:08] <tvoss> xnox, I think that it would make sense to fold the fix into https://code.launchpad.net/~thomas-voss/platform-api/expose_accuracy_and_service_status_to_platform
[10:11] <barry> xnox: https://code.launchpad.net/~chris.gagnon/ubuntu-ui-toolkit/autopilot-python3-package/+merge/196358/comments/476068
[10:23] <pitti> kalikiana, tvoss: I analyzed the crash in bug 1272294 and followed up with two possible solutions for fixing platform-api; do you have a particular preference, or should I just go with what I think is best?
[10:32] <mzanetti> dpm: hey, I think sergiusens is fine with that branch. I didn't change his stuff a lot anyways. can we get it landed?
[10:32] <mzanetti> the cleanup one, that is
[10:32] <xnox> fginther: what's up?
[10:33] <xnox> ogra_: what's up?
[10:33] <dpm> mzanetti, sounds good to me. I can top-approve if you want
[10:33] <mzanetti> dpm: please
[10:33] <ogra_> xnox, we need to move around the developer mode meeting
[10:33] <dpm> mzanetti, done
[10:34] <xnox> ogra_: =/
[10:34] <xnox> ogra_: sorry.
[10:35] <ogra_> xnox, looks like many people have conflicts today ... would tomorrow at the same time work for you ?
[10:37] <xnox> ogra_: i only had this meeting on the Ubuntu Core calendar.
[10:37] <xnox> ogra_: if you want me to be somewhere, it should be on the Ubuntu Core calendar =/ maybe ask michelle about it?
[10:38] <ogra_> xnox, moved to tomorrow, same time now
[10:38] <Laney> might come say hi at the office tomorrow
[10:38] <Laney> if i can get in early enough on my "super off peak"
[10:38] <ogra_> Laney, DOIT !
[10:38] <xnox> ogra_: today at 4:30 -> 6 ?
[10:38] <ogra_> xnox, bah, paperwork
[10:38] <Laney> eurostar to brussels is at ~1530
[10:38] <xnox> ogra_: tomorrow at 11 is free so far.
[10:39] <mardy> mzanetti: OK, question time (cmake): I need to define a couple of string variables in debian/rules (for the OAuth application key/secret), and make the available to cmake (which will use them in a configure_file)
[10:39] <ogra_> xnox, perfect
[10:39] <mardy> mzanetti: is it just -DVARIABLE="xxx"?
[10:40] <mzanetti> mardy: yeah, can do that
[10:40] <mardy> mzanetti: OK. By the way, I'm currently working on making the account plugin as a deb; I'll worry about the click build only once we actually support it
[10:41] <mzanetti> mardy: ok. I guess I can take care about the click too at some point. no worries about that
[10:41] <mzanetti> mardy: make sure everything builds fine when calling cmake with -DCLICK_MODE=1
[10:42] <Laney> could get there for 12ish
[10:46] <tvoss> pitti, looking at 1272294
[10:47] <tvoss> pitti, I would prefer the explicit call to check if a backend is available. I would like to keep the inner workings of IMPLEMENT_FUNCTION0 an implementation detail
[10:47] <tvoss> greyback, hey there
[10:47] <pitti> tvoss: you mean don't interpret a NULL return value as error?
[10:47] <greyback> tvoss: yo, just saw your reply to the MR
[10:47] <pitti> tvoss: still a bit sad that ua_sensors_accelerometer_new() just crashes then on platforms that don't have sensors
[10:48] <pitti> tvoss: well, we could at least make it an assertion then?
[10:48] <mardy> mzanetti: should I just re-approve this? https://code.launchpad.net/~mardy/reminders-app/register-error/+merge/203900
[10:48] <tvoss> pitti, sure, I would think that we could make _new() a bit more robust and don't use the macro to implement it
[10:49] <pitti> tvoss: that would copy&paste a lot of code
[10:49] <mzanetti> mardy: I will take care of it... the cleanup branch needs to land first
[10:49] <tvoss> pitti, sure, but you cannot always return NULL for IMPLEMENT_FUNCTION0 as it depends on the return type
[10:49] <pitti> tvoss: I'd actually think we should make a new macro like IMPLEMENT_FUNCTION0_NULLERR or so?
[10:50] <tvoss> pitti, that makes sense
[10:50] <pitti> tvoss: i. e. a new macro that we use for the constructors
[10:50] <pitti> tvoss: or just straight IMPLEMENT_CONSTRUCTOR0 (0 for zero args)?
[10:50] <tvoss> pitti, exactly, and consumers of the API have to check for errors
[10:50] <pitti> tvoss: right; but we currently define error as "returns NULL"
[10:50] <tvoss> pitti, I think an explicit CTOR macro is self-explaining
[10:51] <pitti> tvoss: ack, doing that then; thanks!
[10:51] <tvoss> pitti, yup :) thanks for the help
[10:51] <pitti> tvoss: yeah, that's indeed a bit annoying; it immediately crashes QtCreator on a desktop, which is a bit sad for app development
[10:52] <tvoss> yup
[10:54] <mardy> mzanetti: I cannot see how the icon is getting installed; is ICON a magic variable?
[10:55] <dpm> mzanetti, would you have some time today to create a click package from the latest branch of reminders and send it to Dani? I'm not sure if popey or I would manage today, and that would help Dani playing with the latest changes
[10:57] <mardy> mzanetti: forget it, I think I found how it works (installs it with SRC_FILES) ^
[11:01] <mzanetti> re
[11:02] <mzanetti> mardy: ok. let me know if there are any more things
[11:02] <mzanetti> dpm: ok
[11:03] <dpm> mzanetti, great, thanks. I'll then tell Dani to find someone in the office to help him install it from the command line
[11:03] <mzanetti> vesar: can you? ^
[11:08] <ogra_> FuLgOrE, so there is still an issue with the package publishing ... the /persist mount should be in the new zip i just published, powerd (brightness stuff) still is not
[11:08] <FuLgOrE> ok I see
[11:08] <FuLgOrE> thx, I will download and try immediately :)
[11:10] <ogra_> FuLgOrE, argh, seems i'm wrong, the persist stuff didnt make it either
[11:11] <vesar> mzanetti, sure I can
[11:11] <FuLgOrE> anything else to test?
[11:13] <mzanetti> dpm: however, the camera branch and the reminders branch are not reviewed yet
[11:13] <mzanetti> WebbyIT: hey ho! You can now go ahead and approve the textformat branch
[11:14] <FuLgOrE> ogra_: should I try something else on hammerhead?
[11:14] <WebbyIT> mzanetti, \o/
[11:15] <ogra_> FuLgOrE, well, the new zip has no changes at all ... we need to wait til the infrastructure is fixed
[11:15] <WebbyIT> mzanetti, last night I thinked about RTF format: well, there are much case I had not considered in first place, in next days I'll update you
[11:15] <ogra_> i'll do a rebuild as soon as that happened ... but i dont know when that will be
[11:15] <ogra_> (zip build takes ~70 min)
[11:16] <FuLgOrE> ogra_: okay, than I keep the "old" image on my phone
[11:16] <mzanetti> WebbyIT: yep, I guess there are a ton of corner cases, however, I guess we'll always hit them... writing a WYSIWYG editor is a tricky task
[11:17] <FuLgOrE> I guess we cannot do that on my hardware, right?
[11:18] <dpm> mzanetti, I think it's fine to pass him the camera and reminders branch, if it's just to test the UX. At least the camera branch was working for me the first time you submitted it, and for the latest changes perhaps we can actually have Dani as a tester :)
[11:18] <WebbyIT> mzanetti, Jenkins is not happy about your branch. If I top approve it, will tests run again?
[11:19] <dpm> mzanetti, but if you feel you shouldn't put them in the .click package, it's your call
[11:19] <mzanetti> WebbyIT: yes. if you want we can trigger ci first
[11:19] <mzanetti> dpm: no, its fine
[11:19] <WebbyIT> mzanetti, np, I top approve it
[11:19] <dpm> ok, cool
[11:29] <mzanetti> WebbyIT: hey, can you create a merge which reverts your fix again please?
[11:29] <mzanetti> WebbyIT: given that the bug it fixes is less bad than the bug it introduces :)
[11:30] <WebbyIT> mzanetti, yes, sure
[11:30] <mzanetti> thanks
[11:30] <mzanetti> I'd say we just get rid of the back button in the edit note and make the user always go through save, just like evernote itself does
[11:30] <mzanetti> dpm: ^
[11:35] <WebbyIT> mzanetti, https://code.launchpad.net/~rpadovani/reminders-app/revert-1273102/+merge/203926
[11:45] <mzanetti> WebbyIT: dpm: https://bugs.launchpad.net/reminders-app/+bug/1273102/comments/2
[11:45] <WebbyIT> mzanetti, I think it's a good idea to align our app to evernote one
[11:54] <pitti> tvoss: ok, working nicely now; I attached MP/patch, but it's blocked by landing your platform-api branch first
[11:54] <tvoss> pitti, ack
[11:55] <tvoss> sil2100, any update?
[11:55] <pitti> (no hurry from my side, that's just an FYI or if you have a minute to pre-review)
[11:56] <sil2100> tvoss: so... platform-api built fine in the slot PPA, but I'm waiting for mir armhf to finish
[11:56] <tvoss> sil2100, ack
[11:56] <sil2100> tvoss: the unit tests for this platform take really long, I wonder if it's supposed to be like that
[11:59] <popey> sergiusens: http://paste.ubuntu.com/6843404/ - what am I doing wrong here? trying to get a really old image from my mirror...
[12:00] <sergiusens> popey, use ubuntu-device-flash ;-)
[12:00] <pitti> sil2100: no, unit tests for platform-api are supposed to take < 2 seconds really
[12:01] <pitti> sil2100: I just built it a few times on my nexus 4, for above bug
[12:01] <tvoss> pitti, I think sil2100 refers to the mir tests
[12:01] <pitti> ah sorry
[12:01]  * pitti STFU
[12:01] <sergiusens> popey, I'm not sure tbh; let me look
[12:01] <tvoss> sil2100, not sure about testing time tbh
[12:02] <tvoss> sil2100, they certainly take some time but they shouldn't run fo rages
[12:02] <popey> sergiusens: alan@deep-thought:~$ ubuntu-device-flash -channel="trusty-proposed" -revision=45 -server="http://popey.mooo.com/mirror/system-image.ubuntu.com"
[12:02] <popey> 2014/01/30 12:02:07 Device is |mako|
[12:02] <popey> 2014/01/30 12:02:09 Failed to locate image 4
[12:02] <popey> there's a 5 there, but I mis-copied
[12:05] <sil2100> ;/
[12:06] <sergiusens> popey, you don't have Version: "45" in devel-proposed
[12:06] <popey> oh doh, it's in trusty-proposed
[12:06] <popey> thanks
[12:07] <popey> but thats what I specified
[12:07] <popey> sergiusens: and I do.. http://popey.mooo.com/mirror/system-image.ubuntu.com/devel-proposed/mako/ has version-45 in it
[12:08] <sergiusens> popey, what's important is what's in http://popey.mooo.com/mirror/system-image.ubuntu.com/trusty-proposed/mako/index.json
[12:08] <sergiusens> popey, that file itself isn't
[12:09] <popey> bah
[12:09] <popey> can I manually pull the files?
[12:09] <Piotrek_> hi, how much does ubuntu touch uses disk pace? I have nexus 4 and I'm wondering about cyagenomod dual boot with ubuntu touch
[12:18] <ogra_> Piotrek_, 2-3G
[12:19] <Piotrek_> ogra thanks
[12:29] <ogra_> FuLgOrE, looks like the archive is fine again, i started a zip build (in ~70min i should have a new zip ready)
[12:29] <lool> pitti: did you ping?  sorry didn't open IRC this morning!  :-/
[12:29] <FuLgOrE> ogra_: that sounds good! thx
[12:30] <lool> also, my rented server is unstable since yesterday, I might have missed messages yesterday
[12:35] <davmor2> popey, ogra_, sil2100: I'm on holiday and what do you do you break my n4 ;)  have you moved over to the 4.4.2 android base?
[12:36] <ogra_> davmor2, nope, thats still days away
[12:36] <ogra_> davmor2, in fact due to the archive issues we had no changes at all for the last few images
[12:37] <davmor2> ogra_: in that case there might be an issue updated today 29.7mb iirc and now my phone doesn't pass the google logo
[12:38] <davmor2> ogra_: I'll try a full fresh flash and see if that fixes it then
[12:40] <popey> sergiusens: so if I want to manually install http://popey.mooo.com/mirror/cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/20131202/ that on my mako, can I still do that via the instructions at https://wiki.ubuntu.com/Touch/Install#Manual_Download_.26_Installation ?
[12:43] <pitti> lool: it's all good now, the platform-api issue is fixed
[12:46]  * popey tries
[12:47] <mardy> mzanetti: are you using Qt 5.2 in your machine?
[12:47] <mzanetti> mardy: no
[12:48] <mardy> mzanetti: cool. I'll now push my branch somewhere, would be very glad if you tried it; for some reason the reminders-app does not display the account displayName (even though it's there), and I'd be curious to know if this is because of me using Qt 5.2
[12:49] <mardy> mzanetti: or if it's really a bug in my accounts-qml-module
[12:49] <mzanetti> mardy: very unlikely because of 5.2
[12:49] <mardy> mzanetti: agreed; but it's very strange, the data() method in my QAbstractListModel isn't even called
[12:50] <mzanetti> mardy: I'm in the middle of something I'd like to finish first. will try a bit later
[12:52] <roman2861> What about 4.4.2 source code?
[12:57] <mardy> mzanetti: no hurry, I'll investigate
[12:57] <mardy> mzanetti, dpm: meanwhile, I just pushed the MR which brings in the account plugin (which correctly fetches the username)
[12:58] <mzanetti> mardy: cheers
[12:59] <dpm> awesome, thanks mardy. Are you still planning to add the trusted helper once that one gets merged?
[13:00] <mardy> dpm: sure
[13:01] <mardy> dpm: but that will need some coordination, because the trusted helper needs to land at the same time
[13:02] <dpm> mardy, yeah, good point. What's the landing plan for the trusted helper?
[13:04] <mardy> dpm: land as soon as the needed changes to reminders-app and friends-app have been approved :-)
[13:04] <dpm> mardy, that sounds like a great plan to me :)
[13:04] <dpm> mardy, note that reminders-app is not yet in the image, so while coordination is still needed, we're a bit more flexible.
[13:05] <dpm> so it's essentially up to the friends-app changes
[13:06] <davmor2> ogra_: fresh flash of 154 and it's still dead
[13:07] <mardy> dpm: ah, good to know
[13:14] <sergiusens> popey, you need to create an ubuntu_commands file
[13:15] <davmor2> ogra_: I'm flashing 152 now
[13:16] <sergiusens> popey, you can either do a normal flash and get that from where it's logged or you can look at https://wiki.ubuntu.com/ImageBasedUpgrades/Upgrader and follow that
[13:19] <popey> sergiusens: ok
[13:19] <popey> davmor2: 153 is good, 154 is bad
[13:19] <popey> see mailing list
[13:26] <davmor2> popey: cool thanks
[13:47] <FuLgOrE> ogra_: how is the status of your zip?
[13:48] <ogra_> FuLgOrE, my zip has the same issues as image 154 (see the mailing lists)
[13:49] <FuLgOrE> what a pitty
[13:50] <FuLgOrE> is it possible to take your zip and apt-get install libunity-mir1?
[13:53] <ogra_> FuLgOrE, it would be, but i dont really want to publish it like that (there might be people using it that arent as smart as you) ... i'll do a re-build as soon as didrocks and ricmm have uploaded the fix
[14:33] <nirmal> hi
[14:33] <nirmal> i woul like to install ubuntu touch in my Xolo Q800
[14:34] <nirmal> plz help me
[14:34] <nirmal> it has got Arm v7 quad core mediatech processor
[14:51] <elopio> ping barry: still having problems with the toolkit?
[14:51] <barry> elopio: yes, but now my stack is pushed down a few :)
[14:52] <elopio> barry: I asked them yesterday about your error, and they told me kalikiana might know more about it.
[14:52] <barry> elopio: https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1274434
[14:52] <elopio> oh, nice.
[14:53] <elopio> barry: and changing the subject, when is a good date for your py2-3 lightning talk for the QA team?
[14:54] <barry> elopio: yeah, good question!  mid feb?
[14:55] <kalikiana> elopio: what error?
[14:55] <elopio> barry: we are sprinting the week of the 17th. So either the week before, or after that, would be perfect.
[14:55] <elopio> kalikiana: https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1274434
[14:56] <barry> elopio: let's do the week after, the week before is too busy
[14:56] <barry> elopio: mon, tue, wed are all clear
[14:56] <barry> (feb 24,25,26)
[14:56] <kalikiana> elopio: actually I have a question for you: can autopilot verify if the screen is unlocked? https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1259476 was re-opened and I can only reproduce by locking the screen, so I got the idea this would be good to excluse as a non-cause
[14:58] <elopio> barry: ok, lets try wed 26. And 20:30 UTC is a good hour for you? I have no idea what are your working hours, I always find you at a different time.
[14:58] <elopio> kalikiana: you can if you restart unity with testability enabled.
[14:58] <kalikiana> elopio: is that something we can enable in our ci?
[14:59] <barry> elopio: :)
[14:59] <elopio> for my point of view, the toolkit tests should be as independent as possible, so I would prefer if we disable the greeter. But that's a bigger discussion.
[14:59] <barry> elopio: i'll be utc-5 then, so 20:30 is good (if i'm doing my utc math correctly :)
[15:00] <elopio> kalikiana: do you just want to give it a try to get debug information, or would you like to check that always?
[15:01] <elopio> alesage: wed 26th, 20:30 UTC, sounds good for you for the cobertura lightning talk?
[15:01] <alesage> elopio sure that'll be fine
[15:02] <alesage> elopio, thanks for the advance warning
[15:02] <kalikiana> elopio: I have no clue what causes the failure this time except on my device if I lock it. so knowing if that was the reason on Jenkins would narrow it down
[15:02] <elopio> alesage, barry: then we are all set. Thanks :)
[15:02] <barry> elopio: awesome
[15:02] <kalikiana> elopio: the earlier bug was resolved, but we never actually determined if it failed for the reason it was reproducible manually
[15:03] <kalikiana> except it was the exact same result
[15:03] <kalikiana> but now we have the same result again despite the fix
[15:03] <kalikiana> I hope this isn't too confusing
[15:03] <elopio> kalikiana: no, it is not, I'm just thinking.
[15:04] <elopio> kalikiana: so, if you look the device, it will fail because the field doesn't have the focus. You type, and the text goes somewhere else.
[15:04] <elopio> s/look/lock
[15:04] <kalikiana> yes
[15:05] <elopio> kalikiana: so, what if we just add a self.focus.wait_for(True) before righting on the textifield?
[15:05] <elopio> ahh, sorry
[15:05] <elopio> writing
[15:05] <elopio> :) I woke up too early today.
[15:05] <kalikiana> elopio: then it can still fail in the middle of that and we don't know why
[15:05] <kalikiana> and in one mr that indeed was what happened
[15:06] <kalikiana> so you get "foob" != "foobar"
[15:07] <elopio> kalikiana: it will discard the case that we just wrote too fast, before the text field was finishing getting the focus.
[15:07] <elopio> hum, that foob instead of foobar is a pretty different case from est instead of Test, or the empty string.
[15:07] <kalikiana> I don't get that, wrote too fast?
[15:07] <elopio> kalikiana: the thing is that there's no reason for the screen to lock while executing this test. Because you are constantly interacting with the device.
[15:08] <elopio> it's never idle, so it shouldn't look during the execution.
[15:08] <kalikiana> I don't have exact log for the mr which was in the middle of it, but it clearly was losing focus while typing letters
[15:09] <kalikiana> elopio: well, that is a fair assumption. I'm aware that short of any clue what really happens all of this is to narrow down what's left
[15:10] <elopio> kalikiana: I agree. We could just run the command that disables the lock screen on an MP to see if it keeps happening.
[15:10] <elopio> how often do you see this error?
[15:10] <kalikiana> often enough to be very annoying
[15:11] <elopio> ok, then if we rerun the suite on jenkins some times without the lock screen, it should give us better information.
[15:11] <elopio> now I don't remember who told me about how to disable the lock screen.
[15:12] <elopio> Saviq: do you know?
[15:12] <Saviq> elopio, lock screen or suspend?
[15:12] <Saviq> elopio, powerd-cli display bright on
[15:12] <Saviq> elopio, as root
[15:12] <elopio> that's it. oh, but as root. hum...
[15:12] <kalikiana> elopio: we did have plenty of lock screen related issues at some point in the past, that's why I wouldn't just assume it just works
[15:13] <kalikiana> same reason I wanted details on the osk in the logs
[15:14] <elopio> it's so bad that we can't get a screenshot from the phone.
[15:14] <kalikiana> despite the bug fix we get the exact same failures
[15:19] <elopio> kalikiana: for collecting debug information, we can ask CI to set up a job for us that starts killing unity, so we can start it with testability on the test and introspect it. Or that starts with suspend disabled.
[15:20] <elopio> kalikiana: but can we first try the focused.wait_for(True) ?
[15:23] <kalikiana> elopio: well, we can add it to the emulator, it doesn't hurt
[15:25] <tedg> sergiusens, This is a bug that is collecting all the bad icon errors in click packages bug 1267884
[15:25] <tedg> sergiusens, UAL doesn't seem the right place for it to be, is there a better one?
[15:25] <nxvl> hi, has someone tried to install Ubuntu Touch on a tablet?
[15:26] <nxvl> i have a Galaxy Tab (GT-P1010) which i can use to test
[15:26] <sergiusens> tedg, if it's the icons for preinstalled, they all have bug reporting enabled in launchpad
[15:26] <nxvl> or it's focused on Phone and Tablet are not looked for yet?
[15:27] <elopio> kalikiana: I piggybacked it here: https://code.launchpad.net/~elopio/ubuntu-ui-toolkit/fix1274240-gallery-textfield_helper/+merge/203831
[15:27] <elopio> what I hope with that branch is to get a clearer trace in case of error.
[15:28] <elopio> but also, the use of the focused_type context we have in the emulator might solve it.
[15:28] <tedg> sergiusens, I think so...  how does one get apport to report a bug on a click package?
[15:28] <tedg> sergiusens, Is there a click hook for apport config?
[15:30] <sergiusens> tedg, so if you look at vUDS august, ev suggested we used the comments/ratings for click issues and I'm not sure what was decided for direct bug reports
[15:30] <sergiusens> neither is implemented though
[15:31] <sergiusens> tedg, I'll go ask him is he's avail
[15:31] <tedg> I think that makes sense for non-preinstalled clicks
[15:31] <tedg> For pre-installs it seems there should be something different.
[15:34] <djbengan> Hello. What is the "window-manager" called in touch?
[15:35] <FuLgOrE> hey guys. I try to flash AOSP to try to flash ubuntu touch again, but fastboot doesn't work anymore. it cannot see my device. is there a way to activate debug mode in ubuntu?
[15:35] <sergiusens> tedg, so talked to ev; seems to be pitti's domain
[15:36] <FuLgOrE> ah I think I got it
[15:37] <pitti> sergiusens, tedg: we have no apport integration at all (that I'm aware of) for click ATM
[15:38] <sergiusens> pitti, yeah, he just told me that if anything is hooked up, you would know
[15:38] <kalikiana> elopio: makes sense. I just hope it doesn't merely happen to pass. in that case I'd consider re-running it twice to be sure
[15:38] <FuLgOrE> it's working now
[15:48] <cwayne> ogra_: hey, so where do we stand with that lxc-android-config MR? should we wait until we have a better way to do only-first-boot upstart jobs?
[15:52] <popey> cwayne: danielholm is having some trouble with a last.fm online accounts plugin.. would you have some time to help him?
[15:53] <tedg> pitti, Can apport detect if a crash comes from a click package?
[15:53] <cwayne> danielholm: popey: sure, what's up?
[15:54] <pitti> tedg: if there is a counterpart of dpkg -S, or some other way of associating a program to a package, then we can certainly teach it to
[15:55] <pitti> tedg: so far click+apport hasn't been discussed at all yet, and I don't yet know how click works
[15:55] <tedg> cjwatson, Does that exist? ^
[15:55] <tedg> Well, really it should be anything in /opt/click ...
[15:59] <cjwatson> tedg: no
[16:11] <sil2100> pitti: hi!
[16:11] <sil2100> pitti: we're actually getting something like that on our i386 platform-api build now: https://launchpadlibrarian.net/164362983/buildlog_ubuntu-trusty-i386.platform-api_0.20%2B14.04.20140130.1-0ubuntu1_FAILEDTOBUILD.txt.gz
[16:11] <sil2100> It was fine in the morning
[16:13] <pitti> sil2100: hm, interaction with the new cmake again?
[16:13] <pitti> xnox: ^ does that ring a bell?
[16:13] <pitti> i386-linux-gnu-gcc-4.7: not found
[16:13] <pitti> err, what?
[16:13] <xnox> sil2100: already fixed between myself and tvoss
[16:13] <pitti> that looks like a cross-build
[16:13] <xnox> pitti: please ignore.
[16:13] <pitti> ack
[16:13] <xnox> sil2100: why are you pinging about it?
[16:13] <xnox> sil2100: it's a merge proposal at the moment, only.
[16:14] <xnox> sil2100: and pinging not the committer, e.g. tvoss or myself. What pitti has to do with it?
[16:14] <xnox> pitti: DEB_HOST_GNU_TYPE != DEB_HOST_MULTIARCH on i386 on ubuntu.
[16:14] <pitti> well, I was involved in debugging the previous fallout of https://code.launchpad.net/~thomas-voss/platform-api/expose_accuracy_and_service_status_to_platform/+merge/203298 :)
[16:14] <xnox> pitti: which i keep on forgetting.
[16:14] <sil2100> xnox: I'm pinging tvoss, actually talking with him all the time
[16:15] <sil2100> xnox: and I just remembered pitti talking something about that in the morning
[16:15] <pitti> and landing that MP is blocking other stuff and is urgent to fix platform-api, so I'm quite interested in its fate
[16:15] <pitti> sil2100: but it won't succeed anyway until https://code.launchpad.net/~thomas-voss/location-service/add_controller_and_service_configuration/+merge/199105 lands
[16:15] <sil2100> xnox: the current state of platform-api https://code.launchpad.net/~thomas-voss/platform-api/expose_accuracy_and_service_status_to_platform/+merge/203298 is resulting in this failure, and I would like this resolved as soon as possible
[16:15] <pitti> (building, I mean)
[16:15] <sil2100> pitti: that's what I'm trying to build exactly!
[16:16] <sil2100> The source from this merge is resulting in this i386 failure
[16:16] <pitti> sil2100: oh, really? location-api is broken, too?
[16:16] <xnox> sil2100: tvoss pinged me about it, i've fixed my compiler-fix branch, which he said will remerge.
[16:16] <sil2100> xnox: ok then, thanks!
[16:16] <pitti> PS jenkins seems happy with the location-api branch
[16:17] <sil2100> pitti: ah! Ignore me!
[16:17] <sil2100> pitti: location-service is ok, read 'platform-api' there
[16:17] <pitti> sil2100: heh; don't worry; I guess after wrestling with this all night and day it's too easy to lose track :/
[16:20] <tvoss> xnox, sil2100 merged and pushed xnox's changes
[16:23] <sil2100> tvoss: thanks! Excellent, already rebuilding
[16:23] <tvoss> sil2100, ack
[16:34] <kalikiana> elopio: weird failures in https://code.launchpad.net/~elopio/ubuntu-ui-toolkit/fix1274240-gallery-textfield_helper/+merge/203831 I wonder if that's to do with https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1274309 though not sure exactly what is broken in the lib
[16:35] <elopio> kalikiana: no, it's because the latest image is broken.
[16:36] <elopio> kalikiana: from ci: <fgint...> cjohns..., elopio, image 154 appears to be hosed
[16:36] <elopio> kalikiana: they already removed the ppa from the jenkins jobs, so that bug should be resolved.
[16:48] <annerajb> rsalveti, was the code for android 4.4 ever put on gerrit? it dosnt have a list of recently modified repositories like it had before so is hard to say.
[16:52] <rsalveti> annerajb: sorry, not yet, fixing a bug with the emulator right now, will publish everything once I get it to work
[16:53] <annerajb> rsalveti, ok
[17:00] <danielholm> cwayne: hi, well I am having some difficulty understanding the code of the auth and creating functions to call from the music app to scrobble and stuff. But I found your fitbit account code and having a look at that now. :)
[17:11] <mandel> barry, lp:ubuntu-download-manager/saucy
[17:12] <cwayne> danielholm: ah, well if you have any specific questions, feel free to ask :)
[17:13] <tvoss> mzanetti, around?
[17:13] <danielholm> cwayne: thank you :)
[17:14] <mzanetti> tvoss: hey
[17:25] <pmcgowan> any eta on a new build?
[17:29] <popey> all those disconnections looks like everyone went to the pub!
[17:55] <timppa>  is it still true if you have put ro image to rw mode and installed some packages to touch you cannot revert back to ro just bu removing the .writable_image file?
[17:56] <timppa> just curious because I had to install the libunity-mir1 with apt-get...
[17:57] <timppa> ok, 155 is just out... :)
[17:58] <timppa> seems to be working ok...
[18:25] <timppa> one thing that works now vs earlier builds is the indicator dropdown. It stays "open" once again which is very nice!
[18:41] <mterry> boiko, so should I merge that greeter-contacts branch into telephony-service myself?  Not sure who the gatekeeper is on your team
[18:41] <boiko> mterry: it's bfiller_afk
[18:42] <mterry> bfiller_afk, is it enough to leave the branch at Approved and you eventually sweep through and commit?  Or do I need to do something special?
[18:42]  * mterry is still getting used to how the new policies work on each team
[18:51] <SonikkuAmerica> So I've heard the Nexus 7 (2013) is the only officially supported TABLET left. So where's the Nexus 7 (2013) image? I see it nowhere on the wiki...
[18:52] <SonikkuAmerica> Or do I just use the daily-preinstalled images at cdimage.u.c ?
[18:53] <popey> SonikkuAmerica: dont think it's published yet
[18:53] <SonikkuAmerica> popey: Oh. :( Thanks...
[18:54] <SonikkuAmerica> They'd better hurry though... I'm itching for my 2013 Nexus 7 to play with the bleeding edge
[18:54] <SonikkuAmerica> :)
[18:54] <popey> ☻
[18:55] <popey> they're working hard on it
[18:56] <SonikkuAmerica> Ah, the person to ask for all things community. Hey jono!
[19:00] <popey> thats just a bot, the real jono is in a cryo-stasis tube on the moon.
[19:00] <jono> true
[19:00] <jono> hey SonikkuAmerica
[19:01] <jono> on the phone, will be there soon
[19:01] <SonikkuAmerica> popey: lol
[19:09] <bfiller> mterry: to get that released you need to do these steps in the checklist https://wiki.ubuntu.com/Process/Merges/Checklists/system-apps and run the test plan here: https://wiki.ubuntu.com/Process/Merges/TestPlan/telephony-service
[19:09] <bfiller> mterry: once you've verified all that let me know and I'll get it released
[19:10] <mterry> oh right, checklist happened after that was written
[20:51] <fermulator> Hi all, in https://wiki.ubuntu.com/Touch/Install#Supported_devices_and_codenames, I see that only the Nexus4 is supported (as the latest phone). Is it definitely true that Nexus5 would not work?
[20:56] <M4dH4TT3r> support mips
[20:58] <Tm_T> M4dH4TT3r: no need to repeat that
[20:59] <M4dH4TT3r> well if anyone had gotten it the first time i said it about 6mos ago i wouldnt ;)
[20:59] <popey> fermulator: no image yet
[21:37] <kenvandine> hey tedg!
[21:38] <kenvandine> i see ual now handles clicks on the desktop much better
[21:38] <fermulator> popey: thank you; are we /planning/ to support? (trying to decide if I should buy the nexus4 now, or wait for nexus5 support)
[21:38] <popey> nexus 4 works now, but you cant buy them anymore
[21:38] <popey> nexus 5 might work, but its not immediately on the list
[21:39] <tedg> kenvandine, Oh, really.  That's cool :-)  I've been running trunk from the PPA.  Archive is so far behind it's not been usable :-(
[21:39] <kenvandine> tedg, however, if the hub calls upstart_app_launch_stop_application on the APP_ID it gets in some weird state
[21:39] <kenvandine> upstart-app-list no longer lists it as running
[21:39] <kenvandine> but
[21:39] <kenvandine> status application APP_ID=....
[21:39] <kenvandine> does show it as running
[21:39] <kenvandine> so it can't start it again when needed
[21:39] <thomi> slangasek: veebers tells me I should talk to you abouyt my WIP branch to make autopilot use the libUAL gir bindings? Apparently there's a reason we shouldn't use gir bindings?
[21:40] <kenvandine> tedg, i can stop it with stop application APP_ID=...
[21:40] <kenvandine> then it all works fine again
[21:40] <tedg> kenvandine, Huh, like the application job itself hangs...
[21:40] <kenvandine> maybe
[21:40] <tedg> kenvandine, What does initctl list show ?
[21:42] <kenvandine> tedg, it doesn't show it anymore
[21:42] <kenvandine> but status does
[21:43] <kenvandine> application start/running, process 18767
[21:44] <kenvandine> yup... that process is running
[21:44] <tedg> kenvandine, initctl list?  not upstart-app-list, but the upstart one?  I don't think that's a possible state :-)
[21:45] <kenvandine> initctl list doesn't show it
[21:45] <kenvandine> upstart-app-list doesn't show it
[21:45] <kenvandine> but status application
[21:45] <kenvandine> does
[21:45] <tedg> That's crazy.
[21:45] <kenvandine> that pid is this
[21:45] <tedg> Calling it an upstart bug :-)
[21:45] <kenvandine>  /bin/sh -e /proc/self/fd/9
[21:51] <tedg> kenvandine, It'd probably be the shell script blocked on "start"
[21:54] <kenvandine> tedg,  it only happens when i stop it from the hub with upstart_app_launch_stop_application
[21:54] <kenvandine> with upstart-app-stop
[21:54] <kenvandine> it stops fine :/
[21:56] <tedg> kenvandine, Are you keeping a GDBus connection anywhere else?
[21:56] <tedg> Oh, wait, this is trunk.
[21:57] <tedg> Trunk is using the libnih connection.
[22:01] <M4dH4TT3r> would also be nice if image for HTC Desire CDMA were made too
[22:01] <popey> no CDMA support yet
[22:01] <M4dH4TT3r> ik
[22:02] <M4dH4TT3r> been waiting
[22:02] <M4dH4TT3r> and for MIPS support too
[22:02] <popey> cant see us doing mips anytime soon
[22:02] <popey> unless a handset manufacturer came along and wanted it
[22:03] <M4dH4TT3r> y not debian did and would be great
[22:03] <M4dH4TT3r> lots of MIPS tablets on the market
[22:05] <M4dH4TT3r> I hqave both MIPS tablets and phones
[22:05] <M4dH4TT3r> and CDMA phones
[22:05] <kenvandine> tedg, so the application-click job stops but then it leaves an application job running
[22:06] <kenvandine> before it calls stop, it shows up as an application-click job, and there is no application job
[22:07] <tedg> kenvandine, That's all really odd.  What happens with the untrusted-helper branch?
[22:07]  * kenvandine tries
[22:11] <kenvandine> tedg, same thing
[22:14] <tedg> kenvandine, Restarting help?
[22:14] <kenvandine> tedg, nope...
[22:14] <kenvandine> :/
[22:15] <tedg> kenvandine, Not sure how to recreate...  can you see if the DBus message is sent to upstart?  Bustle it?
[22:15] <kenvandine> ok
[22:53] <slangasek> thomi: hi there!
[22:53] <thomi> slangasek: hey - I was just about to hit send on an email instead :)
[22:53] <thomi> slangasek: tedg: I'd like to resolve the 'gir bindings vs system call' debate
[22:53] <thomi> so I don't waste my time
[22:54] <slangasek> thomi: well, a) I don't think the gir bindings provide any actual benefits over direct invocation in native python, but also b) the ual bindings haven't actually landed yet so aren't currently anything that autopilot can reasonably base on
[22:55] <slangasek> thomi: so, I have my own branch here which I think does what I think it should do; I've been in the process of trying to test it and finding that phablet-click-test-setup has had a behavior regression out from under me :-P
[22:56] <thomi> okay... the gir bindings give a much richer interface than I can get from a system call
[22:56] <thomi> unless I'm misisng something?
[22:56] <slangasek> thomi: richer yes, but why do you need richer?
[22:56] <thomi> how do I get the failed observer feature with a system call?
[22:57] <thomi> I'd like to know how/why an app failed to start
[22:57] <slangasek> well, I haven't seen evidence that ual gives you that
[22:58] <slangasek> if it does, then ok, I agree that it's better to not reimplement that parsing logic in two places and instead use the library
[22:58] <thomi> tedg: I can get that from libUAL, right?
[22:58] <slangasek> that leaves the other point, that I want this now and ual doesn't seem to be on track to land any time soon
[22:58] <tedg> thomi, Once the branches all land, yes.
[22:58] <slangasek> (OTOH, I'm not sure how relevant it actually is to autopilot to know the reason for a failure to start?)
[22:59] <thomi> slangasek: well, whatever we do we'll need to get it in an autopilot landing, so we'll need to push *something* through the landing process
[22:59] <tedg> slangasek, The reason that I'd prefer to see autopilot use the lib is because that's what Unity is using.
[22:59] <thomi> slangasek: it's pretty important to give accurate and precise feedback to the user when their app fails to start
[22:59] <tedg> The only person in production using the utilities is click, which I hope will go away with it's C rewrite.
[23:00] <tedg> slangasek, Is that still for 14.04?  If not, could we get click to use the GIR bindings?
[23:01] <slangasek> tedg: the click C rewrite is for 14.04, yes
[23:01] <cjwatson> right, I'm in progress on that
[23:01] <tedg> K, so then probably ual-tools will drop from the image then.
[23:01] <tedg> ?
[23:01] <cjwatson> and sure, if there are stable/working gir bindings then I'm quite happy to use them, even in advance of the C rewrite
[23:02] <cjwatson> ./click/database.py:88:        command = ["upstart-app-pid", app_id]
[23:02] <cjwatson> that's all I use
[23:06] <cjwatson> so from my point of view, this is only used when removing click packages; performance isn't particularly important there.  gir bindings are probably marginally better, but not much in it,
[23:06] <cjwatson> .
[23:07] <thomi> slangasek: tedg: so, are we in agreement? We use GIR bindings (need to get them landed ASAP then) - both in autopilot and in click?
[23:07] <tedg> Sure, probably parsing the GIR file is roughly the same cost :-)
[23:08] <slangasek> thomi, tedg: so I think I'm inclined to push for my autopilot changes to land ASAP on autopilot/1.4, because it addresses an immediate issue for me; after which I can look at helping to land the ual gir bindings and help rebase thomi's branch as neede
[23:08] <slangasek> +d
[23:09] <thomi> slangasek: I'm happy to land your branch on /1.4 as a shorter term fix. Ping me a MP and I'll look at it. In the mean time, I'll keep working on my gir-based branch.
[23:09] <thomi> can I leave it to you slangasek and tedg to get the gir branch landed? Is there anything I can do to help that along?
[23:09] <tedg> I put the GIR bindings on the CI Train.  I'm still allowed to edit that spreadsheet.  Not sure when a silo will be allocated.
[23:10] <tedg> thomi, Invent a better release process?  ;-)
[23:10] <thomi> tedg: inventing it is the easy part :)
[23:11] <slangasek> thomi: ack.  I'm still verifying locally that it works for a minimal test case, which is currently caught up on the script popey gave me for wrapping click tests having regressed ;P
[23:11] <slangasek> thomi: as soon as I do that, I'm going to push and raise an MP
[23:11] <thomi> slangasek: ok, cool. let me know if I can help
[23:14] <adminjs> hi guys I flashe today the new build 151 and Ubuntu Touch rocks
[23:21] <popey> adminjs: yay!
[23:29] <a_muva_> adminjs: 153 is available


[01:32] <sagitta007> hi
[01:33] <sagitta007> Me needs help
[01:33] <sagitta007> Hello???
[01:45] <holstein> sagitta007: just ask, and if one of the volunteers can help, they will :)
[06:24] <r4y> Ah, I am wondering about this setup for Ubuntu and how good the offer is. I mean it says quad core but isn't there draw backs of compatibility. My computer is having serious trouble and I also need a way to back up all my data from hard drives on IDE cables which I could try transferring through usb but will take a lot of work
[06:25] <r4y> http://tinyurl.com/b7g6w92
[06:35] <r4y> I taking it that that deal has the connections for the new type of hard drives that now support 500 GB to 1 TB hard drive size which my motherboard doesn't have the capability for.
[06:35] <r4y> I don't know how long sata has been around but anyways I bought my motherboard in 2006
[06:37] <r4y> I figure buying this setup as well as a new hard drive will be better then paying to have my current computer fixed. What do you guys think?, but quad core. I am afraid, ha ha
[06:39] <mysteriousdarren> go big or go home
[06:39] <r4y> I don't need serious specs since I am a very old school gamer.
[06:40] <r4y> I think it is great though
[06:40] <r4y> I am home, ha ha
[06:41] <r4y> I meant to that like this. But I am already home, ha ha ha, wa ha ha ha
[06:43] <mysteriousdarren> good thing your home then
[06:49] <r4y> I will need to wait to buy anything because we are in a tight bind, but I know that is normal for most people. Everyone has their troubles. I am happy to just breath air, do yoga, drum, and so on. I can wait to upgrade to something reasonable. Perhaps the deal will still be around when  have the money, but there will always be other great deals
[06:50] <r4y> well anyways, take care. I bookmarked the deal just in case, bye
[13:01] <budmaester> what is best practice to format and organize partitions for Xubuntu
[15:56] <bodhi_zazen> I re-booted your VPS, I could not tell what was wrong with it.


[00:27] <bobj> quit
[12:43] <echtler> hi everyone, i've got a problem with my ppa build...
[12:43] <echtler> it uses mono/gmcs which fails with the following error:
[12:43] <wgrant> echtler: What's the issue?
[12:44] <echtler> make[3]: Entering directory `/build/buildd/libtisch-1.1/libs/wrappers/csharp'
[12:44] <echtler> g++ -g -O2 -Wall -ggdb -fPIC -DTISCH_SHARED="" -DTIXML_USE_STL -I. -DTISCH_PREFIX='"/usr/share/libtisch/"' -O2 -fno-strict-aliasing -Wall -ggdb -fPIC -L/build/buildd/libtisch-1.1/debian/tmp/lib/ -shared -Wl,-soname,libtisch_csharp.so -I../../../ -I../../..//libs/tools -I../../..//gestured -I../../..//widgets -I../../..//libs/simplecv -I../../..//libs/simplegl -I../../..//gestured/features -L../../..//libs/tools -L../../..//gesture
[12:44] <echtler> d -L../../..//widgets -L../../..//libs/simplecv -L../../..//libs/simplegl -ltools -lgestures -lsimplecv -lsimplegl -lwidgets libtisch_wrap.cxx -o libtisch_csharp.so
[12:44] <echtler> cd libtisch; gmcs -t:library -out:../libtisch.dll -warn:4 *.cs
[12:44] <echtler> ** (/usr/lib/mono/2.0/gmcs.exe:19349): CRITICAL **: _wapi_shm_file_open: shared file [/root/.wapi/shared_data-promethium-Linux-x86_64-328-12-0] open error: Permission denied
[12:44] <echtler> ** (/usr/lib/mono/2.0/gmcs.exe:19349): CRITICAL **: _wapi_shm_attach: shared file [/root/.wapi/shared_data-promethium-Linux-x86_64-328-12-0] open error
[12:44] <echtler> **
[12:44] <echtler> ERROR:shared.c:401:shm_semaphores_init: assertion failed: (tmp_shared != NULL)
[12:44] <echtler> ** (/usr/lib/mono/2.0/gmcs.exe:19349): WARNING **: Thread (nil) may have been prematurely finalized
[12:44] <echtler> Stacktrace:
[12:44] <bigjools> argh, please use pastebin
[12:44] <echtler> ** (/usr/lib/mono/2.0/gmcs.exe:19349): WARNING **: Thread (nil) may have been prematurely finalized
[12:44] <echtler> ** (/usr/lib/mono/2.0/gmcs.exe:19349): WARNING **: Thread (nil) may have been prematurely finalized
[12:44] <echtler> ** (/usr/lib/mono/2.0/gmcs.exe:19349): WARNING **: Thread (nil) may have been prematurely finalized
[12:44] <echtler> Segmentation fault
[12:44] <bigjools> echtler: , please use pastebin
[12:44] <echtler> uargs. sorry for the spam....
[12:44] <echtler> @wgrant: the problem is that the /root/.wapi directory seems to be corrupt
[12:45] <echtler> @bigjools: yes, sorry about that. one moment please..
[12:45] <wgrant> echtler: You can't write to /root.
[12:45] <wgrant> The build doesn't run as root.
[12:46] <echtler> @wgrant: i know. i don't try that in my makefile. the error seems to be quite common with mono, and the quick fix is to remove the .wapi directory for the user
[12:46] <echtler> maybe here the problem is in fact that the build doesn't run as root, but tries to access /root/.wapi
[12:47] <echtler> right - here it is in readable form: http://pastebin.org/408118
[12:47] <echtler> sorry about the earlier spam.
[12:48] <wgrant> echtler: Your build can't expect to have access to /root.
[12:49] <echtler> @wgrant: i am aware of that, and it doesn't assume that. debuild runs it fine as a regular user on my machine, so i'm not sure what causes the attempted access to /root/.wapi
[13:17] <echtler> wgrant: i've just found that the error also occurs within pbuilder, so it's probably not launchpad-specific. sorry for the noise.
[13:32] <echtler> wgrant: for the record, i've found the problem - it's related to mono trying to use the wrong home directory and can be fixed by adding "export MONO_DISABLE_SHM=1" to debian/rules.
[14:26] <ahasenack> launchpad is timing out quite a bit for me today, is it affecting others too?
[14:26] <jpds> ahasenack: On edge.lp.net ?
[14:28] <ahasenack> jpds: no, production
[14:28] <ahasenack> I'm trying to file a bug, https://launchpad.net/landscape/+filebug
[14:28] <ahasenack> I even forgot what it was by now :)
[14:29] <jpds> ahasenack: Do you have the OOPS ID?
[14:29] <ahasenack> 1662G1160
[14:29] <ahasenack> jpds: ^^^
[14:29] <ahasenack> OOPS-1662G1160 even
[14:39] <lifeless> looking
[14:40] <lifeless> ok fti search timeout
[14:40] <Ursinha> ahasenack, it's timing out after you adding the information?
[14:40] <Ursinha> is that correct? so it seems by the oops report
[14:40] <lifeless> the performance for this should be the same on both prod and edge
[14:40] <lifeless> and prod has a 17 second tiemout
[14:44] <lifeless> ahasenack: I've filed bug 607771
[14:45] <lifeless> deryck: I've filed https://bugs.edge.launchpad.net/malone/+bug/607771 for you - turns out its timing out on prod even though its under the limit on edge
[14:47] <ahasenack> Ursinha: it was at the last moment, I had content in the bug description
[14:47] <ahasenack> Ursinha: I was now able to file it by starting over
[14:48] <ahasenack> once in the timeout page, hitting reload just timed out over and over again
[14:48] <ahasenack> and the reload did rePOST the data (maybe having a timeout here was expected)
[14:49] <lifeless> ahasenack: no, we don't expect timeouts
[14:49] <lifeless> we've made a config change last week to reduce a particular timeout value, and some things that were right on the edge are having a bit of trouble
[14:49] <ahasenack> ah, ok
[14:50] <lifeless> stats show its causing some timeouts, *mainly* to scripts
[14:53] <deryck> lifeless, ack.  Thanks.  I'll take a look here shortly.
[14:56] <lifeless> also https://bugs.edge.launchpad.net/malone/+bug/607776
[14:56] <deryck> gotcha
[15:03] <kamal> PPA question:  I'm polishing up a wiki doc which claims that the PPA system can build binary packages for 'armel' ... But I thought the builders only build i386 and amd64 since Karmic and I've never known them to build for armel at all.  Is it even possible to make the PPA system build for armel?
[15:04] <kamal> https://wiki.ubuntu.com/Upstream
[15:06] <wgrant> kamal: Normal PPAs are restricted to x86 and AMD64. Some Canonical-controlled PPAs may have armel support.
[15:06] <wgrant> There's no good way to virtualise armel machines at the moment, so they can't safely be made available more widely.
[15:06] <kamal> wgrant: ok, thanks -- I'm going to remove the reference to armel there.
[15:06] <bigjools> and they're dog slow
[15:07] <wgrant> kamal: That sounds like a good idea.
[15:07] <wgrant> bigjools: That too.
[15:07]  * bigjools boggles at the empty PPA queues
[15:08] <wgrant> bigjools: You don't have a couple of Python and archive rebuilds up your sleeve?
[15:08] <bigjools> oddly, no
[16:10] <hannie> ping danilos
[16:37] <hannie> danilos, ping
[16:37] <danilos> hannie, sorry, otp
[16:38] <hannie> What does otp mean?
[16:43] <geser> On The Phone
[17:41] <Kasuko> Can anyone help with a failed PPA build. It's a python program and the build log says it failed on "/bin/sh: python2.5: not found
[17:41] <Kasuko> but it installs python2.6
[17:50] <ochosi> hi everyone, i have a question: my packages got rejected because i am not "permitted to upload to the RELEASE pocket in a series in the 'SUPPORTED' state". up to now i never had any probs with pushing packages to my ppa - what does this mean? (https://launchpad.net/~shimmerproject/+archive/ppa)
[17:51] <bigjools> ochosi: it means you're trying to upload to Ubuntu, not your PPA
[17:52] <ochosi> bigjools: oh damn, my bad... (now i realise the mistake) thanks a bunch!
[17:52] <bigjools> np
[17:55] <Kasuko> Any ideas why PPA would fail to find python2.5 when it's actually installing python 2.6
[17:55] <bigjools> it's most likely to be a packaging problem
[17:56] <Kasuko> I know but I can't figure out what. It's a super simple command line tool and I followed the Python Packaging tutorial to a tee
[17:56] <bigjools> your best bet is to ask in #ubuntu-motu for packaging advice
[17:57] <Kasuko> ok will do, thank you
[18:51] <Kasuko> ok I made a mistake. I uploaded a version ubuntu1 and that failed to build but instead of doing what I should have done and made a version ubuntu2 I requested deletion of ubuntu1 and was going to try to reupload it before I realized how stupid I was.  What?
[20:23] <purvesh> can some one help me for filling the IRC Channel registration form ?
[20:24] <Pici> purvesh: This is #launchpad, if you're trying to register a channel on freenode, then try asking in #freenode
[20:25] <smallfoot-> Kasuko, yeah you cant report bugs
[20:25] <smallfoot-> cuz it comes TIMEOUT ERROR
[20:26] <purvesh> Pici, i had tried at there but still i didnt got any reply, and i want to open irc channel for communicating my Launchpad Group
[20:27] <Pici> purvesh: #freenode is still the best place to ask about that
[20:27] <deryck> smallfoot-, I know it's a pain.  We want to fix it.  In the meantime, have you tried using apport to file your bug?
[20:30] <smallfoot-> deryck, cant use apport in this case
[20:30] <deryck> smallfoot-, why not?
[20:30] <smallfoot-> deryck, you want to fix it? its been unfixed for months!
[20:30] <deryck> smallfoot-, it's hard to fix.
[20:31] <smallfoot-> oh
[20:32] <deryck> smallfoot-, so why can't you use apport?
[20:32] <smallfoot-> cuz it dont have a package to file against
[20:33] <deryck> smallfoot-, what is "it" in that sentence?  What do you want to file a bug about?
[20:34] <smallfoot-> that there is no package 'yasca' in repo
[20:35] <deryck> smallfoot-, how did you get yasca on your system?
[20:35] <smallfoot-> its not on my system, and that is the problem
[20:36] <smallfoot-> i want it in my system, but its not in the repo
[20:36] <deryck> ah
[20:37] <lifeless> smallfoot-: are you still getting timeouts now? we raised the limit earlier today.
[20:37] <lifeless> smallfoot-: what is the url of the page you are on ?
[20:38] <smallfoot-> lifeless, yes still timeouts
[20:38] <smallfoot-> lifeless, https://bugs.launchpad.net/ubuntu/+filebug?no-redirect&field.tag=needs-packaging
[20:39] <lifeless> smallfoot-: what are you putting in the summary field ?
[20:40] <lifeless> smallfoot-: hello ?
[20:42] <smallfoot-> lifeless, yasca
[20:43] <lifeless> indeed, that times out for me too on the duplicate search, I'm trying the actual filing now.
[20:43] <lifeless> smallfoot-: https://bugs.edge.launchpad.net/ubuntu/+bug/607937
[20:43] <lifeless> smallfoot-: edit to your hearts content
[20:44] <smallfoot-> thanks
[20:44] <smallfoot-> how you made that? i couldnt do that
[20:44] <lifeless> I just tried
[20:45] <lifeless> and it worked
[20:45] <lifeless> I put 'yasca' in the summary, clicked next.
[20:45] <lifeless> it timed out but gave me the form to fill in, so I put in a description and clicked file bug ...
[20:46] <smallfoot-> oh, never worked for me, i tried 10000 times
[20:46] <smallfoot-> maybe cuz you used edge
[20:46] <lifeless> edge has an even lower timeout
[20:47] <lifeless> but perhaps
[20:47] <lifeless> we're working to reduce the difference between prod and edge.
[20:47] <lifeless> to make things like this easier to diagnose and fix
[20:47] <smallfoot-> oh
[20:47] <smallfoot-> dont konw how you did it first try
[20:48] <smallfoot-> i tried 9999 times, just got timeout
[20:48] <lifeless> neither do I
[20:48] <lifeless> back in a bit
[20:48] <smallfoot-> alright
[20:48] <smallfoot-> thanks <3
[21:05] <gmb> lifeless, Usually, when people see an actual timeout and no form when filing bugs, there's a Javascript problem.
[21:06] <lifeless> gmb: how does that work
[21:06] <gmb> The +filebug page degrades to the non JS version if the JS fails to load. And if it takes a long time for the JS to load you'd see the same effect.
[21:06] <lifeless> the js is loaded from apache though, right ?
[21:07] <gmb> lifeless, Yes. But on a high latency connection or with a browser plugin that does something to JS...
[21:07] <lifeless> ok
[21:08] <lifeless> what could I have done better in analyzing it
[21:08] <gmb> lifeless, Not much, really, except to ask the user to try another browser.
[21:09] <gmb> lifeless, Also, in timeout cases, entering a really simple title for the bug (e.g. 'aaa') and then changing it at the next step is usually sufficient to sidestep the timeout.
[21:09] <lifeless> gmb: we don't really have the headroom for that to last more than a couple of days
[21:09] <lifeless> :)
[21:09] <gmb> But that the bugs dupe search is problematic is understating it by an order of magnitude.
[21:10] <lifeless> to the ^2
[21:10] <lifeless> heres another one for your enjoyment
[21:10] <lifeless> https://bugs.edge.launchpad.net/malone/+bug/607948
[21:10] <gmb> lifeless, Well, the dupe search times out many, many times every day, I expect. But the users don't notice because the JS version of +filebug handles it gracefully.
[21:10] <lifeless> gmb: oh, I think they notice
[21:10] <gmb> WHY ARE WE STILL USING NULLBUGTASK. AAAAAAAAAAAAAAA
[21:10] <gmb> *ahem*
[21:10] <lifeless> they say 'wow that took 20 seconds'
[21:10] <gmb> I mean:
[21:10] <gmb> "Oh"
[21:10] <lifeless> gmb: how should that be fixed.
[21:11] <gmb> lifeless, Hand-wavy version that glosses over the fact that we've tried and apparently failed to do it before: we should *always* refer to a bug in a useful context.
[21:12] <gmb> lifeless, I can't remember the root cause of the problem off the top of my head.
[21:12] <lifeless> gmb: by which you mean, I presume, that when its not in a useful context we should redirect and not render ?
[21:12] <gmb> lifeless, Yes, pretty much. I was under the impression that intellectronica had done that work already, though. deryck may know...
[21:13] <lifeless> if only he was still here
[21:13] <lifeless> we could ask him :P
[21:13] <lifeless> https://bugs.edge.launchpad.net/ubuntu/+source/libv4l/+bug/260918 appears to be the actual bug place
[21:13] <lifeless> and that too falls down goes boom
[21:13] <lifeless> ubot5: har har har
[21:14] <deryck> I think intellectronica meant to do the work and other things got in the way.
[21:14] <deryck> other work priorities, I mean
[21:14] <gmb> Bother.
[21:15] <gmb> lifeless, Of course, the real irony is that ubot5 has given us a useable URL.
[21:15] <gmb> Well, useful... except that it times out on edge.
[21:15] <lifeless> tada
[21:16] <deryck> lifeless, what is the timeout set to on edge/lpnet now?
[21:16] <lifeless> gmb: https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1662EA1548 is the oops for it timing out on edge
[21:16] <lifeless> deryck: 14/17
[21:16] <lifeless> deryck: we tried 12 but it was a disaster
[21:17] <lifeless> gmb: 844 queries before it gets killed
[21:17] <deryck> lifeless, right.  Was just curious about the current setting.
[21:17]  * beuno has not been able to file bugs on edge at all today
[21:17] <lifeless> beuno: its working for me
[21:17] <lifeless> beuno: please try
[21:17] <deryck> bdmurray considers this a feature
[21:18] <lifeless> gmb: 153 repeats of 'is someone subscribed'
[21:18] <lifeless> gmb: with limit 1. This seems insane.
[21:18] <gmb> lifeless, That's a privacy check, I'd guess, but htat's just a guess.
[21:18] <beuno> lifeless, I tried re-submitting it 22 times until I gave up and used firebug to inspect the POST and file it on production
[21:18] <lifeless> beuno: you know, there is this 'do not redirect me' button.
[21:19] <lifeless> beuno: but separately, really - is it working for you now. Please check.
[21:19] <lifeless> beuno: it may time out on the fti for dupes, but you should still get a form.
[21:19] <lifeless> and be able to complete the filing
[21:20] <lifeless> gmb: I'm sure its something like that, but we need to pull that up out of per-person and make it set based.
[21:20] <lifeless> gmb: otherwise it will suck forever.
[21:20] <beuno> lifeless, yes, I used that button after 22 times, but I loose my bug description, so I *really* tried
[21:20] <beuno> I will try in a bit
[21:20] <beuno> now
[21:20]  * beuno -> yoga
[21:20] <gmb> lifeless, Couldn't agree more.
[21:23] <lifeless> hmm
[21:23] <lifeless> 233 requests on a changelog page for library file aliases
[21:23] <lifeless> ><
[21:23] <lifeless> bigjools is going to get up, and order a hit on me, I suspect
[21:30] <geser> wgrant: did you say, soyuz doesn't accept uploads with "Architecture: linux-any"? bdrung managed to get an upload through: https://edge.launchpad.net/ubuntu/+source/acetoneiso/2.2.2-2 => no build records
[23:20] <wgrant> geser: Ah, good point. We don't check for buildable architectures in the primary archive, so it will be accepted there anyway.