=== maclin__ is now known as maclin [06:45] please could the swift and neutron uploads for trusty be reviewed by the release team - they both contain high priority fixes (one for upgrades, the other for reboots) [06:46] and I don't want them to hold up final release versions later this week [07:18] infinity, netboot is not on the qatracker for Trusty Final. Is there a switch to flip or must it be added manually? [07:44] jibel: It would get added if there was a new d-i upload, I imagine. Or if someone manually copies it over. [07:44] stgraber: ^? [07:45] infinity, i re-enabled the touch cron job ... [08:16] hmm, if syncing libva/intel-vaapi-driver proves working, could those be squeezed in? new upstream releases to add broadwell support, didn't notice debian had those before now [08:17] both in universe [08:18] infinity, I'll add them with the risk of doing another tiny mistake. [08:19] jibel: Well, unless you're looking for a place to file bugs, they're almost meaningless there anyway. [08:20] jibel: It's not like we're going to not ship d-i if someone doesn't mark it ready. :) [08:20] crap, intel-gpu-tools is ancient [08:20] tjaalton: Deltas on those might be nice to look at without blindly accepting. [08:20] infinity: sure [08:20] infinity, agreed, but I need a place to say "this has been tested" [08:20] or not [08:21] jibel: Yeah, true. Well, try not to break anything. :P [08:21] jibel: Or ask stgraber nicely to figure out the right way. [08:22] infinity, no hurry, I can wait stgraber [08:22] * infinity needs to go attack his face with an angry fork full of omelette. Back in a few. [08:28] infinity: intel-vaapi-driver http://pastebin.com/mCydS6q8 , libva http://pastebin.com/K8cHEZPu [08:29] bumps both 1.2.x -> 1.3.0 [08:29] referenced as part of intel 2014Q1 "release" https://01.org/linuxgraphics/downloads/2014/2014q1-intel-graphics-stack-release [08:49] tjaalton: That's... A lot of changes. [08:50] tjaalton: I don't think that's remotely auditable, which means it needs to be very testable, which seems tough to do in a day and a half. [08:53] libva is in testing already [08:53] as i said they add broadwell support, which is bulk of the diff [08:53] actually both of them are in testing [09:01] tjaalton: How long have they beein in testing, and how many Debian bugs on either package post-date the uploads? [09:02] been in testing since the 12th, this is the only bug I could find, with a patch from upstream https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743701 [09:02] Debian bug 743701 in src:libva "libva1=1.3.0-1 with i965 makes all video "solid black" with mpv --hwdec=vaapi" [Normal,Open] [09:03] happens only with opengl output sink [09:06] tjaalton: Can you fix that bug, and we'll talk? :P [09:06] sure, I'll test without it first [09:07] tjaalton: (FWIW, this is probably a "no", but I understand the broadwell urge, so I'm thinking about it) [09:08] thanks for considering it ;) [09:30] Please consider releasing https://bugs.launchpad.net/ubuntu/+source/gdk-pixbuf/+bug/1174253 before trusty [09:30] Launchpad bug 1174253 in gdk-pixbuf (Ubuntu Precise) "Segfault (core dumped) in gdk-pixbuf on upgrade" [Undecided,Fix committed] [09:36] Laney: The comment directly above yours seems suspicious. [09:37] Laney: Oh, I suppose that might just be a partial upgrade oops. [09:37] Laney: Yeah, releasing. [09:37] I think it's his fail [09:37] Ta [09:50] Please can the neutron and swift upload for trusty be reviewed - they both fix high priority bugs and I'd prefer not to have anything pending when openstack cut final release tarballs if possible [10:05] I'm going to need someone to help update ubuntustudio-meta. We were lacking xfce bluetooth support - also, I needed to update our indicator packages to gtk3 [10:05] infinity: actually, xserver 1.15.1 fixes that libva bug, so we're good already :) [10:06] Besides, we have to rebuild our ISO anyway on account of Bug 1307485 [10:06] Launchpad bug 1307485 in network-manager-applet (Ubuntu) "Drop gnome-bluetooth to suggests (regression)" [Low,Fix released] https://launchpad.net/bugs/1307485 [10:06] http://lists.freedesktop.org/archives/libva/2014-April/002049.html [10:07] I'll test this combo on broadwell next, to see that it actually lowers cpu usage.. with mpv, vlc is crappy that it actually increases (!) cpu usage with vaapi [10:07] zequence, that should have been in in the first "final" image, at least was for xubuntu [10:08] Ah, there was a new build yesterday evening! [10:08] Anyway, we need bluetooth :P [10:10] zequence: Yeah, can sponsor and respin. Just a simple meta ./update needed? Let me give it a spin and see the output. [10:11] infinity: Yep, just an update required [10:11] zequence: Testing right now. [10:16] infinity: Oh, if you want to add a bug report to changelog, Bug 1307969 [10:16] Launchpad bug 1307969 in ubuntustudio-meta (Ubuntu) "no XFCE bluetooth support in ubuntustudio-meta" [Undecided,New] https://launchpad.net/bugs/1307969 [10:17] zequence: http://paste.ubuntu.com/7254450/ <-- Is that what you were expecting to see? [10:19] infinity: Yes. Looks good. [10:22] infinity, any chance you could look at my request above re neutron and swift pending uploads? [10:23] infinity: Actually, we seem to have blueman in our latest ISO. I was assuming it wouldn't be there [10:25] zequence: I assume you still need this meta I just uploaded, though? :P [10:26] jamespage: I'll look. [10:26] ta [10:26] infinity: The changes will be kept, absolutely :) [10:26] but, it seems it was not as critical anymore. [10:26] infinity: yep, vaapi works on bdw, not hitting that bug either [10:26] tested snb too [10:26] tjaalton: Alright, upload, I make no promises about it getting out of the queue, but we'll see. [10:27] tjaalton: s/upload/sync/ if the Debian packages are alright. [10:27] yeah they are [10:27] thanks [10:27] xnox, could you have a look at bug 1307983 ? [10:27] Launchpad bug 1307983 in ubiquity (Ubuntu) "System not localized after an OEM installation" [Undecided,New] https://launchpad.net/bugs/1307983 [10:31] Err, oh. That one's not seeded anyway. :P [10:31] tjaalton: So, I guess all I need to care about is libva. [10:31] tjaalton: I hope intel-vaapi-driver doesn't break without the libva update... === tkamppeter_ is now known as tkamppeter [10:31] it depends on the new libva [10:31] so boo :) [10:32] tjaalton: Depends at the packaging level, as in won't migrate? [10:32] tjaalton: Or as in "it'll break"? [10:32] build-depends [10:32] tjaalton: Okay, fine. Then no crisis here. If we don't accept libva, no harm done, it all moved to u-proposed. [10:32] s/moved/moves/ [10:32] right [10:32] is libva seeded then? it's in universe [10:33] libva1 (from libva) is seeded in: [10:33] kubuntu-active: daily-live [10:33] kubuntu: daily-live [10:33] lubuntu: daily, daily-live, daily-preinstalled [10:33] mythbuntu: daily-live [10:33] ubuntukylin: daily-live [10:33] ubuntustudio: dvd [10:33] xubuntu: daily-live [10:33] ah [10:33] jibel: why is oemconfig also french? [10:33] Seems like pretty much everyone who isn't Ubuntu uses it. [10:33] jibel: (in that bug report) [10:33] hehe [10:33] Curiously. [10:33] yeah there's also a MIR for it [10:33] untouched since a long time [10:34] Oh, possibly because of vlc. [10:34] No, vlc is only in myth. [10:34] * infinity shrugs. [10:35] Anyhow, we have at least one more full respin coming for this apport change, if I choose to let that in, but waiting to see if slightly more urgent things happen that we can do in parallel. [10:35] sure [10:35] I'll pre-review libva, though, so I can let it in the same batch if I'm okay with it. [10:48] xnox, I did the initial installation in french [10:48] jibel: interesting. [10:51] xnox, hm no, from my notes, for this test I redid it in english, only keyboard was in French [11:10] xnox, confirmed, initial installation in english, tz and kb autodetected to French by ubiquity. end-user setup in german (UI and slideshow are in german) after the setup and reboot, system is in english with locale reporting a mix of en, de and fr http://paste.ubuntu.com/7254675/ [11:30] I've a bunch of ubiquity fixes in progress [11:32] jibel: That was the most confusing reproduction sentence I've ever read. [11:53] infinity, xnox: can I do an ubiquity upload? === jhodapp|afk is now known as jhodapp [12:57] hi realese team, there is a critical bug of ubuntu kylin Bug #1298237 when upgrade from 13.10 to 14.04. I communicated with jibel and decided to add ubuntu-session dependency in ubuntukylin-default-settings. But We can't confirm wheather extra problems would be caused. [12:57] Launchpad bug 1298237 in Ubuntu Kylin "Cannot login the system after upgraded from 13.10 to 14.04" [Critical,Confirmed] https://launchpad.net/bugs/1298237 [13:01] maclin: what's your question? [13:01] maclin: It sounds sensible [13:02] It's troubling that you don't have ubuntu-desktop - you might be missing other bits [13:04] Riddel，Laney, yes, I also wonder we should add ubuntu-session or ubuntu-desktop. [13:05] maclin: ubuntu-desktop is removed because of ubuntukylin-default-settings in the first place [13:05] i.e. you remove some packages that ubuntu-desktop Depends on [13:05] Adding ubuntu-desktop would break a lot more. [13:05] Laney, we had over similar cases, it made me wonder if we should make unity depends on ubuntu-session, but that would be a circular depends [13:05] It would bring back packages they don't want, like firefox and ibus things. [13:05] jibel: so we do not configure network / install language packs during oem-config, yet i would expect the language support to kick in and ask for installation additional language packs which did not happen. [13:06] The real solution is for ubuntukylin to have a proper seed-based set of metapackages. [13:06] Yep [13:06] cjwatson: ^ can i talk to you about locales in a sec when you free after the ca-certificates-java. [13:06] maclin: ubuntu-session is what you want for now, but you could try installing ubuntu-desktop and reading what that wants to pull in to see if you're missing anything else [13:06] xnox, ok, I'm currently filing another report for this. [13:07] xnox, only missing english langpacks are installed [13:07] * Riddell waiting on a fix to pyqt as well [13:07] hey. whats the process for revewing things in this queue: https://launchpad.net/ubuntu/precise/+queue?queue_state=0&queue_text= . this is an nvidia driver fix for precise/3.13 that i'd like to test [13:09] Laney，the ubuntu-session is installed by default in the new installed ubuntu kylin 14.04. Does it mean I could just try to add ubuntu-session instead of ubuntu-desktop? [13:11] xnox, bug 1308056 [13:11] Launchpad bug 1308056 in language-selector (Ubuntu) "language packs not installed after a non-network installation in a non-english language" [Undecided,New] https://launchpad.net/bugs/1308056 [13:11] maclin: Yeah. You get it in 14.04 because ubuntu-desktop is installed for a little bit and then removed when ubuntukylin-default-settings has its hook run during the image build process. So there you do get its dependencies. [13:11] * jibel not sure about language-selector, feel free to reassign [13:12] maclin: I think you'll miss any other new dependency of ubuntu-desktop too, that's why I suggested test-installing it in a newly upgraded system to see what it tries to pull in [13:13] jibel: right, that now makes sense, i'm suspecting it's all the same thing. [13:13] jibel: thanks for that, let me see what is suppose to be triggering that. [13:13] xnox, good, thank you. [13:17] Laney, ok, I will try it:) [13:20] jibel: hey there [13:23] jibel: oh, netboot, right, I was vaguely hoping we'd need to upload it for a reason or another yesterday and that it'd just show up then but since that's not the case, I'll push it by hand [13:26] they should all be there now [13:29] stgraber,thank you [13:45] Laney: ping could you have a look at cinder rc3 when you get a chance please? [13:46] zul: Just going for lunch, but can after if stgraber or someone else can't do it meanwhile [13:47] I guess we should look at neutron and swift too [13:47] Laney: yes definently neutron and swift [13:50] that would be nice - thanks Laney [13:51] stgraber: Ta. [14:01] Laney， I tried to install ubuntu-desktop on a newly upgraded system and found 43 packages will be pulled. It is difficult to add so many dependencies. [14:05] I expect most of those will be indirect [14:10] cjwatson， do you mean we do not need to add those dependencies? [14:20] maclin: I mean that ubuntu-desktop probably only depends on some of those directly, and the rest are indirectly pulled in by *their* dependencies; if you're mirroring ubuntu-desktop then you should generally only mirror its direct deps [14:28] uh [14:31] cjwatson, that maybe a difficult for us to confirm direct deps and the correctness. Is there any simpler way to check that? The remaining time is limited and we don't want to pull new more problems. [14:34] maclin: "apt-cache show ubuntu-desktop" [14:34] it isn't hard to "confirm" direct dependencies, you just have to look at them [14:37] cjwatson, yeah, it is also a long list of packages [14:37] hi all [14:38] webbrowser-app is sitting in the unapproved queue, this upload is a trivial one-liner that fixes bug #1307420, can someone have a look and ack? [14:38] Launchpad bug 1307420 in webbrowser-app "The 'Activity' header doesn't disappear after navigating to the activity screen" [High,In progress] https://launchpad.net/bugs/1307420 [14:50] oSoMoN: We'll pull it in if something more urgent triggers a respin. [14:50] oSoMoN: We're not going to respin the release images just for webbrowser-app. [14:50] infinity, understood, thanks [14:53] infinity, so if I were to request another landing for webbrowser-app (with another rather critical bugfix), it would be unlikely to land in 14.04, given the timeframe, right? [14:53] oSoMoN: It would be as likely or unlikely as the current one in the queue. [14:54] oSoMoN: In other words, go ahead. [14:54] oSoMoN: If we can slip it in, we will, if not, it'll need to be pushed to an SRU. [14:54] got it [14:55] We could at least put webbrowser-app into proposed and block it, couldn't we? [14:55] We could, yes. [14:55] It's blocked right now [14:55] We could do that with all the bits in the queue that we're waffling on right now. [14:55] As long as no one else comes along and unblocks. :P [14:56] if moving it from unapproved to proposed allows me to merge the changes back in trunk, then that’d be great, as it would unblock the submission of this other landing request I was mentioning [14:57] Sure. We'll do that in a second. [14:57] oSoMoN: ci-train waits for it to be in release or updates, at least at the moment [14:58] but afaik that's overridable, so ask the landing team [14:58] cz [14:58] cjwatson, ah, thanks for the tip, will do [14:59] didrocks, can you comment on the above? ^^ i.e., if webbrowser-app lands in proposed, can I merge back the corresponding change in trunk? [14:59] oSoMoN: it's not going to be in -updates nor release? [14:59] we haven't decided where to put it yet [14:59] oSoMoN: you can branch from this proposed trunk [15:00] no need to merge that back [15:00] didrocks, well I need the trunk to be up-to-date to submit another landing request, don’t I ? [15:00] oSoMoN: as the publisher job is telling, you have it at https://code.launchpad.net/~ps-jenkins/webbrowser-app/trusty-proposed [15:00] for working and avoid conflicts [15:01] cjwatson: when this decision will be taken? [15:01] is it like hours or days? [15:02] didrocks: hours not days [15:02] oSoMoN: what's your other request your are waiting on the lock to be off? [15:03] Are you taking care of the queue? [15:03] didrocks, a fix for bug #1307735 [15:03] Launchpad bug 1307735 in webbrowser-app "can't open links in twitter" [Critical,In progress] https://launchpad.net/bugs/1307735 [15:03] Like should I not worry about doing those openstack reviews zul asked for? [15:03] didrocks: I think you should just override it for now though [15:04] oSoMoN: ok, so let's get you another silo. Just be aware that it means that your previous release is NOT delivered in Touch nor desktop [15:04] (you plural) [15:04] didrocks, the title is misleading (I’ll update it), it’s actually worse than just twitter being broken, all hyperlinks that request a new tab won’t open at all [15:04] oSoMoN: in the m&c job, you have "ignore destination version", check that one [15:04] let me get the exact wording, one sec [15:04] oSoMoN: IGNORE_PACKAGES_NOTINDEST [15:05] didrocks, okay [15:05] with the hint "Ignore if some packages are not published in the destination" [15:05] didrocks, I’ll file a landing request in a minute [15:05] oSoMoN: ok, please track that one as well as the previous isn't landed/you don't have feedback when it will be available [15:06] fginther: when you asked me for the reason of all those possible overrides, here is one FYI ^ [15:21] isn't http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html awefae long for release week? [15:23] Riddell: anything not handled gets moved over to u-proposed [15:23] doesn't have to be empty [15:23] anyway, some of us have been working on it for weeks :P [15:23] cjwatson: fair enough [15:23] cjwatson: Could you please answer my earlier question? ↑ [15:24] Laney: which one? [15:24] I basically want to know if I should keep my hands off the queue now :-) [15:24] Laney: -> infinity [15:24] Fair [15:24] Thought you were in the room of power [15:24] yeah, but infinity has the master keys, or something [15:27] Laney: hands off the queue, but if you think something's a good/sane/simple/etc opportunity candidate, go ahead and accept *only* if you block it first. [15:27] Laney: Then if we're forced to respin for other reasons, we can let in all the blocked things we want. [15:27] Laney: And if not, they'll carry over to u-proposed. [15:27] Alright [15:27] Thinking of block-all source any time soon? [15:27] Laney: Check the block at the end of my hint, I've already blocked most of the queue as it stands. [15:28] Laney: Could block-all source for a similar affect, but then we'd need to unblock universe/unseeded bits, and I'm not sure I want to. [15:28] Laney: Maybe it's about time, though. [15:28] Laney, neutron swift and cinder don't end up on media if that helps at all [15:29] Yeah, those openstack bits should be fine, if the reviews are sane. [15:29] (I haven't reviewed them yet) [15:29] (Someone else is free to :P) [15:30] Got scared off by the aforementioned block [16:07] infinity: I'm after respinned images after python-qt4 is done compiling, shall I just click rebuild or should it be synced with anything else? [16:20] Laney, are you still good to review the openstack packages in the queue? [16:21] jamespage: yeah, will do [16:21] Laney, thanks - sorry for hassling [16:32] cjwatson: infinity: provisionally i'm thinking to fix all jibel reported bugs with http://paste.ubuntu.com/7256183/ [16:33] which is respin all but server i think. [16:37] xnox: Server too, but that's fine. [16:40] Someone else should look at the neutron diff [16:40] It adds a wait-for-state call into pre-start of an upstart job [16:40] I've not used that before to know if it's sane === superm1_ is now known as superm1 [16:43] Laney, for reference its the same code that's in the l3-agent and the dhcp-agent in the same package [17:00] jamespage: alright then [17:00] Laney, I can explain how it works if you like [17:02] jamespage: it's okay, I read about wait-for-state now [17:04] there will be an edubuntu-netboot upload coming in pretty soon [17:04] Hi, just wanted to bring up bug 1292467 as something that may be worth mentioning in the release-notes [17:04] Launchpad bug 1292467 in unity-greeter (Ubuntu) "Dual screen greeter can break 3D acceleration" [Medium,Triaged] https://launchpad.net/bugs/1292467 [17:05] testing the fix now (turns out that last ltsp upload had the unfortunate side effect of breaking a sed in there...) === bfiller is now known as bfiller_afk [17:07] Laney, thankyou! [17:08] yw [17:08] I'm going to unblock them too unless someone screams in the next 5 minutes [17:09] *scream* [17:09] Laney: If you're unblocking the unseeded openstack stuff, that's fine. [17:10] Ya [17:10] also ta [17:12] nicer diff in the works http://paste.ubuntu.com/7256369/ [17:20] can someone please review that upload ^ [17:20] we'll want to respin Edubuntu once that's landed === jhodapp is now known as jhodapp|lunch === roadmr is now known as roadmr_afk [17:37] stgraber: xnox is working on a world-respin trigger anyway. [17:37] infinity: ok [17:37] infinity: I'm working on a couple more edubuntu installer fix ups, nothing too critical, just trying to avoid having our installer resize itself twice during install :) [17:38] we appear to have a bit of an issue going on as well - not sure how or when we'll be able to deal with it though [17:38] stgraber: Wouldn't that be more future-proof if you match on something that will always be in the commandline, with a .*$? [17:40] infinity: yeah, ironically, looking at the bzr history, the only bit which didn't change upstream over the past 4 years is splash :) [17:41] stgraber: ie "s/vt.handoff=7.*$/& nbdroot=:ltsp/" or something. [17:41] stgraber: Oh, or did vthandoff go away entirely? [17:41] it did [17:41] Right. Kay. [17:42] stgraber: What about the name of the line itself? This is pxelinux, right? [17:42] the actual position on the cmdline really doesn't matter, the fact that vt.handoff got dropped with the last bugfix release of ltsp did break the stuff :) [17:42] infinity: yeah, in theory we could match on initrd, though the config file in question has a dozen of those too [17:43] stgraber: Heh. Fair enough. Change looks fine regardless, just trying to save you from it breaking again. :P [17:44] Laney: From your changelog in that gvfs upload, I assue you intend for that to be an SRU? [17:44] infinity: That's what I expected [17:44] but if you want to let it in that'd be fine too [17:49] Laney: I'll give it a ponderance after I'm done "reviewing" maas. [17:54] tiny but much appreciated improvement for anyone installing Edubuntu ^ (since we'll be respinning anyway) [18:23] hi! can somebody accept webbrowser-app? it's a one-liner bugfix. [18:23] (same with webapps-applications actually) [18:26] slangasek, infinity: stgraber told me you would be missing some last minute toolchain updates. so here you are with an arm64 binutils (wrong code) fix === roadmr_afk is now known as roadmr [18:30] :) [18:32] um? [18:38] infinity: so can I respin? [18:40] Riddell: stop [18:40] Riddell: we're working on some other fixes [18:40] (hence that localechooser) [18:40] it'll be a respin-world due to all the locale damage [18:41] bug 1307983 [18:41] Launchpad bug 1307983 in localechooser (Ubuntu Trusty) "System not localized after an OEM or offline installation" [High,Confirmed] https://launchpad.net/bugs/1307983 [18:41] gotcha, thanks [18:41] Riddell: You can, but I'll end up doing it again in an hour or two. [18:57] robru: So, wouldn't the second of seb's suggestions ("handle the missing schemas") have been saner than adding a library dependency that you'll need to manually track because you don't actually like the library? [18:57] s/like/link/ [18:57] doko: Excellent. Shall we rebuild all of arm64 now? [18:57] infinity, i don't follow. [18:58] infinity, it was crashing due to missing schema, so I added the schema dependency. what do you mean "manually track"? [18:58] robru: You don't link to that library, so a simple rebuild won't magically bump your dependencies on ABI bumps and such, cause it's a manual hardcoded dep. Does it really make sense to depend on the library instead of just gracefully handling it not being around? [18:59] infinity, we usually do this on ppc64el only [18:59] infinity, well, missing gsettings schemas are difficult to handle on purpose. upstream on that feels it's appropriate to crash your program when the schema is missing. [19:00] doko: We can make an exception. We have a whole day and a half before release, plenty of time to redo the whole thing. [19:00] infinity, that was something that I've struggled with in the past, so the manual tracking option seemed easier [19:00] robru: schemas should be shipped in an arch:all package, of which we already have three. [19:00] gsettings-shemaas, and then one for ubuntu and ubuntu-touch [19:00] xnox, the change I'm making isn't to the package that ships the schema [19:01] robru: But why does the schema ship in the library package? [19:01] infinity, i have no idea. i didn't do that [19:01] Effective diff from this incoming ubiquity upload is difficult to mentally untangle just by looking at it, but it's http://paste.ubuntu.com/7256955/ === jhodapp|lunch is now known as jhodapp [19:02] gsettings-ubuntu-schemas, gsettings-ubuntu-touch-schemas, gsettings-desktop-schemas [19:02] xnox: thanks for all your help untangling this locale thing (since I meant to mention you in the changelogs and forgot; I just happened to be in front of the keyboard when doing the final bit) [19:03] infinity: ^ three packages which are all schemas for all desktops, unity7/8 common schemas, and unity8 only schemas [19:03] -touch- is a transitonal package [19:03] Laney: ok. [19:04] Laney: robru: i believe when this schema change came up a few days back, i did point out that it should be shipped in one of the above schemas-only packages and i was told that will be done as part of review/silo thing. [19:04] Sorry, I didn't know anything about this in advance === bfiller_afk is now known as bfiller [19:05] xnox, what schema change? I recall you talking about a schema change a couple days ago but I have no recollection of even which schema that was then. I'm not talking about making any changes to any schemas, just that I have a package that is missing a dependency on a schema that it needs [19:06] But a schema being in a versioned library package is wrong on so many levels. :/ [19:08] infinity, agreed, but I didn't put it there. can we really transition that out so close to release? My experience with that kind of transition is usually quite painful. can we just "manually track" this library dependency for the upcoming release and then fix "properly" the day U opens? [19:08] robru: Breaking out the arch indep stuff and depending on it isn't a transition. [19:09] robru: It's perhaps too late in the release, yes, but this library is not packaged like a sane library... [19:09] Is this for the migration script? [19:09] infinity, whatever jargon you want to use, you have to breaks/replaces/whatever Just Right, such that there's a seamless switch from one package providing the schema to the next. If there's any overlap, the packages will conflict [19:09] Laney, yes [19:09] I'd tend to agree we shouldn't be trying to fix this Right Now, but we also shouldn't forget [19:09] What about making it exit if the schema isn't found? [19:09] source = Gio.SettingsSchemaSource.get_default() [19:09] foo = source.lookup(UNITY_LAUNCHER_SETTINGS, True) [19:09] print foo is None [19:10] This sort of thing massively complicates the resolver's job on upgrade [19:10] Laney, because if it exited without the schema, it would completely fail to do the job that we need it to do, which would leave the user with broken/messy session state. [19:11] robru: unity packaging is just wrong, a library should not ship anything bug usr/lib/*/*.so.* [19:11] cjwatson, when you say "massively complicates", is that an argument in favor of fixing it properly now, or later? I'm not sure what you meant. [19:11] If you make it fail then it'll be re-run the next time [19:11] i.e. exit with a bad code [19:11] robru: He means that having a library that conflicts with the previous versions of itself completely confuses resolvers. [19:12] robru: It was an argument in favour of fixing it :-) I did say earlier "I'd tend to agree we shouldn't be trying to fix this Right Now" [19:12] right [19:12] robru: Because you're effectively telling every unity upgrade that it needs to remove everything then install everything, instead of gracefully upgrading one package at a time. [19:12] And unless something weird's going on they won't be able to launch unity without the library package installed anyway [19:12] So it doesn't matter until then [19:12] At which point the script succeeds [19:13] robru: compare with precise, the library package is sane, and just has the library in it. [19:14] I need to be off. There's my idea, take it or leave it :) [19:14] xnox, Laney: right, so if I'm understanding you correctly, fixing this The Right Way right now, will make the upgrade process messy. So we should just add this manual dep as a quick fix right now, so that users upgrading to trusty aren't immediately slapped with a session migration crash, and then when U opens we can get the unity library fixed properly. [19:14] I mean changing which package ships the library [19:14] ships the schema [19:15] Fixing this the Right Way simplifies the upgrade process, but it's risky to do two days before release [19:15] I've told you a way to avoid the ugly dep and having to do the packaging change, and argued that it's alright in reality too [19:15] Laney: That doesn't solve the packaging problem, mind you. [19:15] No, but that's not getting fixed for 14.04 [19:16] Laney: It could. It's frankly trivial. [19:16] Laney, yeah, exactly. so whether we just accept what I already did or do it your way, they're both technical debt that we have to undo later [19:16] Alright, I've made me points [19:16] see you [19:16] Laney, thanks for the input [19:16] so this goes back to [19:17] https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1193120 [19:17] Launchpad bug 1193120 in unity (Ubuntu) "unity-common is not common" [Undecided,Fix released] [19:17] So, slangasek made this change to fix update-manager having trouble auto-upgrading things [19:17] I therefore don't think we should simply undo it because there was a known problem previously [19:18] Alright. [19:18] Nevermind that, then. [19:18] sad, but such is live. [19:18] *life [19:20] robru: Meh. I'll accept it as-is, and this can be discussed $later. [19:20] infinity, I'll file a bug and assign myself so I remember to do it [19:20] infinity, thanks [19:23] infinity, cjwatson: so would using Breaks instead of Conflicts here against the previous lib versions be viable? [19:23] I've missed among the scrollback what the root problem was that people are having problems with right now [19:24] but yes, splitting the schemas back out into a "common" package which itself is tied to a specific version of the lib doesn't address the fundamental problem [19:26] slangasek: Conflicts wouldn't cause u-m to remove it ... [19:26] slangasek: I think now is probably not the right time to figure it out :) [19:26] cjwatson: do you mean Breaks, rather than Conflicts? [19:26] slangasek: Right, we went back through history and realized the library had a strict dep on the common anyway, so you hadn't actually made things worse. [19:26] ok [19:27] slangasek, I thought the consesus was to put the schemas in a "real" common package (not even part of the unity source package), and be genuinely common without depending on anything [19:27] It just seems like a fundamentally broken design at play here, and sorting that might be a Hard Problem. [19:27] Or a "la la la, who cares, it's fixed in unity8"? (is it?) [19:28] robru: They're only genuinely common if they can be... If we need versioned deps for those bits, it all fails miserably. [19:28] slangasek: update-manager keys off Conflicts+Replaces for "remove this old package", which IIRC is what you were relying on [19:28] cjwatson: right, it probably was [19:30] whats the convention for a package version that was removed from -proposed (say ubuntu2.2), and later another fix is applied on top of ubuntu2.1 ? [19:30] arges: ubuntu2.3 [19:30] (you can't reuse versions once they've been in the archive, even in -proposed) [19:30] slangasek: do I need to add the old changelog entry for ubuntu2.2 even though its not there? [19:31] or can it skip from 2.1 to 2.3 [19:31] arges: it can skip [19:31] slangasek: ok thanks : ) [19:39] arges: Better to skip, or you confuse people when the things 2.2 claims to do don't happen. [19:39] infinity, so wait, what did we decide then? just going to leave that as-is? [19:39] arges: (Unless 2.3 builds on top of 2.2, ie "* Fix the previous upload") [19:39] robru: For now, I accepted your package. [19:40] infinity: ok will do. no its basically a re-do of 2.2 without the issues [19:40] infinity, right, thank you. but I mean for U, should I try to move that schema somewhere else? or leave it? [19:40] robru: For 14.10 and/or SRUs, it would be nice to tear the problem apart a bit and figure out the best way, cause the current state seems questionable. [19:41]