=== salem_ is now known as _salem [01:42] I am getting crashes from the terminal app consistently. Anyone else seeing that? [01:42] on Mako channel devel [01:56] I can see this in var/crash [01:57] weird thing is: the version number of the app differs [01:58] the crash log says 0.5.113 and the ui says 0.5.119 [01:58] could that be relevant? [01:59] could it be this version shouldnt have been released to the devel channel? i.e. proposed only? [02:14] does anyone have any walkthrough on how to prepare files from a fresh `lunch` followed by `make` ready for ubuntu-device-flash (i.e. a redistributable instead of using rootstock to install onto a single device) [02:15] I found information on this page but it is unclear how to get the files from `make` into a format usable by the system-image utilities: https://wiki.ubuntu.com/ImageBasedUpgrades/ServerSetup [02:17] this is for a new port, not a modified version of something the project already provides - therefore the remote-system-image function for file_device in the config file of system-image server is not helpful === _salem is now known as salem_ === salem_ is now known as _salem === Ursinha is now known as Ursinha-afk [06:22] cwayne1: pong :-) [06:53] which component is responsible for the SIM pin unlock? a few days or so ago the phone finally started asking me for the PIN right on startup, but on image 208 it lost that again [06:54] now I again need to go to the indicator and unlock the pin there (which often enough I just forget) [06:54] pitti, unity8 I think [06:54] seb128: uh, really? unity knows about SIM PINs? [06:54] pitti, the lock screen is part of unity [06:55] anyway, I can start there and we can move the bug around [06:55] ah, it's got a few sim pin bugs already indeed [06:56] pitti, https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1333121 [06:56] Ubuntu bug 1333121 in unity8 (Ubuntu) "SIM Unlock should be shown on boot" [High,In progress] [06:56] that might be yours? [06:57] hm, not sure [06:57] it did work in image 207, and a few earlier ones [06:57] well, that's what you are suggesting no? [06:57] exactly as it should be [06:57] that bug has a branch linked that landed some days ago [06:58] pitti, https://launchpad.net/ubuntu/+source/unity8/8.00+14.10.20140822-0ubuntu1 [06:58] has [06:58] " * Show the SIM unlock dialog immediately after booting, and enable its [06:58] emergency call button." [06:58] so maybe there is a bug in there? [06:58] maybe, or some race condition [06:58] but I booted three times with 208, it never asked me [06:59] while on 207 it always asked me (and I booted that umpteen times yesterday) [06:59] I filed bug 1361518 for now [06:59] bug 1361518 in unity8 (Ubuntu) "image 208 regression: does not ask for SIM pin at startup" [Undecided,New] https://launchpad.net/bugs/1361518 [06:59] danke [07:01] I also followed up to the other bug [07:14] pitti, seb128 it's disabled on purpose in unity8 [07:14] bug 1361074 [07:14] bug 1361074 in unity8 (Ubuntu RTM) "Dual-SIM support for PIN unlock dialog" [Critical,Triaged] https://launchpad.net/bugs/1361074 [07:15] jibel, how come it was not mentioned in the changelog? [07:15] seb128, no idea [07:15] Saviq, ^? [07:16] seb128, it was... but in the line the train didn't pick up, my bad [07:16] hum, how does that work? it should have picked the commit msg for the change no? [07:16] seb128, train's only picking up until an empty line now to allow for verbose commit msgs vs. not-so-verbose changelog [07:16] oh, ok, didn't know that [07:17] but obviously that failed when I did put the empty line in the wrong place [07:17] k [07:17] Saviq, thanks [07:17] jibel, Saviq: oh, so it got deliberately disabled yesterday? [07:17] will that come back? [07:18] pitti, yeah, soon [07:18] pitti, like this week maybe even [07:18] Saviq: ok, thanks === tvoss is now known as tvoss|test === tvoss|test is now known as tvoss [07:36] robru, Mirv: so apparently we'll need to land all the X-Langpack: things to RM too; is there some shortcut with copying packages from utopic, or do we need to jump through all the "create a bazillion MPs and land them" fuss again? [07:37] RTM, even [07:37] * pitti uploads new touch langpacks and will copy them to RTM, but without ^ they will have little effect === JoshStrobl[ZZZ] is now known as JoshStrobl [07:38] Saviq: hm "invalid" is quite harsh -- it is a functional regression, and not having the SIM dialog is quite a bummer.. [07:38] pitti, would you rather me dupe it? [07:39] pitti, there's like 3 bugs dealing with that already [07:39] Saviq: no worries, I just wondered [07:39] that's fine [07:39] as long as it's tracked [07:42] pitti: yes it is legit to create an rtm silo and then sync utopic packages into it. Sil can help you with that once he's up, I'm long past EOD [07:43] that rtm handling is suboptimal [07:43] not sure why 2 landings are needed for things that use trunk for rtm [07:43] I'd think that most changes landing in utopic are destined for RTM anyway -- we are in FF, and people work on nothing else [07:44] we should double work only for projects that want a trunk with new features not suitable for rtm [07:44] yeah, we made our lifes even harder wiht that.. [07:44] and branch in those cases [07:44] pitti: probably the best is to check if sil2100 has something new brewed to help that copying, but at least PPA-to-PPA copying is not anymore possible since the X-Langpack changes have landed already. dget + dput would of course work. [07:45] or well copy-archive from archives to rtm-PPA [07:47] yeah, that's what I meant [07:47] I did that with langpacks [07:48] i. e. we'll need to go through and see if utopic has any changes that we don't want in RTM, and if there are none we can just copy? [07:52] good morning [09:01] jgdx, hey, did you try if you still have the tz not changing issue? === yofel_ is now known as yofel [09:09] hm, why don't I see the gallery-app in the emulator? because camera isn't visible (no cam in emulator)? gallery still ought to work though, no? [09:10] pitti: gallery is an armhf click [09:10] aah [09:10] pitti: we need the ci team to support fat package building [09:10] hm, wouldn't that blow up the image size and downloads even more? [09:11] only with fat though [09:11] thats elastic :P [09:11] pitti: it's the click design; and yeah; gallery si kind of big [09:11] pitti: but the store doesn't allow multiple packages to coexist [09:11] well, it was just for a screenshot of a bug that I filed; but should be fine without one, too [09:12] * ogra_ sighs ... so finally we have DRI, GLX and wayland on the phone ... [09:12] http://people.canonical.com/~ogra/touch-image-stats/208.changes ... [09:13] all the guys with nvidia or radeon cards in their telephones will be so thankful :P [09:13] and those that want to mess with freedreno drivers [09:13] heh [09:15] ogra_: why was that only added now? mesas egl already seemed to depend on wayland and xcb.. [09:16] anpok, https://launchpad.net/ubuntu/+source/gst-plugins-bad1.0/1.4.0-1ubuntu1 [09:16] needs to be fixed to recommends or some such, so they dont end up on armhf images [09:16] (these libs are huge and have no benefit) [09:24] ogra_: your stats should be for the rtm image! === vrruiz_ is now known as rvr [09:31] whoopsie again not happily uplkoading... log is telling me its offline, while it is wifi online for sure [09:32] what does whoopsie really look for to determine whether online/offline and whether on data or not? [09:32] anyone knows details? [09:33] nm-tool reports "connected" [09:33] restarting whoopsie resurrected this [09:35] asac: whether it's connected to wifi or ethernet: http://bazaar.launchpad.net/~daisy-pluckers/whoopsie/trunk/view/head:/src/connectivity.c#L205 [09:35] ev: do you also wake up everye 10 minutes or so in case yo missed a dbus signal? [09:35] seems this is what happened then i guess [09:36] like evfery 10 minute one busy poll etc. [09:36] missed a dbus signal? It's been a long time since I've dug deep on dbus, but is that possible? [09:36] ev: of course. dbus is buggy in general :) [09:36] also you can have race [09:36] i assume [09:37] ev: i assume you first register state handler and then do ONE busy poll on initial startup? [09:37] state_changed [09:37] pitti: can you confirm? ^ that changes my understanding greatly of how we should interact with dbus [09:38] asac: yes: http://bazaar.launchpad.net/~daisy-pluckers/whoopsie/trunk/view/head:/src/connectivity.c#L339 [09:38] i think i see it in the code that you do that (e.g. first register state handler, then go and poll for Get once [09:38] ) [09:38] yeah [09:38] err, yes, it's not a know issue that apps "miss d-bus signals" [09:38] of course you have to initalize the state after connecting to services [09:38] in any case, NM was online with nm-tool, but whoopsie log spit out "offline" [09:38] restarting whoopsie made it pick up all the missed crashes and submitted them [09:39] if that were the case, we'd have a big problem (randomly missing signals) [09:39] seb128, I'm in the middle of a wipe. Will check right after [09:39] yes, I'm not denying something strange is going on here that we need to investigate [09:39] jgdx, thanks [09:40] asac: can you pastebin the logs from whoopsie? Was it just a single "offline" - that might happen if whoopsie was unable to talk to NM's dbus API when it started. [09:40] I should really make that more explicit [09:40] ev: yes it was offline repeating [09:40] hm [09:40] no itmestamps [09:40] it was talkinga bout data plan before [09:40] but then loads of offline while i was surely online [09:41] okay, were you on 3G and then switched to wifi? [09:41] ev: most likely yes. [09:41] i was outside [09:41] came back indoors [09:41] there were a bunch of crashes from yesterday in /var/crash though [09:41] and i surely rebooted with wifi on in between due to hangs [09:42] http://paste.ubuntu.com/8148475/ [09:42] thats what i found before restarting whoopsie [09:42] those crashes not submitted were yesterday [09:43] ev: is .1 always the newest backup? [09:43] hm, I think I should implement SIGINT or something to more cleverly dump the state of the world that whoopsie sees [09:43] or rather .2 [09:43] timestamps for logging would also help for very basic forensic support [09:44] Err SIGUSR1. And yeah, timestamps [09:44] ev: i was confused because of bad adb shell behaviour [09:44] ev: here is the real log [09:44] sergiusens, they will soon ... i plan to add changelog generation for rtm before end of the week [09:44] http://paste.ubuntu.com/8148490/ [09:45] ev: Using lock path: /var/lock/whoopsie/lock [09:45] thats when i did the restart whoopsie [09:45] then it flush submitted stuff [09:45] ev: i am using dual sim btw [09:45] so might be a bit more confusing if you assume something other than global [09:46] but really doubt this has anything to do with that [09:46] ev: hmm. [09:47] ev: http://bazaar.launchpad.net/~daisy-pluckers/whoopsie/trunk/view/head:/src/connectivity.c#L165 [09:47] that while ... that seems to assume that the interface that has primary route is coming first? [09:47] sure that thats true? [09:48] ev: at least in nm-tool my wifi interface comes after the data interfaces: http://bazaar.launchpad.net/~daisy-pluckers/whoopsie/trunk/view/head:/src/connectivity.c#L165 [09:49] ev: i think you have to check whether the interface is default and connected before even considering this a device that is valid for bailing. [09:50] ev: http://paste.ubuntu.com/8148518/ [09:50] check that output [09:51] i dont see that you check that this is the default connection [09:51] * ev looks [09:51] so you will bail whenever there is a 3g connection active [09:51] or not? [09:51] * asac thinks he doenst understand the code well enough [09:52] hmm [09:52] well. dont think i am right [09:52] see the state_changed logic checks somehow if any device is active that isnt data [09:52] it is fine [09:53] err [09:53] this looks very odd: [09:53] if (is_default_route (connection, path, FALSE) || [09:53] is_default_route (connection, path, TRUE)) { [09:53] if (!is_paid_data_plan (connection, path)) { [09:53] paid = FALSE; [09:53] break; [09:53] } [09:53] } [09:53] :) [09:54] if it is or if it is not default route and it is not paid then we are on nt on paid? :) [09:55] that's for ipv4 and ipv6 [09:55] I would greatly welcome explicit keyword arguments to C for exactly this reason [09:55] though I suppose I could just encapsulate that in a variable [09:55] sil2100: good morning [09:56] hmm. route_available logic feels very implicit ... might be a source of thinking that we are not online [09:56] you might not be wrong about is_paid_data_plan - I just need to stare at it a bit longer [09:57] pitti: morning! [09:57] ah, yeah, maybe the route comes up a little after the connection? [09:57] dunno. i think that logic is sane... should at least report MORE cases then valid ...not less [09:57] s think route_changed logic might be the bad one [09:57] route comes on after, yes [09:58] dunno what g_network_monitor_can_reach is doing [09:58] sil2100: for the x-use-langpack stuff: is it acceptable to copy those from utopic to RTM if they don't have other changes (or only changes which we want), or do we need to go through the whole "gazillion MPs, land" dance again? [09:58] that might be buggy [09:58] i assume it uses some netlink stuff which is never easy to really understand how to get deterministic behaviour out of it [10:00] oh that is gio [10:01] i like; [10:01] /* Using GNetworkMonitor brings in GSettings, which brings in DConf, which [10:01] * brings in a DBus session bus, which brings in pain. */ [10:01] very wise comment [10:01] :) [10:01] I *hate* GIO and everything it stands for. [10:02] /* Checking whether a NetworkManager connection is not enough. [10:02] * NetworkManager will report CONNECTED_GLOBAL when a route is not present [10:02] * when the connectivity option is not set. We'll use GNetworkMonitor here [10:02] * to fill in the gap. */ [10:02] ev: do you remember that one? [10:02] connectivity option i dont know [10:02] i think this monitor is probably the reason for flakiness [10:02] I'd love to kill gnetworkmonitor, but we're not using the connectivity check, unless things have changed in recent times [10:02] i have been working ona network library using netlink and i know taht even if ou think you got it, it just sometimes doesnt work. e.g. kernel doesnt give you the right signals etc. [10:02] ev: what is the connectivity check? [10:03] some tin foil hat types didn't want to "phoning home" to determine connectivity [10:03] despite just about everything else in the world doing it [10:03] so rather than support it at the OS level [10:03] we have to do it in a number of different places [10:03] i dont understand [10:03] why cant you just try if NM believs you can connect [10:04] and then dont try again for 10, 20, 30 minutes if fail [10:04] connectivity check> Hit a website and verify the response to make sure we're really, really online, and not just inside a captive portal === davmor2_ is now known as davmor2 [10:04] ev: but you could try to connect if you have a crash; why even try to figure if you are really online that way? [10:04] * ev preps a branch to increase the logging around all of this [10:05] ev: i also dont really think that the "can_reach" feature of netlink really helps you figuring if you can talk to that server [10:05] it just guesses based on the routes that you have a path to get there [10:05] asac: we don't verify the core file payload until much later in the process [10:05] so if you are in hotel it will stll claim that you can connect [10:05] so uploading a massive one into a captive portal would be quite wasteful [10:06] ev: it would fail, no? [10:06] or are they behaving like honeypos that accept whtever you http post to them? [10:07] whoopsie would send the initial metadata to nowhere and get a 200 response back, so it would then send the core dump to nowhere [10:07] ev: so i feel if we say we only check if server can really be reached if there isa crash file that wew ould submit anyway afterwards [10:07] its fine [10:07] which is the wasteful bit [10:07] otherwise just use the NM state to fast fail [10:07] but yeah, maybe it's not worth the faff [10:07] though it would mean we'd never get that core file [10:07] but *shrugs* scale [10:08] so 1. if NM connected to non_paid and if we have crash to work on, then check if we can connect and if success, hurry, process crash and submit [10:08] if it's important we'll get it from someone [10:08] if we cant connect we just wait for 10-30 minutes or for next state_changed event naturally [10:08] it does process the queue every two hours regardless [10:09] though hm, online if it thinks its online [10:09] yes :) [10:09] that is every two hours it checks [10:09] eyah [10:09] yeah even [10:09] rvr: good morning [10:09] i really believe this stupid monitor check is what should die... rather do logic like above... do a hot call to serer if user has submit crash enabled AND there isa crash avail :) [10:10] i cant really think that someone feels that logic is calling home [10:10] its really activity driven and not regular/random [10:10] rvr: I seem to remember that there was a bug about "compartment names not translated", but I can't find it anywhere; am I hallucinating? Otherwise I'll file a new one [10:10] pitti: Good morning! [10:10] well they thought the general network manager connectivity check was "calling home" [10:10] and the "can_reach" is buggy i am pretty sure and will tell you reachable if youare behind hotel bound [10:10] pitti: Yeah, there is, let me find it [10:10] ev: oh you talk aobut a NM feature... well. i dont know that [10:10] but yeah, I think we can eat the problem of crash reports being sent to a captive portal and being marked locally as submitted [10:10] rvr: not on your spreadsheet, not on the blueprint, not against unity8 [10:10] think if thats a problem we just do it on ourr own on demand [10:11] for the sake of greatly simplifying this [10:11] rvr: erk, nevermind; "department", not "compartment" [10:11] rvr: (worst name *EVER*) [10:11] ev: i dont know. why wouldnt we realized that the we didnt upload successfully? [10:11] rvr: bug 1343129? [10:11] https://bugs.launchpad.net/ubuntu/+source/unity-scope-click/+bug/1343129 [10:11] bug 1343129 in Ubuntu Translations "Department names are not translatable" [High,Triaged] https://launchpad.net/bugs/1343129 [10:11] https://bugs.launchpad.net/ubuntu/+source/unity-scope-click/+bug/1358776 [10:11] i mean we do a rest call and dont talk to our server, we surely wwill get a different answer than we expect [10:11] Ubuntu bug 1343129 in Ubuntu Translations "duplicate for #1358776 Department names are not translatable" [High,Triaged] [10:12] asac: the protocol is pretty stupid - it just checks for a positive HTTP code [10:12] pitti: They are listed in the blueprint [10:12] so if it gets 200 back, it assumes everything went okay [10:12] ev: aaaanyhow... lets add some logging; we might be hunting a non-dragon :P [10:12] rvr: yeah, for some reason my brain told me "compartment" *sigh* :) [10:12] which is what a captive portal is going to do [10:12] yeah [10:12] will do [10:12] ev: you are using HTTP PUT without any wrapping protocol? [10:13] POST, but yes [10:13] it's BSON inside a POST [10:14] ok cool you send a whoospie verwsion X header [10:14] so we can change protocol to be smarter :) [10:14] give at least a json OK :) [10:14] answer [10:14] lol [10:14] yeah [10:15] cool. [10:15] well, in general i think we have far better report reliabiliy then a month back [10:15] as you suggest, changing the protocol is a better way of solving this than layering a captive portal check on top [10:15] so not super urgent. was just bad that i lost a hard to reproduce crash file [10:15] glad to hear it [10:15] because it was .upload [10:15] adding the logging now while I mull dropping the captive portal check [10:15] and not .uploaded [10:15] heh [10:16] butwell, i run into it one time every other day at minimum, so i will get it :) [10:16] ev: can you change whoopsie to force overwrite new crashes [10:16] even if .upload? [10:16] such heurisitic would suite my purpose right now better [10:17] ev: anywya. so now that i think about it, what usually works well is polling netlink. what is often not happening is getting proper events on change of routes etc. [10:17] ev: so in case you find that this route logic is a problem, i would try to switch it to poll from listen for changes [10:17] somehow [10:17] but only after logging [10:22] seb128, mako is fine re: time zone. Still trying to unbrick my other device. === MacSlow is now known as MacSlow|lunch === cking_ is now known as cking [11:18] pitti: I confirm the problem with Online Accounts, localization not working [11:18] rvr: yeah, I'm a bit stunned -- mo files are present, translations are complete, and I didn't even touch taht one yet with X-Use-langpack [11:18] rvr: ah wow, reading along with my German testing? [11:19] pitti: Yeah [11:20] rvr: I'll file a bug [11:20] pitti: Ok, I'll confirm it [11:22] rvr: done and put into the spreadsheet [11:22] rvr: I'll now add all my new bug reports to the blueprint [11:22] pitti: Awesome! You rock! [11:22] rvr: way too much red still :( [11:23] pitti: Indeed [11:23] rvr: heh, thanks, yw :) [11:23] although updating the pot of system-settings will fix quite a bunch of that === Ursinha-afk is now known as Ursinha [11:26] mardy: hey, so i got an account-plugin installed via click, but i cant get an .application to show up there, what do i need to put as the service id there? [11:30] jgdx, ok, thanks for testing [11:32] rvr: all done [11:34] pitti: \o/ [11:35] pitti: What's your overall opinion? Too much red, isn't it? [11:37] rvr: yeah, of course; the manual pot update sucks [11:39] Yup [11:41] rvr: I'm just talking to seb128 to update the pot of system-settings, so that we get unblocked at least there (that's the largest chunk) [11:42] pitti, feel free to commit an update, please just do it with the branch I pointed merged locally, so you get all the strings [11:42] seb128: ah, good point [11:42] pitti: Great [11:42] most of the ones which are missing are due to the incomplete sources list, which that mp fixes [11:42] pitti, danke ;-) [11:45] mardy: alternatively, do you know what our policy is for what account-plugins can be seeded onto the image [11:53] cwayne1: hi! So, if your click package is also shipping a .service file, use _ as service id [11:53] cwayne1: that is, the click package name without the version number [11:55] mardy: I tried that, no luck [11:56] i can add the account fine in system settings, and i do ship a .service, i just cant get anything applications to show up there [12:03] cwayne1: can I see the code? [12:03] mardy: sure, let me push it to a public place === alan_g is now known as alan_g|lunch [12:05] mardy: lp:~cwayne18/+junk/fitbit-click-account === Saviq_ is now known as Saviq [12:06] mardy: and emailed the .application [12:06] note i can get this same .application/scope to work perfectly with the debianized account-plugin in universe === _salem is now known as salem_ === MacSlow|lunch is now known as MacSlow [12:32] sil2100: did you see my question about moving the x-use-langpack: stuff to RTM? [12:33] pitti: hey! Sorry, missed it because of meetings/work, but I see the question now [12:33] no worries [12:34] pitti: so it should be fine to do a source-package copy of those (Colin even mentioned binary copy possibilities) - you're from QA so I suppose you can assure the quality yourself ;) [12:37] sil2100: yes, source/binary copies do work, I did it this morning for the new langpacsk [12:37] sil2100: I was just wondering how that plays along with rtm branches, or whether it generally shouldn't be done [12:38] sil2100: e. g. https://launchpad.net/ubuntu/+source/address-book-app/0.2+14.10.20140820-0ubuntu1 is something which we could trivially copy [12:38] stgraber: heya, can we et the custom channels setup for rtm channels? [12:40] anyone knows how i can start the intro/tutorial/OOBE wizard thingy after the fact one more time to check something? [12:42] phablet-config welcome-wizard --enable [12:42] sil2100: ah, many of those don't even have rtm branches yet, so easy [12:42] pitti: for what projects whould you like to do this? [12:42] pitti: since if they don't have rtm branches, or are like ubuntu-rtm-focused, then you can simply go on and do the copy [12:42] sil2100: I'm just running through to see for which that is the only current change; currenlty, address-book-app, unity-scope-click, indicator-location (checking the others) [12:43] sil2100: right, my thinking [12:43] sil2100: not sure about https://launchpad.net/ubuntu/+source/unity-scope-click/0.1.1+14.10.20140821.1-0ubuntu1 [12:43] pitti: for some projects that you are unsure maybe contacting upstream would be good, to make sure they're aware of something getting released there [12:43] sil2100: I suppose most changes that land today are meant for RTM, but for cases like these ^ we should ask the upstreams [12:43] sil2100: right [12:43] sil2100: I'll do the simple cases first to get them out of the way [12:44] pitti: unity-scope-click doesn't have an RTM silo yet, so there's the risk that when copying you'll pull unwanted changes [12:45] sil2100: what does that mean, an "RTM silo"? [12:45] pitti: so also try making sure you're not pushing anything else to RTM besides the wanted change [12:45] i. e. how are silos related to the package copies? [12:45] pitti: a silo for ubuntu-rtm, since we have seperate silos for ubuntu and ubuntu-rtm [12:45] seb128: yes, I know what an "RTM silo" is, just don't know what they have to do with the package copies [12:46] pitti: they're not directly related, I just mean that if someone just released something to ubuntu, but didn't release the same in ubuntu-rtm AND there is no ubuntu-rtm silo with these changes then we cannot do a src copy [12:46] sorry, sil2100 [12:47] sil2100: I'm confused -- if someone already released the current ubuntun package to RTM, or have it in an RTM silo, we don't need the copy in the first place [12:47] we only need it for those ubuntu-only packges which are not in RTM yet [12:47] pitti: right, but you only want to do srccopy of changes for langpacks, right? [12:47] meh, and of course people went right away and created RTM branches for everything, even though there are zero changes yet [12:47] that double workflow/landing is just crazyness [12:47] why oh why do we make our lives so ridiculously complicated and painful? [12:47] +1 [12:47] this is the anti-thesis to velocity [12:48] I didn't invent this ;) [12:48] just for the record I'm not landing anything to rtm, that's just ridiculous the way things are set up [12:48] if people want to work on changes which aren't ready for RTM, then *those* should be in separate branches [12:48] Anyway, what I mean is: [12:48] as I'd expect most (all?) folks to work on RTM now [12:48] You want to push langpack changes to RTM, and I just want you to make sure that when you do srccopies that nothing BESIDES those langpack changes is copied there [12:48] I already spent 3 days for super-simple changes which should have been done in 10 minutes [12:48] I'm really not feeling like doing that all over again TBH [12:48] As we have a requirement of QA signing-off everything that goes through the CI Train to RTM [12:49] sil2100: ah, ok, then we might viciously agree, but just misunderstand [12:49] Yeah, I'm changing the train to work with that now, i.e. that you can live without RTM bzr branches in case everything you develop is for RTM [12:49] sil2100: e. g. https://launchpad.net/ubuntu/+source/unity-scope-click/0.1.1+14.10.20140821.1-0ubuntu1 -> not copy, as I don't know [12:50] sil2100: with https://launchpad.net/ubuntu/+source/indicator-location/13.10.0+14.10.20140820-0ubuntu1 -> yes, copy [12:50] sil2100: is that what you mean? [12:50] pitti: yes, exactly ;) [12:50] ah, good [12:51] sil2100, how do you request a copy from utopic to rtm? [12:51] pitti: well, I would generally say you could push all of that, since you're QA ( ;) ), but I think CI Train landings need some specific testing that needs to be done [12:51] $ copy-package -b --from ubuntu -s utopic --to ubuntu-rtm --to-suite 14.09 address-book-app [12:51] seb128: ^ [12:51] pitti, that's not a request, that's doing it :p [12:51]