| xnox | infinity: i'm confused, the only things in main that pull-in lua are ibus-pinyin, librpm, vim-gnome, libquvi7, if it's purely due to extensions I'd argue strongly for pushing _all_ lua into universe. | 00:00 |
|---|---|---|
| teward | i'm just going to go write up the "jcastro: thanks for making everyone think something way ahead of being able to make a statement to the effect of the one you did" rant now... and let you argue it out, i don't particularly care anymore which way the MIR goes. | 00:00 |
| infinity | xnox: You can argue that all you want, but it's not really going to help this conversation. | 00:00 |
| sarnold | teward: I don't see much point in pointing figures at jcastro, fwiw.. | 00:01 |
| xnox | the technical solution here is to port nginx to 5.2 =))))) and no conversations would be needed... | 00:01 |
| infinity | Agreed. Looks like probably about an hour of research, an hour of Googling, a few hours of code and, then, the hard part, validating it. | 00:02 |
| infinity | I can't do the latter, cause I don't actually use it. | 00:02 |
| infinity | Not have any idea how. | 00:02 |
| infinity | s/Not/Nor/ | 00:02 |
| sarnold | .. and then you'd wind up with a module that can't actually execute the code that the users have written for it, because they wrote their code for lua 5.1, which might as well be known as "lua classic" or something, compared against "new lua".. | 00:03 |
| teward | sarnold: i haven't stopped pointing fingers at jcastro since he posted two days after the MIR was filed that nginx was going to be in main | 00:03 |
| infinity | It's also nowhere near the top of the list of things I care about doing before release. | 00:03 |
| infinity | sarnold: See, people claim that, but the language doesn't appear to have changed THAT much. | 00:03 |
| teward | infinity: i can get you a list of examples to test, to see if it interprets Lua. I can't give you Lua applications to fully test the module though. | 00:03 |
| infinity | sarnold: But there is also the third (fourth, fiftfh, I've lost count) option of admitting that lua5.1 is important enough to people to support it for trusty. | 00:04 |
| sarnold | infinity: true, without having made the change to naything I care about I can't really judge how much effort it is | 00:04 |
| teward | although if I put out a few requests to certain individuals i could probably grab a ton of examples | 00:04 |
| teward | s/examples/test code/ | 00:04 |
| sarnold | infinity: true. lua 5.1 is probably "done" by now anyway, what with being ancient :) | 00:04 |
| infinity | sarnold: lua5.1 was in main up until saucy. | 00:05 |
| * infinity suspects this was a doko-initiated "bigger versions are better!!" transition... | 00:06 | |
| sarnold | infinity: *sigh* that just might be the least annoying path forward. | 00:06 |
| sarnold | bigger isn't better? :) | 00:06 |
| xnox | sarnold: well lua5.1 is supported for another 3 years on precise =) | 00:06 |
| sarnold | xnox: <3 :) | 00:06 |
| sarnold | that would make it a little less bitter pill to swallow, what's another two years? heh | 00:07 |
| xnox | sarnold: and in 3 years time, we can debate about SRUing nginx to compile against 5.2. | 00:07 |
| xnox | sarnold: at least we only have 2 pythons in main (2.7 and 3.4). | 00:07 |
| infinity | sarnold: Worth noting that we've done exactly zero security or SRU releases for lua. Ever. | 00:07 |
| sarnold | infinity: yay :) | 00:08 |
| sarnold | xnox: hoooray for that indeed :) | 00:08 |
| infinity | xnox: SRUing it to change the lua version would be Bad. | 00:08 |
| infinity | What we ship is what we're stuck with. | 00:08 |
| sarnold | but we can debate it all the same, right? :) | 00:08 |
| infinity | The language didn't change a lot, but it *did* change. | 00:08 |
| infinity | You don't break people's interpreters in a stable release. | 00:08 |
| xnox | infinity: sarnold: bug shipping nginx with lua opens up attack surface. Previously it only was things like vim-gnome that used lua in main =) | 00:09 |
| xnox | s/bug/but/ | 00:09 |
| infinity | Shipping daemons opens attack surface. Let's stop. | 00:09 |
| sarnold | xnox: that's the most hilarious part; the actual nginx_lua module will live in a binary package that is in universe. | 00:09 |
| xnox | sarnold: oh exelent, that's about as good as we supported libav ;-) | 00:09 |
| sarnold | xnox :) | 00:10 |
| infinity | sarnold: Honestly, I think re-promoting lua5.1 is probably the least icky option here. | 00:10 |
| xnox | it was in main as a build-dep, but not much else. | 00:10 |
| infinity | sarnold: I already find the extra binary distasteful, but at least that one is simple, we can direct people to -core for supported, or -full to be like Debian. | 00:10 |
| sarnold | infinity: agreed, you talked me into it. | 00:10 |
| infinity | Alright. Let's do that, then. I'll review teward's current patchset, re-add lua, and we'll go from there. | 00:11 |
| infinity | We all agreed? | 00:11 |
| infinity | Well, all except xnox, who seems to be on random tangents. | 00:11 |
| sarnold | yes, do you want any comment in the bug from me about it? | 00:11 |
| teward | infinity: i can revise the debdiff if you'd like, remove the "Drop lua" bits. | 00:11 |
| teward | (for nginx) | 00:11 |
| teward | i need a copy of that locally anyways | 00:11 |
| infinity | teward: I can do that myself faster than you can, don't worry about it. | 00:11 |
| teward | infinity: awesome. :) | 00:11 |
| teward | (I had the debdiff on screen though :P) | 00:11 |
| infinity | teward: If I find any bugs in your current patches, I'll just fix them and pretend you did. I'd rather get this behind us than do more back and forth. | 00:11 |
| teward | infinity: awesome. | 00:12 |
| infinity | sarnold: Sure, if you want to summarize the last thousand lines of pointless drivel in a few grunts and smiley face, that would be great. | 00:12 |
| sarnold | infinity: great, will do | 00:13 |
| infinity | teward: When you re-did your debdiff, you didn't take into account the new common_configure_flags setup in debian/rules. Will fix. | 00:22 |
| teward | infinity: oops. i missed that. thanks. | 00:22 |
| teward | infinity: i have to disappear for a bit, but messages are logged so feel free to continue to point out mistakes I made, and I'll see them later. | 00:23 |
| * teward disappears | 00:23 | |
| infinity | teward: You also did a straight copy/paste of the debhelper files without s/full/core/, so you were installing the full binary into the core package. :P | 00:30 |
| teward | infinity: eheheh, whoopsies. serves me right for debdiff-ing late at night | 00:31 |
| teward | s/late at night/when tired/ | 00:31 |
| teward | infinity: i should probably just learn that lesson and be done with it | 00:32 |
| teward | infinity: thanks though for pointing out my mistakes. :) | 00:32 |
| === stgraber_ is now known as stgraber | ||
| jdstrand | infinity, sarnold: re lua updates> sounds like we are due. istr a similar argument made for erlang btw. and that is a pita to update | 00:36 |
| jdstrand | I am not weighing in on the argument, sarnold can make the call. just saying I've heard it before | 00:37 |
| infinity | jdstrand: Personally, I think the upstream view is purely based on them not having the clue to do the porting, but I don't have the time to JFDI and send them a patch. | 00:38 |
| infinity | jdstrand: But given how much security support we've never given lua in the past, I think we can continue with that stellar track record. :) | 00:38 |
| * teward laughed too hard at that xD | 00:38 | |
| sarnold | huzzah! celebratory beers all around :) | 00:38 |
| teward | s/beers/shots/ | 00:39 |
| sarnold | speaking of erlang, 17.0 looks due on 2014-03-26... | 00:42 |
| infinity | I refuse to believe anyone uses erlang. | 00:44 |
| infinity | Then again, everything I know about Lua, I know from hacking WoW modules. So, what do I know about languages? :P | 00:45 |
| === jasoncwarner___ is now known as jasoncwarner | ||
| * elmo pulls a rabbitmq out of a hat for infinity | 00:50 | |
| sarnold | lol :) | 00:51 |
| infinity | elmo: What, no couchdb? | 00:52 |
| bluesabre | pitti, others: I missed a minor detail in my package this morning, can we sponsor this updated package? | 01:07 |
| bluesabre | https://bugs.launchpad.net/ubuntu/+source/light-locker-settings/+bug/1291699 | 01:07 |
| ubottu | Launchpad bug 1291699 in light-locker-settings (Ubuntu) "Please add python-psutil to Depends for light-locker-settings" [Undecided,Confirmed] | 01:07 |
| YokoZar | Is it too late to fix this sort of thing? https://bugs.launchpad.net/ubuntu/+source/p11-kit/+bug/1027299 (I'll note we did a similar SRU backport ofgnome-keyring https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/859600) | 01:07 |
| ubottu | Launchpad bug 1027299 in p11-kit (Ubuntu) "Seperate out p11-kit-trust.so into a multiarch package to prevent errors in Wine" [Undecided,Confirmed] | 01:07 |
| ubottu | Launchpad bug 859600 in gnome-keyring (Ubuntu Precise) "Please convert gnome-keyring to multiarch" [High,Confirmed] | 01:07 |
| RAOF | YokoZar: Given that we've SRUd in multiarch support I don't see why it shouldn't be possible to get multiarch support a FFe. | 01:19 |
| infinity | sarnold, teward: Alright, for better or worse, it's uploaded and promoted. | 01:24 |
| dobey | RAOF, YokoZar: i think the issue isn't whether it's too late, but more about supporting of upgrades | 01:24 |
| sarnold | infinity: thank you :) | 01:25 |
| sarnold | teward: thank you :) | 01:25 |
| dobey | YokoZar: at least if you're talking about getting the keyring backport to precise | 01:25 |
| YokoZar | dobey: I'd be happy with trusty honestly | 01:26 |
| YokoZar | For p11-kit | 01:26 |
| jcastro | sarnold, infinity, teward, hi guys. | 01:26 |
| dobey | YokoZar: i don't think it's too late to multiarch something, no | 01:26 |
| jcastro | hey so, my blog post pointed out that the MIR was filed, and Ars Technica posted their story that it was a done deal. | 01:26 |
| dobey | i don't know that i'd even say you must have an FFE approval for multi-arching a package | 01:26 |
| infinity | jcastro: Yeah, no real harm done, just an annoyance. | 01:27 |
| jcastro | so I edited my post to make it clear that the MIR had started, I didn't make any promises or anything other than pointing out that a MIR had been filed because hey, someone filed a MIR. | 01:27 |
| infinity | jcastro: Though, it might pay to not blog about process, since people always misinterpret "we're considering" as "we're doing". | 01:27 |
| dobey | YokoZar: i'd just call it a bug fix | 01:27 |
| jcastro | infinity, true that. | 01:28 |
| infinity | (This is one of the fundamental issues I've always had with blueprints too, the notion that once someone's written down intent, it's going to happen) | 01:28 |
| jcastro | infinity, but hey, all the work is done in the open, and if we come back and say "you know, we looked at all the issues people had, and here is what blocked it." that's fine | 01:28 |
| infinity | YokoZar: If it's done sanely and tested, I'd approve an FFe for that. | 01:28 |
| dobey | infinity: the best part about blueprints is you can't delete them or anything, and anyone can create one! :) | 01:28 |
| infinity | dobey: ANYONE. Trust me, I know. | 01:28 |
| jcastro | the entire MIR process is public, and if something didn't make it, then fine. We know why it didn't, it's clearly documented, given X resources and X time, that's how the world works | 01:29 |
| dobey | jcastro: just disavow all knowledge of everything. it works for the nsa. | 01:30 |
| infinity | And Ollie North. | 01:31 |
| dobey | exactly! | 01:31 |
| infinity | I may have just dated myself with that comment., | 01:31 |
| jcastro | I'd be more than happy to take the blame and say "look, if you care about nginx use the PPA, we tried to get it in, but LOL LUA modules, we'll work on it over time." | 01:31 |
| infinity | jcastro: Too late. It's in main. | 01:31 |
| dobey | yeah, ars said so! | 01:32 |
| infinity | Well, so does launchpad. | 01:32 |
| teward | infinity: sarnold: no, thank you both! | 01:35 |
| teward | jcastro: yeah, sorry about once again placing blame. My point at the time is the one that infinity made, people interpret "we're considering" as "we're doing" if they don't understand the difference | 01:36 |
| teward | (which is most people) | 01:36 |
| jcastro | yeah I get that | 01:36 |
| teward | in any case, it's been promoted, so no harm done. | 01:36 |
| * teward yawns | 01:36 | |
| jcastro | teward, even without lua it's a win to get it in 14.04 | 01:41 |
| * jcastro raises a beer | 01:41 | |
| teward | jcastro: truth | 01:43 |
| teward | jcastro: although I think we were going to get the Lua module in anyways... | 01:43 |
| teward | because AIUI, the agreement was to repromote lua 5.1 to main as a build-dep here? | 01:44 |
| teward | s/agreement/decision/ | 01:44 |
| xnox | slangasek: i'm not reasonably happy with https://code.launchpad.net/~xnox/ubuntu/trusty/plymouth/private-upstart-socket/+merge/210672 in the process of fixing all of my pet-peaves, i've resonably tested your fix in a variety of scenarios and it's all fine =) | 02:19 |
| xnox | i hope somebody can review my patch series ;-) | 02:20 |
| micahg | dobey: multiarching a package is a major change that needs release team approval as it can impact reverse dependencies (or so I have been told) | 02:21 |
| micahg | that's not to comment on how readily it might be approved | 02:21 |
| rmk | So, 3 forms of init with trusty? | 03:44 |
| xnox | =))))) | 03:47 |
| xnox | we have way more than 3 in the archive i believe. | 03:47 |
| rmk | 3 forms of init on an lts release.. | 03:48 |
| infinity | rmk: Just the one. | 03:52 |
| rmk | Is everything systemd? | 03:52 |
| infinity | No, everything is upstart. | 03:52 |
| infinity | There will be no systemd in trusty. | 03:52 |
| rmk | OK great. | 03:52 |
| === FJKong_afk is now known as FJKong | ||
| === kitterma is now known as ScottK | ||
| === NCommander is now known as Guest44669 | ||
| === Guest44669 is now known as NCommander | ||
| slangasek | xnox: does your plymouth branch deal with disconnects by upstart? (e.g., upstart restarts in the middle of boot... which is a real thing that happens with cloud-init :) | 05:14 |
| YokoZar | infinity: regarding our conversation earlier, would it be sufficient for dpkg if wine1.6 conflicted with wine1.7, or is it important that I have the conflicts line in the same package as the replaces line? | 05:39 |
| pitti | Good morning | 05:39 |
| Mirv | @pilot in | 05:48 |
| === udevbot changed the topic of #ubuntu-devel to: Trusty Beta 1 released! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Mirv | ||
| pitti | bluesabre: done | 06:01 |
| Unit193 | sarnold: Heh, FWIW, downgrading wouldn't have been a good answer, didn't work. :P (bash-completion) | 06:20 |
| Mirv | pitti: hi! would you have time to help my piloting a bit, since you already started on some of the XFCE packages? I'd have three ready and checked for upload. | 07:03 |
| Mirv | these are fine to upload as is, and I tested them on XFCE from my own PPA: 1. lp:~noskcaj/ubuntu/trusty/xfce4-places-plugin/gtk3-bookmarks 2. lp:~noskcaj/ubuntu/trusty/thunar/1280641 (bzr bd -S -kMYKEY, no changes were needed) | 07:03 |
| Mirv | thirdly, there's https://launchpad.net/~timo-jyrinki/+archive/ppa/+files/shimmer-themes_1.7.1-0ubuntu1.dsc I've tested to seemingly work and tested that each orig tarball matches (diff -urN) the git upstream | 07:04 |
| pitti | Mirv: ah, you can't upload yourself? sure, I can upload the first two | 07:05 |
| Mirv | pitti: yes, that's the thing, I can only prepare everything until the upload part | 07:05 |
| Mirv | pitti: thanks! | 07:05 |
| Mirv | I was also looking at tumbler and light-locker-settings but then they disappeared :) | 07:05 |
| pitti | Mirv: yes, I uploaded them as I got pinged about them | 07:06 |
| pitti | Mirv: they were a followup from yesterday | 07:06 |
| Mirv | yep, I noticed you answering | 07:06 |
| pitti | Mirv: please approve the MPs in LP | 07:07 |
| pitti | Mirv: I guess you can't mark an MP as "merged" yourself; I can do that | 07:08 |
| Mirv | pitti: done, thanks | 07:08 |
| Mirv | I should have done that | 07:08 |
| pitti | Mirv: uploaded 1. and 2. | 07:10 |
| Mirv | thank you. the 3. can maybe wait for micahg or someone else, but I commented on the bug #1291739 that I've checked it matches upstream and seems to work (I browsed through the themes in XFCE) | 07:11 |
| ubottu | bug 1291739 in shimmer-themes (Ubuntu) "[needs-packaging] shimmer-themes-1.7.1" [Wishlist,Triaged] https://launchpad.net/bugs/1291739 | 07:11 |
| pitti | Mirv: yep, looking at this | 07:11 |
| pitti | Mirv: watching sabdfl's keynote ATM, so I'm a tad slow :) | 07:11 |
| Mirv | oh, good point, I was meaning to do that too | 07:12 |
| pitti | Mirv: having a checked, dgettable and ready-to-upload .dsc from you is nice, thanks | 07:12 |
| pitti | Mirv: uploaded | 07:14 |
| Mirv | \o/ thank you | 07:14 |
| Unit193 | Thank you both. | 07:14 |
| zyga | good morning | 07:49 |
| pitti | xnox, ogra_: I'm afraid I don't know what's wrong with dial-number; works fine here, I asked some questions in bug 1287628 | 08:19 |
| ubottu | bug 1287628 in dialer-app (Ubuntu) "invoke_incoming_call() doesn't seem to work, result is not checked, yet test_incoming test passes (?!)" [Undecided,Confirmed] https://launchpad.net/bugs/1287628 | 08:19 |
| pitti | xnox: is there are reason why you didn't upload the ofono python3-dbus fix? I'm happy to upload it (it's an obviously correct and trivial fix, and I tested it on the phone) | 08:28 |
| pitti | xnox: and that might be the reason for failing the dialer-app tests in CI? | 08:28 |
| Mirv | if anyone is interested in iDevices support and/or has some of them, I've made a git snapshot packaging branch, a test PPA and a call for testing at bug #1207812 (to get test results before making it a FFe request) | 08:37 |
| ubottu | bug 1207812 in libimobiledevice (Ubuntu) "iOS 7, Trust Prompt Looping" [Medium,Triaged] https://launchpad.net/bugs/1207812 | 08:37 |
| === tkamppeter_ is now known as tkamppeter | ||
| bluesabre | thanks pitti! | 09:50 |
| ogra_ | pitti, i think the issue with the ofono-scripts are not the scripts themselves, but the question of "why did apport not create .crash files for the exceptions before the switch (or why does it now do that)", it simply trashes your test results now | 09:53 |
| pitti | ogra_: aah | 09:53 |
| pitti | ogra_: so that's the python-apport vs. python3-apport issue? (you need to have the version installed for the python version you want to catch exceptions for) | 09:54 |
| ogra_ | looking at the ofono-phonesim-autostart it is even designed to cause exceptions by looping until a connection can be made | 09:54 |
| pitti | it's indeed a bit unfortunate that dial-number 199 causes an ofono exception | 09:54 |
| ogra_ | so the behavior is probably fine, the .crash files arent | 09:54 |
| pitti | ogra_: ok, so I completely misunderstood this | 09:54 |
| pitti | I thought dial-number etc. was now broken with the py3 port | 09:55 |
| pitti | as it has always thrown these exceptions, also with py2 | 09:55 |
| ogra_ | if the exceptions arent critical it is fine to hide them | 09:55 |
| pitti | ogra_: ok, then xnox' branch makes much more sense to me now | 09:55 |
| ogra_ | well, but apport never created .crash files for them before | 09:55 |
| pitti | ogra_: yes, because we don't install python-apport by default | 09:55 |
| ogra_ | which is what UTAH collects | 09:55 |
| pitti | but we do install python3-apport | 09:55 |
| ogra_ | right | 09:56 |
| pitti | ogra_: thanks, that moved it from "WTH NFC" to "completely clear" to me now, *phew* | 09:56 |
| ogra_ | :) | 09:56 |
| ogra_ | sorry that i wasnt clear before :) | 09:56 |
| pitti | ogra_: I'll comment on https://code.launchpad.net/~xnox/dialer-app/fix-dial-number-crash/+merge/209677 and approve | 09:57 |
| ogra_ | good | 09:57 |
| pitti | ogra_: no worries, we didn't really talk about it so far; UDS and all | 09:57 |
| ogra_ | yeah | 09:57 |
| ogra_ | but i had researched some on the topic already ... i could have told you earlier if i had remembered ... i might just be getting old :) | 09:57 |
| pitti | ogra_, xnox: https://code.launchpad.net/~xnox/dialer-app/fix-dial-number-crash/+merge/209677 understood, commented on, and approved; thanks! | 10:01 |
| pitti | sorry for the confusion | 10:02 |
| jamespage | pitti, any chance you could put your archive-admin hat on and promote the main inclusions blocking package builds for glance, cinder and ceilometer? | 10:21 |
| pitti | jamespage: sure, do you have the bug # at hand? | 10:22 |
| pitti | jamespage: I don't see those packages on http://people.canonical.com/~ubuntu-archive/component-mismatches.svg | 10:22 |
| jamespage | pitti, they are all on http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg | 10:23 |
| pitti | oh, -proposed | 10:23 |
| jamespage | pitti, yup | 10:23 |
| pitti | jamespage: all done | 10:25 |
| jamespage | pitti, you are a star - thanks very much! | 10:25 |
| MacSlow | Is there a simple way to query the type of device an app is running on... via the SDK? | 10:46 |
| rbasak | MacSlow: try #ubuntu-app-devel | 10:49 |
| MacSlow | rbasak, thx | 10:50 |
| bluesabre | ok, this should be my last package for this week... | 10:53 |
| bluesabre | https://bugs.launchpad.net/ubuntu/+source/lightdm-gtk-greeter/+bug/1291913 | 10:53 |
| ubottu | Launchpad bug 1291913 in lightdm-gtk-greeter (Ubuntu) "[needs-packaging] lightdm-gtk-greeter 1.8.3" [Undecided,Confirmed] | 10:53 |
| bluesabre | Any interested sponsors? Please let me know if you have any questions. | 10:53 |
| Mirv | @pilot out | 11:15 |
| === udevbot changed the topic of #ubuntu-devel to: Trusty Beta 1 released! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| Mirv | bluesabre: sorry, I was piloting but I think I don't have time today for more since other stuff is needing attention | 11:17 |
| Mirv | but on the plus side I got your shimmer-themes in :) | 11:17 |
| xnox | Can somebody help me out understanding the jenkins failures, of autopilot tests on mako as reported here https://code.launchpad.net/~xnox/gallery-app/fix-sample-dir/+merge/210517/comments/496524 I have a mako device, but i don't get those failures. | 11:56 |
| xnox | How is that executed? | 11:56 |
| === MacSlow is now known as MacSlow|lunch | ||
| bluesabre | Mirv: that's fine, thanks for that btw! | 11:56 |
| === Sweetsha1k is now known as Sweetshark | ||
| Saviq | seb128, sorry for hitting you again, but you're the closest one I can think will know about this - this user confirms my bugs the whole morning (like 10 already) https://launchpad.net/~eddiedog988/+karma is that expected / encouraged? he's even accepting bugs he definitely should not (like ubuntu-ux) and such... | 12:13 |
| seb128 | Saviq, can you give an example? | 12:14 |
| Saviq | seb128, here's the last one https://bugs.launchpad.net/bugs/1290750 | 12:14 |
| ubottu | Launchpad bug 1290750 in gstreamer1.0 (Ubuntu) "totem-video-thumbnailer crashed with SIGSEGV in gst_mini_object_unlock()" [Medium,Confirmed] | 12:14 |
| Saviq | seb128, but then https://bugs.launchpad.net/bugs/1291458 he confirmed the ubuntu-ux task | 12:14 |
| ubottu | Launchpad bug 1291458 in unity8 (Ubuntu) "Volume buttons change ringtone volume when suspended" [Undecided,Confirmed] | 12:15 |
| Saviq | TBH looks like bot behaviour, really... especially since the user is registered two weeks ago | 12:16 |
| seb128 | Saviq, well, confirming bugs is usually ok, if ubuntu-ux is special you should maybe contact him to say that | 12:16 |
| Saviq | seb128, yeah, well, I doubt he managed to confirm all those bugs in the short time he accepted them... | 12:16 |
| seb128 | right, seems like somebody who is going through reports and clicking confirm if he thinks those are real bugs | 12:17 |
| seb128 | or something | 12:17 |
| Saviq | 10s per bug... https://launchpad.net/~eddiedog988/+karma | 12:17 |
| seb128 | Saviq, I think the standard procedure to ask for an user to be locked is to report the issue through https://answers.launchpad.net/launchpad/+addquestion | 12:18 |
| seb128 | Saviq, but ask on #launchpad for confirmation | 12:18 |
| Saviq | seb128, will do | 12:19 |
| xnox | thanks for locking ~eddiedog988, indeed a lot of havoc caused. | 12:31 |
| smoser | xnox, around ? | 12:51 |
| xnox | smoser: yeah. | 12:51 |
| xnox | smoser: so i've pushed further updates, but i was not able to reproduce the problem you reported using your scripts. | 12:52 |
| smoser | ok. so you were right. the script was bogus. | 12:52 |
| pitti | ah, I just undid some damage from eddiedog988 | 12:52 |
| smoser | xnox, http://paste.ubuntu.com/7084468/ is 'go-test | 12:52 |
| smoser | now, and that works for me. and shows how i prepared the images in comments at the top | 12:52 |
| xnox | smoser: as in it's all good / resolves your problem? | 12:52 |
| smoser | serial-patched-01.log: http://paste.ubuntu.com/7084469/ | 12:53 |
| smoser | serial-unpatched-01.log: http://paste.ubuntu.com/7084470/ | 12:53 |
| xnox | smoser: it's best to view them with "less -r" due to keycodes usage. | 12:53 |
| smoser | line 417 and 419 is a dupe, no? | 12:54 |
| xnox | smoser: well i've fixed for _no_ startpar-bridge crap to show up, with further updates in the plymouth branch + sysvinit upload. | 12:54 |
| xnox | smoser: i'm not sure where the "naked" messages are comming from - e.g. the line: 443 "bootmisc.sh". Let me recreate the VMs using your updated script and all updated plymouth / sysvinit. | 12:55 |
| smoser | xnox, ok. you can point me at some debs too if you want, and I can just re-patch them. but the script shows exactly what i did to patch the images. | 12:58 |
| elopio | xnox: I've just recently ran all the gallery tests on my phone, and they passed. | 12:58 |
| smoser | xnox, and also, i can't really explain this, but: http://paste.ubuntu.com/7084495/ | 12:58 |
| elopio | are you using any PPA there? | 12:58 |
| === _salem is now known as salem_ | ||
| smoser | xnox, the patched takes like 15% longer every time (32s to 39s) | 12:59 |
| xnox | elopio: i've made a merge proposal, and i believe the tests are running with my change in. | 13:00 |
| xnox | elopio: but when testing locally with my change in, it all passes, but it doesn't as reported by jenkins. | 13:00 |
| xnox | elopio: so i'm wondering exactly _how_ the ps-jenkins is executing AP tests on mako. E.g. full-steps to reproduce, as I don't see that in any of the output. | 13:00 |
| xnox | smoser: i would not be expected _such_ big delay =/ | 13:01 |
| elopio | xnox: it's hard to tell just from the traces without screenshots, but when all the tests fail it's likely that the application could be opened | 13:02 |
| xnox | elopio: ... how were the tests started / provisioned to the device. | 13:03 |
| xnox | elopio: it recently got converted into a click, is it running the tests like a click? | 13:03 |
| * ogra_ humms "run it like a click ... yeah" | 13:03 | |
| ogra_ | sounds like hip hop :) | 13:04 |
| elopio | xnox: the package inflating: package_archive/archive/work/output/gallery-app-autopilot_0.0.67+14.04.20140306bzr925pkg0trusty3452+autopilot0_all.deb is installed | 13:04 |
| elopio | that's the one you get from one of the jenkins links. | 13:05 |
| elopio | I don't know how the actual app is being installed. | 13:05 |
| xnox | elopio: right, so probably not. Right, let me try fetching that and running tests from that package then. | 13:05 |
| xnox | elopio: thanks. | 13:05 |
| xnox | smoser: so the $ less -r boot-patched-01.log -> looks wonderful | 13:06 |
| xnox | smoser: without any dupes. | 13:06 |
| xnox | smoser: http://paste.ubuntu.com/7084520/ | 13:06 |
| smoser | xnox, thats unfiltered through less -r ? | 13:07 |
| smoser | and wrt speed difference, if that is real, i can't take a 15% performance regression on boot/shutdown cycle. | 13:08 |
| smoser | if its real. | 13:08 |
| smoser | i dont 'knwo why my data would be bad, but i'm not 100% convinced its good at the moment. | 13:08 |
| xnox | smoser: the serial console does have correct " * Starting Bridge file events into upstart" but has an extra name of the upstart job printed, e.g. "upstart-file-bridge". I don't know where the extra name of the upstart job is printed from. | 13:09 |
| xnox | I'll open a separate bug about that. | 13:09 |
| xnox | smoser: for me, here locally it's 13s vs 11s. Let me move the original disks to SSD and check, how that's different. | 13:10 |
| smoser | $ echo "scale=3; 13/11" | bc | 13:14 |
| smoser | 1.181 | 13:15 |
| smoser | $ echo "scale=3; 39/32" | bc | 13:15 |
| smoser | 1.218 | 13:15 |
| smoser | those are in the same range, both not acceptable really. | 13:15 |
| smoser | and making the disks go faster isn't a "fix" | 13:15 |
| rbasak | jamespage: I'd appreciate some quick eyes on https://launchpadlibrarian.net/169357857/add-build-tests.debdiff. I don't like: having to add all runtime depends as build-deps to make the test suite run, and having to use override_dh_auto_test. | 13:15 |
| xnox | smoser: sure, but it makes the baseline the same. So what's the penalty for these numbers? http://paste.ubuntu.com/7084560/ | 13:15 |
| * rbasak wonders if there's some kind of nosetests dh sequencer or something | 13:16 | |
| rbasak | (or anyone else) | 13:16 |
| xnox | rbasak: pybuild can do nosetests, grep through python-modules / python-apps debian teams svns? | 13:16 |
| xnox | smoser: cause e.g. on those runs, fully in ram, sometimes "patched" was quicker than "unpatched". | 13:17 |
| jamespage | rbasak, it would be nice if there was (some kind of nosetests dh sequencer) | 13:19 |
| jamespage | rbasak, that generally looks OK | 13:19 |
| jamespage | rbasak, I might ping upstream and get them to re-align with 0.17.5 | 13:20 |
| rbasak | jamespage: I spoke to upstream in #juju. They're ready to release AIUI, but are waiting for a juju-core release first. | 13:21 |
| GunnarHj | pitti: ping? | 13:21 |
| jamespage | rbasak, ah - OK - makes sense | 13:21 |
| jamespage | rbasak, I think for the time being that is generally +1 then | 13:21 |
| rbasak | xnox, jamespage: thanks. I'll leave it for now since we're in a hurry, but will see if I can convert the packaging to use pybuild in the future. | 13:21 |
| xnox | smoser: so in my run, i have total of 10 runs patched at 108s, unpatched at 101s. which is a 6.9% penalty. But i'm not a stats person to identify error margins here, cause we are measuring at 1s resolution here thus all runs are +/- 0.5s | 13:23 |
| xnox | smoser: average patched time is 10.8s, average unpatched 10.1s | 13:24 |
| xnox | smoser: i did rearrage events of the plymouth startup & shutdown events earlier in the cycle (possibly whilst cloud images were still affected by plymouth segfaulting) thus the do now may prolong boot/shutdown a little, but we get a more consistent boot & shutdown. | 13:26 |
| pitti | hey GunnarHj | 13:27 |
| GunnarHj | Hi pitti! | 13:27 |
| GunnarHj | pitti: Do you possibly have time to 'push the button' as regards https://mentors.debian.net/package/mythes-sv ? | 13:27 |
| mlankhorst | huh? | 13:28 |
| mlankhorst | is perl bugged on ppc64el? | 13:29 |
| pitti | GunnarHj: yes, can look | 13:29 |
| mlankhorst | https://launchpadlibrarian.net/169358009/buildlog_ubuntu-trusty-ppc64el.mesa_10.1.0-1ubuntu1~ppa1_FAILEDTOBUILD.txt.gz | 13:29 |
| GunnarHj | pitti: Thanks! | 13:29 |
| pitti | GunnarHj: do you mind if I upload it as -1? an initial -2 is ugly | 13:29 |
| smoser | xnox, plymouth did not segfault to my knowledge with current lp:ubuntu/plymouth | 13:30 |
| GunnarHj | pitti: Not at all, it it's possible it's better. | 13:30 |
| GunnarHj | if | 13:30 |
| pitti | GunnarHj: uploaded to Debian and Ubuntu NEW | 13:33 |
| pitti | GunnarHj: to Ubuntu as 1.3.1-1~fakesync1 | 13:33 |
| pitti | as it's not a real sync yet, needs to pass Debian NEW first; but I figure you want it in Ubuntu ASAP | 13:34 |
| GunnarHj | pitti: Thanks! Well, guess I could have waited for the real sync, but thanks anyway. ;-) | 13:34 |
| psusi | say, why does packages.ubuntu.com only show amd64 and i386? What about the other archs? | 13:35 |
| xnox | psusi: there is a contact person on the bottom of the packages.ubuntu.com pages... | 13:36 |
| zbenjamin | tedg: hey ted, do you remember me? I'm the guy working on the ubuntu qtcreator integration, i'm currently at a state where i need to run a deployed application on the phone, currently we deploy a exploded directory and run the app from there. However that seems to not work anymore (qmlscene complains about -I is not known as a paramter and the appwindow also does not show up) | 13:49 |
| zbenjamin | tedg: i was wondering if there is any way for me to upstart a desktop file directly without it being installed by click | 13:50 |
| tedg | zbenjamin, There is, but wouldn't it be better to just install it per-user with click? | 13:50 |
| zbenjamin | tedg: well bzoltan said he does not want to do that in the development process because it would take long | 13:51 |
| tedg | i.e. my app becomes the dev version for the account | 13:51 |
| zbenjamin | i also would need a way to somehow control the running application from cli , so i can start/stop the app and i also need to run gdbserver with it for debugging :) | 13:52 |
| tedg | zbenjamin, We should fix it taking too long. :-) We can launch the app but you won't get any of the other things you might want to test, like registering for a URL pattern. | 13:52 |
| tedg | I think if you just untar a directory, you'll always get something half functioning. | 13:53 |
| xnox | zbenjamin: it doesn't take long =) ask for numbers before you believe it ;-) | 13:53 |
| zbenjamin | tedg: ok wait i maybe try to pull in bzoltan here | 13:53 |
| xnox | zbenjamin: also gdbserver and QML apps?! is that really the common case debugging? | 13:55 |
| zbenjamin | xnox: qml apps + cpp backend | 13:55 |
| xnox | zbenjamin: ok. | 13:55 |
| tedg | How are you installing gdbserver? To use QtCreator do you have to make your image writable? | 13:55 |
| zbenjamin | xnox: i have a few cases: 1) pure QML, 2)pure HTML, 3)QML+Cpp, 4)C++ | 13:56 |
| zbenjamin | tedg: thats a good question, i didn't come that far, but we have scripts to make the image writeable | 13:56 |
| zbenjamin | but if we want on device debugging i guess we need that | 13:56 |
| zbenjamin | ok seems zoltan is not here right now | 13:57 |
| tedg | We should probably break the requirements down a bit, as I think there's a case where someone would be happy to install a dev version of a package, but wouldn't want to make their device writable. | 13:57 |
| zbenjamin | tedg: well as long as you don't want to debug, you don't need gdbserver | 13:58 |
| zbenjamin | my idea was to sneek the gdbserver command in , in cases where someone really hits the debug button | 13:58 |
| * tedg has a hard time imagining software with bugs, as he's never written any, but has heard about this from other people | 13:59 | |
| xnox | tedg++ | 13:59 |
| tedg | The trick there is going to be confinement, you really want to run the app confined to test it. | 13:59 |
| zbenjamin | never written bugs or never written software? ;) ;) | 13:59 |
| tedg | But I'm guess gdb isn't confinement happy. | 13:59 |
| zbenjamin | tedg: ok requirements would be a) start the app from cli, b) stop the app from cli , c) watch the apps state for running | 14:00 |
| pitti | jamespage: do you know some web UI to browse files from swift? (I tried ftp-cloud, but it seems to be ridiculously slow and doesn't want to authenticate) | 14:01 |
| zbenjamin | tedg: for debugging we need: a) the qml debugger switch to the command for debugging qml, b) somehow get gdbserver into the game | 14:01 |
| jamespage | pitti, erm | 14:01 |
| tedg | zbenjamin, So "upstart-app-launch" does that, you can take apart the executable to get more info at the various phases. | 14:01 |
| tedg | zbenjamin, It registers for the callbacks, etc. | 14:01 |
| zbenjamin | tedg: ok | 14:02 |
| pitti | jamespage: I mean, I know how to do it with curl, passing around the auth headers; if that's what it takes for debugging, I use it; but something clickable in the web browser would be nice | 14:03 |
| jamespage | pitti, if you set appropriate acl's on the container | 14:03 |
| jamespage | you should just be able to browse it | 14:03 |
| pitti | jamespage: you mean it has builtin http simple auth? | 14:04 |
| jamespage | pitti, http://docs.openstack.org/grizzly/openstack-object-storage/admin/content/swift-acls.html | 14:04 |
| jamespage | one second | 14:04 |
| * jamespage reads again | 14:04 | |
| pitti | jamespage: ah, thanks; reading that | 14:04 |
| zbenjamin | xnox: also for the taking long part, its not only the installing but also the click package creation and validation vs upload a directory ;) | 14:04 |
| pitti | jamespage: yes, I totally don't care about security; this is just a swift running in a local container for testing | 14:05 |
| cjwatson | creating a click package isn't much more than tar under the hood | 14:06 |
| pitti | jamespage: if I e. g. go to http://10.0.3.134:8080/v1/AUTH_testproj it just greets me with "Unauthorized" | 14:06 |
| jamespage | pitti, ".r:*,.rlistings" read acl makes it browseable | 14:06 |
| jamespage | you'll need to access at the container level | 14:06 |
| pitti | and doesn't ask me for my super-secret testuser/testpwd creds :) | 14:06 |
| jamespage | http://10.0.3.134:8080/v1/AUTH_testproj/<container> | 14:06 |
| xnox | zbenjamin: click build + install is near instant... | 14:08 |
| jamespage | pitti, this is relevant as well - http://docs.openstack.org/api/openstack-object-storage/1.0/content/Examples_for_static_web-dle4025.html | 14:08 |
| xnox | zbenjamin: and due to compression, you'd win time since one would be pushing less bytes over adb. | 14:08 |
| zbenjamin | xnox: i'll test it :) | 14:08 |
| cjwatson | the main slow bit of click install will be the python interpreter starting on the phone, I suppose; that costs a bit over half a second | 14:09 |
| === MacSlow|lunch is now known as MacSlow | ||
| pitti | jamespage: many thanks | 14:13 |
| pitti | jamespage: I get a somewhat ugly XML page now, but I can specify file URLs and download them, and at least see the listing | 14:14 |
| jamespage | pitti, the web-listings thing might be neater | 14:14 |
| === pete-woods1 is now known as pete-woods | ||
| arges_ | smb: hey do you need help with bug 1248025 | 14:19 |
| ubottu | bug 1248025 in libvirt (Ubuntu) "libvirt-bin fails to start inside Xen" [Undecided,In progress] https://launchpad.net/bugs/1248025 | 14:19 |
| smb | arges_, I am just bugging hallyn / jamespage on the server channel :) | 14:19 |
| arges_ | smb: oh ok. just checking out the queue and saw it. I'll leave it alone then | 14:20 |
| smb | arges_, ok, yeah. there seems to be some autotest problem, too anyway | 14:20 |
| psusi | say... how is the ppc arch not dead? wasn't apple the only one using it and they stopped like 10 years ago? | 14:28 |
| infinity | psusi: Turns out that not everything in the world is a desktop computer. | 14:28 |
| psusi | someone is making ppc servers? | 14:29 |
| infinity | psusi: Many someones have been doing so for a very long time. | 14:29 |
| psusi | weird | 14:29 |
| Pici | AIX runs on PPC | 14:29 |
| infinity | psusi: Guessing you've never heard of International Business Machines? :P | 14:30 |
| psusi | so given that apple dropped it a long time ago... does it still make sense for us to use the apparently long unmaintained and rotten mac-fdisk over util-linux's fdisk on ppc? | 14:30 |
| infinity | psusi: Maybe. It still supports things that fdisk doesn't. | 14:30 |
| psusi | well it apparently doesn't support disks > 500gb ;) | 14:30 |
| infinity | psusi: Though, arguably, that support should be rolled into fdisk. Or people should use parted. | 14:31 |
| infinity | psusi: And, frankly, "people should use parted" is an aswer for other reasons, like fdisk not groking GPT. | 14:31 |
| psusi | yea.. I think they added support for mac partition tables to util-linux upstream recently | 14:31 |
| psusi | fdisk now understands gpt upstream too ;) | 14:31 |
| infinity | psusi: Anyhow, it's on my list of things I want to try to sort out. | 14:31 |
| infinity | It may well be that the divergence there has outlived its usefulness. | 14:32 |
| infinity | Finally. | 14:32 |
| psusi | aye | 14:32 |
| infinity | YokoZar: That conflict might work by accident, but still probably doesn't mean what you wanted it to mean. | 14:32 |
| infinity | YokoZar: Your "replaces" without a "conflict" still means "please overwrite files from the other package and take ownership of them", but the conflict might force a premature removal that prevents that. Maybe. :P | 14:33 |
| psusi | infinity: but replaces does force the other package to be removed right? unlike dpkg-divert? | 14:34 |
| psusi | I thought the difference was that conflict means it won't be installed instead of the other package during an upgrade, but with replaces it will | 14:35 |
| infinity | psusi: Erm, what? | 14:36 |
| infinity | psusi: Replaces overwrites files. It does not force package removal. | 14:36 |
| infinity | psusi: Conflicts/Replaces forces a package removal. | 14:36 |
| psusi | you just contradicted yourself... | 14:36 |
| infinity | psusi: This is exactly the bug YokoZar is dealing with, he had a replaces without a conflict, and then when he'd install B after A and remove A, he'd have no files left (completely expected). | 14:36 |
| infinity | psusi: I didn't contradict myself if you check context. He was asking if it would work if the conflict was in another package, instead of having the C/R pair in the same package. | 14:37 |
| infinity | (The answer is "maybe, but not by design") | 14:38 |
| psusi | why would you ever want to just overwrite the files of another package? that seems broken | 14:38 |
| infinity | psusi: You do it all the time, when files move. | 14:38 |
| infinity | psusi: Say, for instance, a file were to move back and forth between procps and util-linux. :P | 14:38 |
| psusi | yea.. and you removee or upgrade the old package | 14:38 |
| infinity | No, you overwrite the file in the old package. | 14:39 |
| infinity | That's what Replaces means. | 14:39 |
| infinity | You take ownership, so it's now in your file list, and not the other. | 14:39 |
| psusi | that doesn't make sense by itself... if the file moved then you need to upgrade the other package to the new version that does not also contain the file | 14:39 |
| dakira | exit | 14:39 |
| dakira | exit | 14:39 |
| dakira | exit | 14:39 |
| psusi | and if you take ownership, then removing the old package shouldn't remove your files | 14:40 |
| infinity | psusi: No, removing the NEW package leaves the old one without files, which is unexpected if that's not what you wanted. | 14:40 |
| psusi | ohh | 14:40 |
| psusi | but why would you ever want to replace files of another package, and keep both installed? and why wouldn't you use dpkg-divert for that? | 14:41 |
| infinity | psusi: You want to do that all the time. Like I said, when files move between packages. | 14:41 |
| infinity | In YokoZar's case, it's expressly what he *didn't* want. He wanted to force the old package off the system. But you need C/R for that, and he only had R. | 14:42 |
| psusi | when files move between packages though, the old package removes the file in its new version, so you want to upgrade, not keep the old, conflicting version | 14:43 |
| psusi | why isn't a conflicts by itself enough to force the old package off the system? | 14:44 |
| infinity | psusi: Yes, you want to install a new version of the package, but you still need the overwrite, unless you want to force the unpack/install order. | 14:44 |
| psusi | so by using both, you can install the new new package first, *then* upgrade the old one? rather than uninstalling the old one, then installing the new one? | 14:45 |
| infinity | psusi: Here. Let's look at a real life example where it would obviously be broken to require removal before install. If we broke out libnss-files.deb from libc6.deb and wanted to install that on upgrade. | 14:45 |
| psusi | right, so if there are depends, then you *can't* uninstall the old package first... so you have to be able to replace it, then upgrade it? | 14:46 |
| infinity | With a hard versioned conflict, I'd have to remove libc6 before installing libnss-files.deb (obviously bad, cause I'd no longer have a libc), or I'd have to install the new libc6 first, which would no longer have libnss-files (wich could break my shell). | 14:46 |
| psusi | right... got ya | 14:47 |
| infinity | But if I install libnss-files first, and it Replaces libc6 (<< first-version-wihout-libnss-files), then it overwrites, I have my bits, and I keep upgrading. | 14:47 |
| infinity | As for why Conflict isn't enough to foce things off a system, it is, but it isn't. | 14:47 |
| infinity | If you manually ask for "please install foo, which conflicts with bar, which is installed", you'll get what you asked for. | 14:47 |
| psusi | aha! I see now | 14:48 |
| infinity | But upgrade managers like apt, update-manager, etc, won't let you do that because, well, it's far too easy to shoot yourself in the foot. | 14:48 |
| psusi | the conflicts by itself would cause the upgrade path to refuse to remove the existing package... but with c+r, the upgrader sees that when it upgrades the old package, it will no longer conflict, so proceeds | 14:48 |
| infinity | Conflict/Replace together is a hint that foo is *meant* to replace bar, rather than them just being conflicting implementations (like MTAs... If every time something listed "exim" as its preferred MTA, it tore out your "sendmail" or "postfix", you'd be pretty angry) | 14:48 |
| cjwatson | also note the stuff in policy about when you should prefer to use Breaks instead | 14:48 |
| cjwatson | that's the result of quite a bit of very pedantic discussion and it's nice to make use of it rather than have to rethink it all from first principles | 14:49 |
| infinity | I like the general rule that "if it's a versioned conflict, you probably meant Breaks". | 14:49 |
| cjwatson | yep | 14:50 |
| sergiusens | xnox, your gallery question is sort of answered now | 14:50 |
| psusi | so... replaces+breaks would be the right way to move a file between packages? | 14:50 |
| xnox | sergiusens: well, sort off. the full log does not use "phablet-test-run" thus it's really hard to reproduce. | 14:51 |
| === vibhav is now known as Guest47064 | ||
| psusi | I would think that moving a file you would need a versioned conflicts, otherwise even the updated old package wouldn't be coinstallable | 14:51 |
| xnox | sergiusens: or is there a new reply i didn't notice somewhere? | 14:51 |
| cjwatson | psusi: in general you should use Breaks+Replaces for that, yes, if the old package survives just with fewer files | 14:51 |
| psusi | ahh... why? ;) | 14:51 |
| cjwatson | versioned conflicts> see "nice not to have to rethink it all from first principles". | 14:52 |
| cjwatson | go read the footnote in policy :) | 14:52 |
| sergiusens | xnox, like 2 minutes ago; I triggered the rebuild before going to be last night as the error seemed weird | 14:52 |
| xnox | sergiusens: ok, i'll try to do the deb thing. | 14:53 |
| sergiusens | xnox, in the jenkins build there's a 'deb' key with a link to all thedebs it builds for testing | 14:53 |
| infinity | psusi: Well, a versioned conclict, historically, was use with a versioned replace. | 14:53 |
| sergiusens | xnox, http://jenkins.qa.ubuntu.com/job/generic-mediumtests-builder-trusty-armhf/3452/artifact/work/output/*zip*/output.zip | 14:53 |
| infinity | psusi: But that causes awful messes for resolvers. | 14:53 |
| cjwatson | the short answer is that Conflicts imposes too strong a constraint and often requires apt to entirely remove the old package temporarily rather than being able to do something more graceful | 14:53 |
| cjwatson | Breaks is to Conflicts as Depends is to Pre-Depends, roughly | 14:53 |
| infinity | psusi: Basically, a break/replace combo lets you upgrade in any order, but still requires you to upgrade both packages. | 14:53 |
| psusi | wait... if you use breaks, then the old package has to be deconfigured first, which you can't do if other packages depend on it | 14:54 |
| cjwatson | that makes no sense; conflicts is *stronger* than breaks | 14:54 |
| cjwatson | if you think breaks is too strong then logically you must also object to conflicts | 14:54 |
| psusi | I though the point was to use both conflicts, and replaces, to allow the new package to be installed *without* first removing the old one? | 14:55 |
| cjwatson | anyway, yes you can deconfigure, it just requires deconfiguring the tree above it | 14:55 |
| cjwatson | no, use breaks+replaces. | 14:55 |
| cjwatson | we have gone over this ad nauseam in -policy and it's the right answer | 14:55 |
| cjwatson | policy exists so that we don't have to keep revisiting this stuff :) | 14:55 |
| === cmagina is now known as cmagina-away | ||
| cjwatson | conflicts+replaces *forces* the old one to be removed or upgraded before unpacking the new one | 14:57 |
| cjwatson | in cases where the new one also depends on the old one (commonplace in cooperating groups of packages), this can get pretty exciting for the resolver! | 14:58 |
| psusi | I thought infinity was just explaining to me that the replaces allows the new one to be installed, and take over the file, before removing or upgrading the old one | 14:58 |
| infinity | psusi: It does. | 14:58 |
| cjwatson | replaces does; but the conflicts says that both packages cannot exist in >=unpacked state on the system at the same time | 14:58 |
| cjwatson | whereas breaks says that both packages cannot exist in configured state on the system at the same time | 14:58 |
| psusi | ohh | 14:58 |
| cjwatson | the latter turns out to work much better for moving files between packages | 14:59 |
| infinity | psusi: But without the breaks (or, in the past, conflicts), you have no hint that the other package should be upgraded. Which leads to the "when I remove the new one, the old one is missing files" issue. | 14:59 |
| psusi | then replaces doesn't really let one package take over a file from another since it forces the other package to be removed first | 14:59 |
| cjwatson | no, replaces doesn't force the other package to be removed first | 14:59 |
| infinity | Replaces only overwrites files. | 15:00 |
| psusi | you just said it prevents both from being >= unpackacked | 15:00 |
| cjwatson | no I didn't | 15:00 |
| cjwatson | please read again | 15:00 |
| cjwatson | 14:58 <cjwatson> whereas breaks says that both packages cannot exist in configured state on the system at the same time | 15:00 |
| infinity | (Except when used with conflict, but that's a special and weird case) | 15:00 |
| cjwatson | and | 15:00 |
| psusi | ohh, right... *conflicts* | 15:00 |
| cjwatson | <cjwatson> ... but the conflicts says that both packages cannot exist in >=unpacked state on the system at the same time | 15:00 |
| psusi | ok, so you do want replace, just use breaks instead of conflicts since conflicts forces removal of the old package first, which might break things | 15:01 |
| cjwatson | exactly | 15:01 |
| cjwatson | conflicts+replaces is the hack we used before breaks existed | 15:01 |
| psusi | ok... I swear infinity was saying that c+r allowed the smooth replacement without first removing the old one ;) | 15:01 |
| cjwatson | it was suboptimal but there wasn't really anything better; so it's still embedded in various packages | 15:01 |
| cjwatson | and occasionally people clone-and-hack it | 15:02 |
| cjwatson | but breaks+replaces is the new hotness (where new = about 6 years old) | 15:02 |
| cjwatson | and actually does what we wanted all along | 15:02 |
| cjwatson | c+r allows a replacement that doesn't allow files to magically reappear, but it's an excessively large hammer | 15:02 |
| cjwatson | it's still appropriate in cases where the old package name is going away permanently | 15:03 |
| cjwatson | https://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts has a set of rules of thumb for when to use one or the other | 15:03 |
| psusi | unless temporarily removing the file could break the system | 15:03 |
| psusi | like if you were moving /bin/sh | 15:04 |
| cjwatson | right, essential packages must be much more careful | 15:04 |
| cjwatson | there's a whole set of mostly unwritten lore for dealing with those, since there are very few of them and their maintainers are mostly experts already :) | 15:04 |
| cjwatson | plus the essential set is *mostly* fairly stable | 15:04 |
| cjwatson | some of the rules are written down, like essential packages normally need to use Pre-Depends to ensure that dependencies of the essential facilities they provide are always met even while unconfigured | 15:05 |
| cjwatson | but policy leaves you to derive some of the rest from first principles of the state machine it describes | 15:06 |
| cjwatson | largely when this comes up it's something that's worth thinking through from scratch anyway | 15:06 |
| psusi | aye | 15:06 |
| cjwatson | Santiago and I have a low-level running disagreement about exactly how base-passwd should be behaving here :) | 15:07 |
| psusi | damnit... so... I've reworked my patches to partman-basicfilesystems like you asked, and trying to test it now... but I can't build d-i.. it looks like it is still looking for the previous kernel and acpi-modules versions, which are in testing, but have been removed from unstable | 15:07 |
| psusi | any hints there? | 15:07 |
| cjwatson | might be worth checking whether build/sources.list.udeb is exactly correct - if it isn't, copy to build/sources.list.udeb.local and adjust | 15:08 |
| psusi | looks fine to me: deb http://ftp.us.debian.org/debian unstable main/debian-installer | 15:09 |
| cjwatson | you might need to locally bump the kernel version in the appropriate config file under build/config/ | 15:10 |
| cjwatson | it's not always perfectly up to date | 15:10 |
| psusi | hrm.. build/pkg-lists/kernel says to get kernel-image-${kernel:Version}... where's it get that version from? | 15:10 |
| cjwatson | build/config/amd64.cfg:5:KERNELVERSION = 3.12-1-amd64 | 15:10 |
| cjwatson | for instance | 15:10 |
| zbenjamin | tedg: i was just checking how android handled the debugging. Looking at the android creator plugin it seems the "am" tool has support for running a app in a debug mode, any chance we could do something similar? | 15:10 |
| psusi | ahh, right | 15:10 |
| tedg | zbenjamin, We have an API in libual that runs an app in test mode. Mostly for thomi, if he's happy with adding things there, I'm happy to as well. | 15:12 |
| tedg | zbenjamin, Today it just sets the testability flag. | 15:12 |
| * psusi wishes that all of the partman modules were in one repo | 15:14 | |
| cjwatson | yeah, it's not ideal | 15:14 |
| cjwatson | mr can help | 15:14 |
| cjwatson | https://wiki.debian.org/DebianInstaller/CheckOut | 15:15 |
| psusi | it feels very goofy to have to do a svn checkout and then use this mr tool to checkout all of the sub git modules | 15:15 |
| psusi | ohh that was for d-i though | 15:15 |
| cjwatson | partly this is 'cos translators wanted to stick with svn iirc | 15:15 |
| cjwatson | yeah, but that gets you partman-* | 15:15 |
| psusi | ohh.. I just did a git clone once I realized they were maintained in git... that first round of patches I just downloaded the source package and made a debdiff | 15:16 |
| cjwatson | definitely much less work to do it in git | 15:16 |
| shadeslayer | ev: can Kubuntu drop gdb in favor of gdb-minimal? Will everything work fine from the daisy POV? | 15:17 |
| === cmagina-away is now known as cmagina | ||
| pitti | shadeslayer: should be fine, yes; it doesn't need the extra pretty-printers and other bells and whistles | 15:24 |
| ev | shadeslayer: I honestly have no idea and I'm in full on firefight mode at the moment, sorry | 15:24 |
| ev | ah thanks pitti | 15:24 |
| pitti | Recommends: update-notifier, gdb | gdb-minimal | 15:24 |
| xnox | sergiusens: elopio: barry: i've now emails ubuntu-devel & ubuntu-phone about this gallery-app merge proposal. I've pulled the debs generated in the merge comment, and they fully pass their test-suite when i execute them on my mako. | 15:24 |
| pitti | shadeslayer: ^ that's what apport-gtk has | 15:24 |
| shadeslayer | aha | 15:24 |
| pitti | shadeslayer: (and -kde) | 15:24 |
| shadeslayer | so apport will work fine as well | 15:24 |
| pitti | shadeslayer: yes | 15:24 |
| shadeslayer | now all that's left is Dr Konqi | 15:24 |
| shadeslayer | pitti: so, the only difference is "Recommends: libc-dbg, python3" right? | 15:25 |
| pitti | shadeslayer: sorry, which difference? | 15:25 |
| shadeslayer | gdb vs gdb-minimal | 15:25 |
| barry | xnox: so, it passes as a .deb but fails as a .click? | 15:27 |
| xnox | barry: it passes whichever way around, always, locally. | 15:28 |
| sergiusens | xnox, then fginther should be able to figure it out | 15:28 |
| xnox | barry: i'm really struggling to fail it locally at all, or in anyway similar to what ps-jenkins is telling me. | 15:28 |
| xnox | sergiusens: just fginther ? =( | 15:30 |
| barry | xnox: yay | 15:30 |
| xnox | fginther: hopefully you can help shed some light as to why https://code.launchpad.net/~xnox/gallery-app/fix-sample-dir/+merge/210517 is failing by ps-jenkins on mako, yet passes locally against mako. | 15:31 |
| dobey | cjwatson: ping | 15:32 |
| dobey | cjwatson: you're not making the vala click scope code use libclick, are you? | 15:32 |
| fginther | xnox, what image are you using? | 15:32 |
| fginther | xnox, the tests use trusty-proposed | 15:32 |
| xnox | fginther: i'm testing against trusty-proposed on my local mako... | 15:33 |
| fginther | xnox, ok | 15:33 |
| xnox | fginther: are there steps that I can do locally, to match what ps-jenkins is doing? cause it's using .deb instead of .clicks. | 15:33 |
| xnox | fginther: and phablet-test-run passes here =( | 15:34 |
| dobey | cjwatson: if so, please stop wasting your time (the vala code is going away as soon as new scopes lands in the image) :) | 15:34 |
| cjwatson | dobey: see my conversation with alecu on #ubuntu-phone earlier | 15:34 |
| cjwatson | dobey: I hadn't started on the vala bits yet, as it happens | 15:34 |
| sergiusens | xnox, no, not just him; cihelp on that other channel for ci works | 15:34 |
| dobey | cjwatson: on irc? i'm not on that channel. is it logged? | 15:35 |
| cjwatson | dobey: sorry, I mean #ubuntu-touch | 15:35 |
| dobey | ah ok | 15:35 |
| cjwatson | dobey: anyway, I'm basically scattergunning my efforts across anything I can find that forks /usr/bin/click, but thank you for decrementing my list :) | 15:36 |
| fginther | xnox, yes. the test runner is all in lp:~canonical-ci-engineering/jenkins-launchpad-plugin/autopilot-testrunner-touch-saucy | 15:36 |
| cjwatson | dobey: I'll probably just defer submitting anything from the scope until there's something new-scopish I can test conveniently | 15:36 |
| dobey | cjwatson: i just now saw your e-mail about it on the list. didn't see the backlog in irc though. :) | 15:36 |
| cjwatson | *to the scope | 15:36 |
| fginther | xnox, it's a bit of a patch work, some parameters are env vars, some are passed as arguments. But you should be able to reproduce things by just walking through mediumtests-runner-touch.sh | 15:36 |
| dobey | cjwatson: yeah, i was going to file a bug about using libclick anyway, and see if it can be done reasonably trivially | 15:37 |
| dobey | cjwatson: just don't want you to waste time on code we're going to throw away in a few days | 15:37 |
| fginther | xnox, basically do some setup of the phone, install all of the test packages from the build, unlock the screen, then run the tests with ptr. | 15:37 |
| cjwatson | dobey: sure; it looks something like http://paste.ubuntu.com/7085258/ but I haven't polished that yet | 15:38 |
| xnox | fginther: in the full console log I do not see ptr executed at all =/ | 15:41 |
| fginther | xnox, ack, the script isn't being echoed, which I admit makes this annoying | 15:45 |
| shadeslayer | pitti: poke poke <shadeslayer> gdb vs gdb-minimal | 15:46 |
| doanac` | ptr starts in the log around: INFO:unity8.process_helpers:Greeter unlocked, continuing | 15:46 |
| pitti | shadeslayer: ah, that | 15:46 |
| shadeslayer | that's what I can see atleast : Recommends: libc-dbg, python3 | 15:46 |
| pitti | shadeslayer: yes, you don't need those for whoopsie or apport | 15:46 |
| shadeslayer | cool, thx pitti | 15:46 |
| doanac` | xnox: i'm terrible with autopilot log parsing, but this doesn't seem good: | 15:48 |
| doanac` | Could not determine application identifier. HUD will not work properly. | 15:48 |
| doanac` | Provide your application identifier in $APP_ID environment variable | 15:48 |
| barry | doanac`, xnox i've seen that before | 15:48 |
| barry | no idea what it means, but it went away when i fixed the bug | 15:49 |
| xnox | doanac`: my analysis so far is that gallery-app has been converted to click on the image, yet ps-jenkins is building/installing/testing it as a .deb. That can't be right, as we are doing wrong/unconfined testing. | 15:49 |
| barry | http://bazaar.launchpad.net/~barry/address-book-app/py3autopilot/revision/149 | 15:49 |
| fginther | xnox, it's actually a click in the image now? | 15:50 |
| xnox | doanac`: if the app / autopilot driver crashes, it would results in HUD garbage. | 15:50 |
| jibel | doanac`, I think it means the app is not launched by upstart-app-launch | 15:50 |
| fginther | xnox, in that case, I think the jenkins testing is unpredictable | 15:50 |
| xnox | fginther: as per http://people.canonical.com/~ubuntu-archive/click_packages/click_list gallery is a click app on the images. | 15:50 |
| xnox | fginther: and that link is the canonical list of preinstalled clicks used during image construction. | 15:51 |
| fginther | xnox, thanks | 15:51 |
| === awe__ is now known as awe | ||
| === Sweetsha1k is now known as Sweetshark | ||
| fginther | xnox, I think your right then, this is incompatible until we can get these converted to pure click testing. I can't do that today, so I recommend dropping the automated touch tests from these click packages for now. | 15:53 |
| xnox | fginther: but e.g. it should still work, let me try flashing a fresh image, uninstalling gallery-app click, install debs, try testing them. | 15:55 |
| xnox | fginther: maybe e.g. the .deb creation got broken since conversion to click. | 15:55 |
| fginther | xnox, indeed. I would expect the deb to rot now | 15:56 |
| infinity | bdmurray: *poke* | 16:30 |
| infinity | bdmurray: What's the point in ubuntu-release-upgrader failing gracefully if apport isn't installed if you explicitly depend on it? | 16:31 |
| infinity | bdmurray: (And do we really want to explicitly depend on apport and pull it into the standard set?) | 16:31 |
| bdmurray | infinity: apport and python3-apport are already on most installs? | 16:43 |
| infinity | bdmurray: Desktop installs, they weren't in standard until you made that change. | 16:43 |
| infinity | bdmurray: And they were recommends of most desktops until you made it a hard dep of... Everything. | 16:44 |
| bdmurray | infinity: right, I got that. the release-upgrader uses python3-apport to do its own crash handling. so we won't get crash reports on upgrades of things other than most desktops | 16:46 |
| bdmurray | There won't be a .crash file generated at all. | 16:46 |
| infinity | bdmurray: Well, I'd say it's by design for us to not get crash reports from people who don't want to send them, or people who don't want apport installed... | 16:48 |
| infinity | bdmurray: Just seems weird to put effort into making it gracefully work without apport installed and then require apport. | 16:48 |
| bdmurray | infinity: I missed that python3-apport recommends apport. The creation of the .crash file is different than the send of it. | 16:50 |
| infinity | bdmurray: As you note, apport will be installed on most desktops anyway, so that bit should Just Work. I'd argue that the graceful business should allow for py3-apport not being there too, no? | 16:51 |
| infinity | So, user has apport, stuff works, user doesn't have apport, no .crash. | 16:51 |
| bdmurray | infinity: okay | 16:52 |
| infinity | bdmurray: It just pulls a lot of stuff in, hence my complaint. So, yeah, if we can fix, that would be lovely. | 16:53 |
| bdmurray | infinity: right, I'll take care of it | 16:54 |
| infinity | Ta. | 16:54 |
| jtaylor | hm is the diamond like pattern in the trusty desktop background a graphical glitch or intentional? | 17:21 |
| ogra_ | intentional | 17:22 |
| jtaylor | k | 17:22 |
| jtaylor | maybe not the best choice if the first though you get from seeing it is that somethings wrong :/ | 17:23 |
| infinity | Would have made more sense for quantal. :P | 17:23 |
| infinity | But it's grown on me. | 17:23 |
| * ogra_ finds it slightly painful that the cross point isnt actually centered | 17:24 | |
| infinity | ogra_: Thanks. Now I can't unsee that. | 17:25 |
| cjwatson | It's like the software centre icon | 17:25 |
| ogra_ | lol | 17:25 |
| jtaylor | ^^ | 17:25 |
| cjwatson | I thought the crossbar on it was a graphical glitch for the longest time | 17:25 |
| mdeslaur | hehe | 17:25 |
| infinity | cjwatson: I thought it was a masonic symbol. | 17:26 |
| mdeslaur | lol | 17:26 |
| cjwatson | Particularly since not long before it was introduced I actually did have an occasional graphical glitch on my system that looked a bit like that | 17:26 |
| dobey | cjwatson: the progress bar? | 17:26 |
| cjwatson | I expect that is what it's supposed to be, yes | 17:27 |
| cjwatson | To my hindbrain it's forever an X glitch | 17:27 |
| ogra_ | it is mpt's expression of anarchy | 17:27 |
| dobey | heh | 17:28 |
| cjwatson | I also have no idea why it looks like an A | 17:28 |
| ogra_ | (in a shopping bag) | 17:28 |
| infinity | cjwatson: I assume A is for "Appz lolz". | 17:28 |
| dobey | cjwatson: because applications don't start with an s | 17:28 |
| infinity | Because you if you don't have "apps", you're not hip and cool. | 17:28 |
| infinity | Thanks, Apple. | 17:28 |
| ogra_ | cjwatson, because it brings you "Apps" | 17:28 |
| cjwatson | I assumed it was the Amazon icon for ages before I actually checked | 17:28 |
| cjwatson | Icon designers and I don't normally get on well. :-) | 17:29 |
| dobey | ogra_: you're mistaken. all i've gotten is suffering ;) | 17:29 |
| mdeslaur | so it's _not_ an Abercrombie bag? | 17:29 |
| ogra_ | thats not my fault ! | 17:29 |
| infinity | mdeslaur: No, even fat kids can use software-centre. | 17:29 |
| dobey | mdeslaur: no, it's too thick for that | 17:29 |
| mdeslaur | hehe | 17:29 |
| dobey | also, it has a color other than grey | 17:30 |
| * cjwatson wonders if we localise that icon | 17:30 | |
| dobey | localize? icons? LOL! | 17:30 |
| cjwatson | Or if we just assumed everyone speaks a language where applications starts with A | 17:30 |
| cjwatson | Because cultural imperialism lol | 17:30 |
| infinity | cjwatson: It's not "applications", it's "apps", and "apps" is probably a universal borrowed word by now. | 17:31 |
| infinity | (Again, thanks Apple... *grumble*) | 17:31 |
| cjwatson | I was pleased to find last night that the only star map application (:-P) I could find for Ubuntu Phone had an Irish title | 17:32 |
| cjwatson | Less pleased to find as a result that the "Recent apps" thing isn't Unicode-safe | 17:32 |
| rbasak | This conversation reminds me of save icons not being floppy disks | 17:32 |
| * cjwatson checks the century | 17:32 | |
| rbasak | And everyone getting confused | 17:32 |
| xnox | jtaylor: infinity cjwatson: the bit that annoys me is that the origami center fold is not _actually_ in the center of the image, see screenshot on bug #1291735 | 17:32 |
| ubottu | bug 1291735 in ubuntu-wallpapers (Ubuntu) "Default 14.04 wallpaper does not align well with greeter grid" [High,Confirmed] https://launchpad.net/bugs/1291735 | 17:32 |
| infinity | rbasak: Floppy for life. | 17:32 |
| rbasak | "Daddy, what is that thing in the photo that looks like a save icon?" | 17:33 |
| infinity | rbasak: I just like that, way back when, the icon *did* change from a black 8"/5.25" floppy to a colorful 3.5" floppy. And then we just stopped updating. | 17:33 |
| infinity | I assume that, by now, it should be a picture of someone flinging bits over the intertubes at a remote server. | 17:33 |
| infinity | But that's hard to represent. | 17:34 |
| dobey | infinity: gnome is updated :) | 17:34 |
| infinity | dobey: What does GNOME use now? I haven't looked. | 17:34 |
| * infinity looks. | 17:34 | |
| dobey | infinity: it's a hard drive with an arrow | 17:34 |
| infinity | Oh, right. It's been that for a while. | 17:34 |
| infinity | Silly GNOME. I want my floppy. | 17:34 |
| rbasak | Yeah that's what I'm referring to. Users used to know what floppy disks look like. Users have never known what hard drives look like. | 17:34 |
| dobey | software-center icon is actually a shoe bag: http://www.gettyicons.com/free-icons/174/the-city/png/256/nike_256.png | 17:34 |
| infinity | rbasak: The problem is that there's nothing that users know on sight that also represents "saving stuff" and can fit in a tiny icon. | 17:35 |
| * psusi wrote the floppy disk driver for ReactOS... most shitty hardware you can imagine | 17:35 | |
| rbasak | infinity: indeed. And arguably the whole load/save paradigm for documents is a broken one anyway. | 17:35 |
| ogra_ | reactos is bound to a certain HW ? | 17:35 |
| dobey | rbasak: yet web sites offering downloads of apps or whatever use a metaphorical hard disk and arrow as an icon for it :) | 17:35 |
| psusi | ogra_: no, I was refering to floppy disks | 17:36 |
| infinity | rbasak: With enough space, an IKEA-style pictogram of a man crying because his essay is lost, and a crossed-out circle around it would totally work. :P | 17:36 |
| ogra_ | ah | 17:36 |
| ogra_ | yeah | 17:36 |
| rbasak | :) | 17:36 |
| infinity | "Have you clicked the sadness-prevention button recently?" | 17:36 |
| dobey | infinity: users use google docs, which doesn't have save, anyway. :) | 17:37 |
| psusi | I was scratching my head for quite a while trying to figure out why I couldn't get it to even detect the type of drive... the specs say there is a command to do this... then I realized nobody botherd to fscking implement it, which is why every pc bios ever makes you tell it what type you have, if any.. and the OS just has to blindly accept that | 17:37 |
| infinity | dobey: Right, creating the file before editing (which is the gdocs paradigm) allows you to just autosave-on-edit and do away with the button. | 17:37 |
| infinity | dobey: Which is, arguably, what those poor kids losing essays and dissertations should be doing too. | 17:38 |
| dobey | or just get in the habit of pressing Ctrl+S after every Return | 17:38 |
| psusi | it was fun though, being able to redo the low level format and squeeze 1920 kb onto a 1440k floppy using mixed sector sizes ;) | 17:38 |
| cjwatson | Hah, the author of the star map application I mentioned even filed a bug about it. https://bugs.launchpad.net/unity8/+bug/1276005 | 17:42 |
| ubottu | Launchpad bug 1276005 in Unity 8 "Accented characters don't get rendered properly in Recent apps" [High,Triaged] | 17:42 |
| cjwatson | bregma: I don't suppose you'd be available in the core-1 session now? We could use some experience with hidpi | 18:02 |
| bregma | be right there | 18:03 |
| === TheDrums is now known as DalekSec | ||
| barry | xnox: https://code.launchpad.net/~barry/gallery-app/xnox-pkgresources/+merge/210877 | 18:31 |
| xnox | barry: if ps-jenkins will O.K. it i'd want to ship it asap =) | 18:34 |
| barry | xnox: i guess it would supersede your branch, since lp's mp is ignoring my suggestion. or just steal my branch and merge it into yours | 18:34 |
| xnox | barry: yeah target lp:gallery-app | 18:36 |
| xnox | barry: that's fine. | 18:36 |
| theqlabs | howdy, running ubuntu on beagle bone black: trying to understand the best way to develop a DMA kernel module that sends its buffer to a host PC over Ethernet (TCP socket, send() system call, etc?) | 18:37 |
| barry | xnox: sorry, i don't know whether your going to pull it into your existing mp or mine should supersede? | 18:38 |
| sarnold | theqlabs: you may have more success in #kernelnewbies on irc.oftc.net | 18:40 |
| xnox | barry: doesn't matter =) i'd rather not touch the proposal, and wait for ps-jenkins to test it and see what the results would be. | 18:41 |
| theqlabs | excellent, was looking for kernel room - thanks sarnold | 18:41 |
| barry | xnox: okay. i guess we'll just leave my mp as a separate proposal | 18:41 |
| barry | xnox: https://code.launchpad.net/~barry/gallery-app/xnox-pkgresources/+merge/210877/comments/497072 | 19:35 |
| ogra_ | xnox, FYI there is also python-apt on the touch images (along with python3-apt ... i just saw your gallery-app mail) | 19:40 |
| xnox | barry: *ship it* =) | 19:41 |
| xnox | ogra_: i know. i can't port anything else, until these 3 clicks land - music, calendar and now gallery app. | 19:44 |
| ogra_ | yeah, that might take a bit ... | 19:45 |
| ogra_ | given the Qt explosion that is just happening :) | 19:45 |
| bdmurray | pitti: the retracer logs contain information about what debug symbol packages are outdated. Could we use that to get updated versions? | 20:29 |
| jtaylor | nice the new readline is borked too | 21:19 |
| jtaylor | am I to dumb to find the FFe or was there none? | 21:20 |
| jtaylor | oh well at least theres a patch, lets try | 21:31 |
| jtaylor | hm how does one apply this type of patch: http://lists.gnu.org/archive/html/bug-readline/2014-03/msg00031.html | 21:35 |
| YokoZar | cjwatson: infinity: Thank you for the extended discussion. I think the only weirdish not-fully-defined behavior in apt is what happens when you Provide a package that is also a real package (the resolver gets a bit confused) | 21:38 |
| sarnold | jtaylor: patch should handle that, that's just an old-style diff or context diff.. | 21:39 |
| jtaylor | bug 1290287 | 21:41 |
| ubottu | bug 1290287 in readline6 (Ubuntu) "ipython crashed with SIGSEGV in _rl_dispatch_callback()" [High,Triaged] https://launchpad.net/bugs/1290287 | 21:41 |
| infinity | YokoZar: Providing a package that's a real package give equal weight for non-versioned dependency resolution if it's already installed, but favours the real one if not, or if a version comes into play. | 21:43 |
| infinity | jtaylor: Eww, wow, a non-unified diff? Ugly. | 21:44 |
| infinity | jtaylor: But yes, patch will read it fine. | 21:44 |
| achiang | does anyone have a pointer to wiki that explains the technical/support differences between a flavor and a remix? | 21:49 |
| achiang | flavor implies official support | 21:49 |
| infinity | achiang: No it doesn't. | 21:49 |
| achiang | but is there a type of derivative that is less official? | 21:49 |
| achiang | https://wiki.ubuntu.com/RecognizedFlavors | 21:50 |
| achiang | well, i guess not official support, but some support for the recognized flavors | 21:50 |
| achiang | but i'm looking for an explanation of other derivatives that aren't recognized flavors | 21:50 |
| infinity | achiang: Sure, archive support, because we run the archive. | 21:50 |
| YokoZar | We share one big archive | 21:50 |
| infinity | achiang: And security/sru support, when it overlaps with the set we care about. | 21:50 |
| infinity | YokoZar: So, a flavour is in-archive and also uses our CD infrastructure. | 21:51 |
| infinity | Err. | 21:51 |
| infinity | achiang: ^ | 21:51 |
| achiang | https://wiki.ubuntu.com/DerivativeTeam/Derivatives | 21:51 |
| YokoZar | So when derivatives are just packagesets from within the archive, they're implicitly supported. | 21:51 |
| infinity | achiang: A remix may or may not be in-archive, but the images aren't built on our infra. | 21:51 |
| infinity | achiang: And a derivative is out-of-archive. | 21:51 |
| achiang | infinity: ok, then to support community "thingies" of ubuntu touch, the proper term would be remix, i think? | 21:52 |
| achiang | infinity: where the thingies might have customized backgrounds, or new click packages, but otherwise share the same core of ubuntu | 21:53 |
| infinity | achiang: If you've stopped using PPAs, touch is a flavour. It's built from the Ubuntu archive, and uses Canonical infrastructure to build. | 21:53 |
| infinity | achiang: Oh, a community port or mangling of Touch would be a remix, generally, possibly a derivative. The line's fuzzy there. | 21:53 |
| achiang | infinity: the context for this line of questioning is about what do i write in documentation to describe these "thingies" that communities might make | 21:54 |
| achiang | infinity: see first paragraph here - http://people.canonical.com/~achiang/ubuntu_savvy/ | 21:54 |
| infinity | achiang: I think we might have official rules on what's allowed to call itself a "remix". But it's definitely not a flavour. | 21:54 |
| * infinity looks. | 21:55 | |
| achiang | infinity: i just want to be sure i'm using the term "remix" properly - so that i can ensure the docs everywhere use that term consistently | 21:55 |
| infinity | achiang: I feel like this used to be mentioned in the trademark policy or something, but can't find it. | 21:57 |
| === kyleN is now known as kyleN-afk | ||
| achiang | infinity: yeah. google fails me | 21:57 |
| infinity | And, in fact, it used to be. In an older version. | 21:58 |
| achiang | infinity: but based on your informal comments above, i think 'remix' is appropriate | 21:58 |
| infinity | achiang: See the stale copy on http://www.ubuntu.org.cn/trademark-policy | 21:58 |
| infinity | achiang: It has a whole section on remixes. | 21:58 |
| infinity | achiang: (Might be worth taking up with legal as to why that policy seems to have died entirely and made this even more confusing) | 21:59 |
| infinity | "A remix may not include software from any source other than the standard Ubuntu package archives, nor may it specify software sources / archives other than the standard Ubuntu package archives." | 21:59 |
| infinity | So, by that standard, a Touch port that pulls kernels/drivers from AOSP/CM wouldn't be a remix. | 22:00 |
| achiang | yeah | 22:00 |
| infinity | But a Touch rebuild that tweaks configs or swaps out packages, would be. | 22:00 |
| achiang | right - the sentence just prior seems to indicate what Savvy aims to do would produce mostly valid remixes | 22:00 |
| achiang | infinity: thanks for this pointer | 22:01 |
| infinity | achiang: Yeah, looks like savvy's goal is to produce remixes, pretty much to the letter of the law. | 22:01 |
| achiang | infinity: yep. the one sneaky corner case is if a remix pre-installs a click package that is not from archive | 22:02 |
| infinity | That would be a derivative, or would need Canonical approval. | 22:02 |
| achiang | infinity: but i have a feeling that said click package would not violate the spirit of what a remix is defined as | 22:02 |
| infinity | (Note the remix policy has^Whad a provision for blessed software sources) | 22:02 |
| TheMuso | @pilot in | 22:03 |
| === udevbot changed the topic of #ubuntu-devel to: Trusty Beta 1 released! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: TheMuso | ||
| infinity | achiang: Definitely worth taking up internally to revive the remix policy and dust it off and, indeed, start vetting pre-approved click packages that don't violate remixification. | 22:03 |
| achiang | i mean, including that click package shouldn't change the spirit of whether your build output would deviate enough from Touch to be considered a !remix | 22:03 |
| achiang | infinity: good advice. thanks | 22:03 |
| infinity | achiang: Depends on the package. Think, for instance, what happens to Android when you install that Facebook takeover thingee that pretty much turns your phone into a Facebook phone. | 22:04 |
| infinity | achiang: We'd want some control over brand purity there, hence needing to review the clicks we'd approve people use and still call the product Ubuntu. | 22:04 |
| achiang | infinity: true, but a click package can't do that in Ubuntu due to confinement, etc. | 22:04 |
| achiang | infinity: and they wouldn't be able to produce that output with Savvy | 22:04 |
| achiang | infinity: so at that point, the other trademark/derivative naming rules would kick in | 22:05 |
| === iulian is now known as Guest53422 | ||
| bdmurray | happyaron: is there a bug that fcitx in the saucy proposed queue fixes? | 22:05 |
| achiang | infinity: thanks again | 22:07 |
| infinity | achiang: True that a click is probably less scary since we don't allow replacing core functionality like Android does. | 22:07 |
| infinity | achiang: But I'm sure someone will come up with creative ways to make a package that we don't really want our name attached to. ;) | 22:07 |
| achiang | true | 22:07 |
| achiang | Ubuntu Touch...ing You | 22:08 |
| infinity | Ubuntu Bouncing Boobies Remix, etc. | 22:08 |
| TheMuso | marcoceppi: Can https://bugs.launchpad.net/ubuntu/+bug/1292230 be considered the FFE for the package in question? If so, I don't see ubuntu-release as being subscribed... | 22:13 |
| ubottu | Launchpad bug 1292230 in Ubuntu "Needs packaging: charmworldlib" [Undecided,In progress] | 22:13 |
| infinity | achiang: I assume the intent here is for things like an "Ubuntu Touch T-Mobile Remix" that is basically Touch, but slightly more pink, and includes their VoIP app, that sort of thing? | 22:13 |
| infinity | (Wishful thinking on the US Carrier there, I know) | 22:13 |
| marcoceppi | TheMuso: sorry, I'm in #ubuntu-motu trying to figure out the process, I've just been following https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages#Going_through_MOTU | 22:13 |
| achiang | infinity: that's exactly it | 22:14 |
| TheMuso | marcoceppi: Ok. | 22:14 |
| marcoceppi | TheMuso: I'm a bit lost in the process. I essentially need to get that package and another python package in to universe, then have charm-tools (already in universe) updated to 1.2.10 which is available and packaged already in a ppa | 22:14 |
| infinity | achiang: Right, yeah, we definitely want to revive the policy and add some click review addendums, I think. | 22:14 |
| achiang | infinity: we want to provide a tool that both commercial OEM engineering teams and our existing community can use to produce remixes | 22:14 |
| achiang | infinity: i'll kick off a mail | 22:15 |
| infinity | achiang: I don't suppose there's any plans to do the cute things Android used to do with carrier settings keyed off SIM cards? | 22:15 |
| TheMuso | marcoceppi: I'll continue this in #ubuntumotu, since thats where you were. | 22:16 |
| infinity | achiang: (My old, old Android phone used to actually change some UI colours when you stuck a T-Mobile SIM in, totally threw me the first time I saw it) | 22:16 |
| marcoceppi | TheMuso: thanks! | 22:16 |
| achiang | infinity: hm, you mean things like provisioning? | 22:16 |
| infinity | achiang: No, I mean visually. Obviously we'd want to do invisible backend things for carriers, if we can. | 22:16 |
| === salem_ is now known as _salem | ||
| achiang | infinity: ah. well... no one has asked for that feature yet | 22:17 |
| achiang | infinity: but i'm not philosophically opposed | 22:17 |
| infinity | achiang: But allowing them to define their "remix" in the distro, but keyed of SIM insertion is a fun trick. | 22:17 |
| infinity | s/of/off/ | 22:17 |
| infinity | To be fair, I think Android gave that up. My Kit Kat phone doesn't appear to turn pink when I switch to TMo. :P | 22:17 |
| achiang | infinity: it would be a matter of our developer bandwidth and any commercial agreements (which would reallocate said bandwidth ;) | 22:17 |
| xnox | infinity: achiang: well on touch images we preinstall clicks _only_ from the click store. Thus it would still be a remix if it preinstalls clicks from the ubuntu store. | 22:34 |
| infinity | xnox: I'm not entirely sure I'd agree, depending on what we end up allowing in the store. | 22:35 |
| infinity | xnox: But I haven't seen what policies are being applied there. | 22:35 |
| infinity | (Note that "it installs a bunch of packages from the archive" wasn't good enough for a remix either, it needed to maintain brand coherence) | 22:36 |
| xnox | infinity: well, true, we only preinstall those that come from the blessed account and get listed in the http://people.canonical.com/~ubuntu-archive/click_packages/click_list thus it's a very small subset. | 22:36 |
| infinity | xnox: Kay, but what you preinstall and what achiang is letting OEMs do are not the same thing. :P | 22:36 |
| infinity | Or, potentially. | 22:36 |
| xnox | infinity: sure :P | 22:37 |
| achiang | xnox: infinity: i'm not too worried about the OEM case - we will ensure they get their click apps into our store | 22:37 |
| infinity | achiang: Right, but even if it's in the store, that doesn't magically make preinstalling it match our previous remix policy. | 22:37 |
| achiang | right | 22:38 |
| infinity | achiang: For instance, if "only installs stuff from the archive" was the only requirement, Kubuntu would be a remix. It's clearly not. | 22:38 |
| xnox | infinity: the only remix i remember, was a business remix that installed stuff from the partner repository i think, no?! | 22:39 |
| infinity | xnox: There are dozens. | 22:39 |
| infinity | xnox: Mostly people remixing for localization, but there are others. | 22:39 |
| infinity | xnox: And the "business remix" was a special and weird case, since it was produced by Canonical, who owns the Ubuntu brand, so we didn't really have to play by the rules (though we certainly should, so we don't look like jerks). | 22:40 |
| xnox | yeah, from the announce "everything in the remix is available from the standard Software Centre" http://www.markshuttleworth.com/archives/1002 | 22:41 |
| === hholtmann_ is now known as hholtmann | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
