[00:00] feel free to remove my block if you folks reach consensus, or update it as necessary ... I'm off to bed shortly [00:02] oh, hell, blocks is unversioned [00:03] cjwatson: Luckily, a versioned block doesn't fail to block, but completely crashed britney! [00:03] * cjwatson updates [00:03] ("luckily") [00:03] hah [00:03] infinity: feature [00:03] s/crashed/crashes/ [00:04] /failsafe/, n.: [00:04] slangasek, infinity, cjwatson: please lets go with this: http://paste.ubuntu.com/7631134/ [00:05] ok [00:05] doko: WFM. [00:05] We'll need to delete the old one before you upload. [00:05] Doing that now. [00:05] ok [00:06] doko: I assume you test-built locally and checked gcc/g++/cpp binaries for sanity? [00:07] yes, installed these using a dist-upgrade [00:07] doko: Alright. Should be safe to upload now, I think. If I'm wrong, the binaries will reject, and I can retry later when it's definitely safe. :P [00:09] doko: When the fresh builds are done, I'll give them a once-over here too, and then undo Colin's block. === doko_ is now known as doko [00:15] infinity, i386 upload was rejected [00:15] old packages still in the archive [00:17] It's possible you'll have to build them in a PPA and copy back [00:17] doko: I'll sort it out. [00:17] But we'll see once the publisher processes the deletions [00:17] cjwatson: Nah, the publisher just raced. [00:17] ok, I'm afk now [00:17] cjwatson: It published the binaries after I deleted, and had a sad, I imagine. [00:17] cjwatson: Happened for armhf too, and those were the two arches that published this cycle. [00:17] So, next cycle should clear it up. [00:18] I think. [00:18] OK, so a retry later will clear it? OK. [00:18] Should do. [00:18] If not, there's a pretty icky soyuz bug here. [00:18] Too late, I'm at my quota of soyuz bugs fixed today [00:18] Heh. [00:18] * wgrant reads scrollback [00:19] wgrant: Highlighting on "soyuz bug"? [00:19] soyuz in general, IIRC [00:19] wgrant: Anyhow, probably just a misfeature not a bug. We'll see after another publisher run. [00:20] wgrant: 4/6 arches were published, 2 were accepted, I deleted the source, publisher ran, published the 2 outstanding, and those 2 caused reject clashes for the new upload. [00:20] wgrant: My assumption is that the next publisher run will clean them up. Or maybe I'll have to delete harder. :P [00:21] infinity: It won't require a publisher. You probably need to re-delete. [00:21] You probably deleted it before process-accepted ran [00:21] So the binaries didn't exist to be deleted yet. [00:21] wgrant: Kay, so those binaries live on forever now without a second deletion? That does seem like a bit of a bug. [00:21] (ie: the pending pubs should have been deleted too...) [00:22] But I'll re-delete. [00:22] infinity: There are no pubs until process-accepted runs; that's the problem. [00:22] mumble soyuz redesign mumble [00:22] Deleted harder. [00:23] infinity: I'd check the DASBP pages to be sure. [00:23] That means remembering how to navigate to the page I can never find. [00:23] I think cjwatson knows [00:24] But it has the best URL in Launchpad [00:24] https://launchpad.net/ubuntu/utopic/i386/cpp [00:24] That'll do. [00:24] Yep [00:24] I think I managed to click through to it once. [00:24] Only once. [00:24] I just did. [00:24] Well, sort of. [00:25] On-screen keyboards don't count. [00:25] I got to https://launchpad.net/ubuntu/utopic/i386/cpp/5:4.8.2-5ubuntu4 from the build record, and then stripped the version by hand. [00:25] I'm not convinced you can get there completely with clicks. [00:25] infinity: See the "Package relationships" section [00:26] And the breadcrumbs. [00:26] wgrant: Okay, so if I found something else that depended on cpp, I could navigate to it. That doesn't count. :P [00:26] infinity: Breadcrumbs on that page get you straight there! [00:26] DistroArchSeriesBinaryPackageRelease is finally useful for something :) [00:26] wgrant: The breadcrumb, indeed. [00:26] wgrant: SUPER INTUITIVE. [00:27] I'm disappointed that it wasn't DistributionArchitectureSeriesBinaryPackageRelease [00:28] Alright, deleting with extra violence cleared up the binary rejects. We're good to go. [00:28] And a quick once-over of the resulting binaries appears sane. As sane as 4.9 depending on 4.8 can be. [00:28] So, I shall unblock. [00:29] (base)adconrad@cthulhu:~/build/britney/hints-ubuntu$ bzr u [00:29] bzr: ERROR: unknown command "u" [00:30] Martin missed a golden opportunity there to respond with 'No, U!" [00:31] infinity: So, what would bzr U do? :) [00:32] RAOF: Something to "your mom", I imagine. [03:52] Good morning [03:52] Howdy. === Saviq is now known as Saviq|QtCS [08:09] bdmurray, I don't understand that email telling that the evince SRU to trusting has an increase in bug reports, the url in the email gives a "no data to display" page on e.u.c === jamesh_ is now known as jamesh [08:20] shrug [08:20] e.u.c seems to not be working properly [08:21] ev, bdmurray: hey, ^ ... e.g https://errors.ubuntu.com/?release=Ubuntu%2014.04&package=nautilus&period=year ... it tops to 500 then 80 reports, on the year view, we have bugs with > 80 reports a day on the daily view since release, those numbers are wrong [08:21] same on other sources [08:21] e.g I tried evince or unity-control-center [08:22] like picking the week view gives the same numbers [08:42] seb128: we cut over to a new database. All the reports you are seeing are new as of yesterday [08:42] infinity, ping [08:42] doko, ping [08:42] ev: did we loose history? :-( [08:42] seb128: this is part of a plan to reunify the previous databases and upgrade us to cassandra 2.0 [08:42] nope, we still have everything [08:42] it's just warehoused [08:42] tvoss, evil dbus-cpp pong [08:43] ev, k, is it going back to the e.u.c frontend? [08:43] ev, also, is that what creates the issue I was mentioning to bdmurray a bit before that ping? I got an email since that the evince SRU is blocked because there has been an increase in reports with that version [08:44] ev, is that because the system has no old record, consider there was no bug, and see new ones for the SRU that got copied yesterday, and assume the trend shows a regression? [08:44] tvoss: What doko said. [08:46] infinity, happy to learn what my mistake is :) the offending class is http://bazaar.launchpad.net/~phablet-team/dbus-cpp/trunk/view/head:/include/core/dbus/message_router.h [08:47] infinity, the mutex member causes the issues, both for 4.7 -> 4.8, and for 4.8 -> 4.9 [08:47] not sure why, though [08:47] tvoss: My C++ is weak, but doko might have some ideas? [08:48] infinity, doko is looking into it, sent him a pm in German :) [08:48] es ist kaputt [08:48] tvoss: I'd love to come to an agreement that this is a dbus-cpp bug, and fix it there, but there's always the possiblity that you've found a compiler bug with your clever abuse of the language. [08:49] infinity, I'm abusing the language at itmes, yes. Not in this particular case, though [08:49] if the std::mutex and std::lock_guard abi is stable, this should cause issues [08:49] shouldn't, obviously [08:50] seb128: just trying to dig you up some background material [08:50] tvoss: mutexex might invoke static inlining that isn't guaranteed stable. Though that would seem unfortunate. [08:51] tvoss: Anyhow, wild speculation from me at 3am isn't worth anyone's time. I'll let you and doko argue with it. [08:51] ev, no hurry, I'm afaik for a bit, I'm mostly interested in knowing how I get my SRU unflagged as increases errors when it doesn't (the url in the email gives a "no data to display" e.u.c) [08:51] infinity, well, sure, at which point I'm happy to hide it in the impl. But: I would like to understand why the abi obviously isn't stable [08:52] seb128: *nods* I'm afraid I don't know the answer to that. bdmurray and I believe slangasek were looking into how we handle phased updates with this temporary change [08:53] ev, ok, thanks, I'm waiting for them to be online then [08:58] seb128: so right now we have the data living in three separate clusters. Over the next few months we'll be pulling these together in the background, doing a bit of repair to tidy up counters and other things that don't merge so easily, and then cutting over to this Cassandra 2.0 version of the database. [08:58] Nothing will be lost, but this was needed as webops got painted into a corner by running out of disk space as part of an attempt to purge unneeded data. [08:58] It also brings a lot of improvements around storage size (compression by default, which makes it faster as well), ability to run big queries over the entire db more efficiently (the new client apis have knowledge of what nodes own which token ranges and split that across threads), and our ability to grow and manage the database nodes [08:58] sorry I couldn't be of more help on the phased updates stuff [09:02] doko: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1328838 [09:02] Ubuntu bug 1328838 in apt (Ubuntu) "Can't x-build ubuntu-system-settings with 1.0.4ubuntu1: /usr/lib/arm-linux-gnueabihf/libapt-pkg.so: undefined reference to `std::__throw_out_of_range_fmt(char const*, ...)@GLIBCXX_3.4.20'" [Undecided,New] [09:02] please look at that and see if you think it could be the same thing [09:04] doko: thats probably a dupe of #1329089 [09:08] I mention it partially because of the attempts to lay the blame on dbus-cpp. :) [09:10] Laney: oh, sorry I missed that bit [09:15] mvo, do you know why this is the same issue? [09:15] or is this guessing? [09:17] doko: just guessing [09:18] mvo, the please undo the duplicate [09:18] doko: done [09:21] doko, what is our rebuild policy if the toolchain changes? Do we rebuild the world? [09:22] tvoss, no, only for ABI changes. and until now I can't find any intentional ones ... [09:27] Laney, what does ldd say about /usr/lib/arm-linux-gnueabihf/libapt-pkg.so ? [09:27] which version? [09:27] e.g. libstdc++ [09:28] the one you mentioned in the bug report [09:29] doko, reading https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html right now [09:29] doko, outstanding issues explicitly says: "Because of this, mixing C++ ABIs is not recommended at this time." [09:29] doko, and I think that is the case we are hitting right now [09:33] Laney, which cross compiler did you use? [09:33] doko: whatever I get when I do sbuild --host=armhf foo.dsc [09:33] so 4.8 [09:35] oh you mean which version, yes [09:37] tvoss, that's why I'm fighting versioned build dependencies on g++ like in dbus-cpp ... [09:38] doko, the versioned build-dependency has gone [09:38] doko, we upgraded everything to latest [09:38] doko, including the platform api [09:40] libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0xb6d53000) [09:40] does it have a dep on libstdc++ (>= 4.9)? I assume not ... [09:40] but I guess it could be this problem tvoss mentions if the cross toolchain is behind the native one [09:40] Depends: libbz2-1.0, libc6 (>= 2.15), libgcc1 (>= 1:4.4.0), liblzma5 (>= 5.1.1alpha+20120614), libstdc++6 (>= 4.9), zlib1g (>= 1:1.2.3.4) [09:40] hmm [09:41] hm. [09:42] well, wanted to wait with the cross toolchain updates ... but looks I should start with this ... [09:47] there is no versioned build dep accross our components, as tvoss said [09:47] we removed all of that a bit over a month ago === vrruiz_ is now known as rvr [09:47] do you think the archive needs a run of stdc++s reverse build deps to rebuild? that sounds painful [09:48] last resort [09:49] well, I think for most cases it is not needed. I'd like to find out what exactly did cause the issue for dbus-cpp [09:49] cjwatson, admittedly, but: even the gcc guys themselves advice against mixing ABIs [09:49] mixing ABIs isn't strictly the same as mixing compiler versions [09:50] cjwatson, sure, but I think it strikes in this case [09:50] tvoss: That same page you pointed at also notes the painstaking effort made to make sure libstdc++ is backward-compatible, mind you (unless configured for an ABI break). [09:50] and my point is investigate first, don't sweep it under the carpet with a rebuild. [09:50] cjwatson, I'm all in for that [09:50] we can talk about what rebuilds are needed (and how to make sure that partial upgrades work, etc.) AFTER investigating the root cause. [09:51] infinity, sure, but: the warning is put there for a reason. I'm not saying it always breaks, just that we should be mindful [09:51] we aren't going to rebuild everything C++ on every toolchain change [09:51] just not happening :) [09:52] cjwatson, sure, I just would like to understand what prevents us from doing so in theory [09:52] $ apt-cache rdepends libstdc++6|wc -l [09:52] 5695 [09:52] and hasn't been necessary in the past as a general rule; there have been some events where it has been necessary to rebuild some things [09:52] rebuilding frivolously is expensive [09:52] both for us and our mirrors [09:53] cjwatson, tracking down build issues and weird behavior is expensive, too. Just saying that it is a balance [09:53] and if there really is an ABI event then we have to do more than rebuild; we'd probably have to change package names and so on [09:53] this is peanuts compared to the cost of rebuilding 5000 packages [09:53] I don't think you appreciate the scale there [09:54] lukasz is saying in another channel that they saw issues with the OSK [09:54] between 4.8 -> 4.9 [09:54] so, there are stones unturned that might only show up as bugs [09:54] that people wont be able to diagnose [09:54] sil2100: ^ [09:54] OSK? [09:54] on-screen keyboard [09:55] In case of ubuntu-keyboard these were FTBFS issues, so nothing serious [09:55] cjohnston, I surely appreciate the scale [09:55] cjwatson, even :) I surely appreciate the scale [09:55] we have done C++ ABI changes in the past, but only after we understood exactly what was causing them [09:56] package name changes and rebuilds in response to ABI changes I mean [09:56] and such things need to be synced with Debian [09:56] cjwatson, doko a question though: under the assumption that the c++ abi for 4.8 -> 4.9 did not change, and the ABI of dbus-cpp didn't change (as there was no upload to it), why would anything break at all? [09:57] obviously it needs to be investigated [09:57] my point is precisely the opposite of let's ignore ABI breaks [09:58] tvoss: If, as you note, you saw this from 4.7 to 4.8 as well, I feel this is something more subtle than your run of the mill ABI break. [09:58] but rebuilding everything C++ is a lot of expense that could maybe be avoided by root-causing the ABI change [09:58] (And we clearly didn't have to rebuild half the archive for that switch) [09:58] tvoss, I don't know yet. so starting with obvious things, mayb start testing for class sizes, offsets, etc ... [09:58] infinity: IIRC that was a C++11 specific thing [09:59] and hardly anything uses that yet [10:05] reading https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html in more detail - I think it's fairly clear from that page that the C++ ABI it's talking about is that controlled by -fabi-version, other ABI-affecting compiler options, and configure options used when building libstdc++; not simply changing version, because it has clear tables of versions, interfaces they provide, and compatibility between them. There's certainly scope ... [10:05] ... for problems there, but it is obviously intended to be backward-compatible except where explicitly indicated otherwise, and where backward-incompatibility isn't indicated we should dig into it and raise with upstream as necessary rather than assuming that it's a lost cause and rebuilding the world. [10:10] cjwatson, sure, I'm not arguing that gcc version change results in abi changes (not necessarily breaks) [10:11] instead I'm saying that it should raise awareness, and that we might want to thing about tooling to catch issues with the ABI in version change cases [10:11] s/thing/think/g [10:29] dbus-cpp comes with an std c++11, yet libstdc++ is probably (didn't check) built with c++98, and there is a mention that complex::{imag,real} would be affected (cause abi incompatibility) unless it gets inlined. [10:38] xnox, libstdc++ is build for both [10:42] libstdc++ has to be built for both otherwise c++11 wouldn't work at all, I expect [10:42] ok. [10:43] meh, checked mutex classes/headers and it well, obviously, doesn't use complex numbers to do mutexes. so yeah futile. [10:44] cjwatson, I guess that restricting the architectures set for ubuntu-system-settings to "amd64 armhf i386" would make the world unhappy through the u-s-s-online-accounts/online accounts stack, right? [10:44] seb128: Yup [10:44] :-/ [10:45] I suppose it can be made conditional in one way or another [10:45] k, need to way for mterry then [10:45] the build-dep [10:45] yeah, we could disable the wizard build on the other archs [10:45] Either avoid whatever functionality or make the wizard a compile-time option [10:46] cjwatson, just for context, we are discussing https://code.launchpad.net/~unity-team/ubuntu-system-settings/wizard.wifi/+merge/212675 which added a build-depends on libunity-mir-dev, which is only available on a limited archs set [10:47] making that part of it conditional seems reasonable [10:47] until we get unity-mir ported [10:47] right [10:50] * seb128 commented on the bug, waiting for mterry to get online to discuss it more [10:50] cjwatson, Laney: thanks [10:50] bug->mr === pete-woods is now known as pete-woods-lunch === MacSlow is now known as MacSlow|lunch [11:25] pitti: apw has tried running with systemd yesterday and his lightdm doesn't come up and he gets dropped to tty1 [11:26] pitti, yeah it is reliable i've rebooted 3-4 times and it occurs each time [11:26] xnox, apw: anything in sudo systemctl status lightdm ? [11:26] bug 1329056 [11:26] bug 1329056 in lightdm (Ubuntu) "lightdm does not start under systemd" [Undecided,New] https://launchpad.net/bugs/1329056 [11:26] it was saying something (dead) [11:26] pitti: that was inactive (dead) or somesuch [11:26] no log? [11:26] i am about to reboot [11:26] pitti, where would i find the said log [11:27] pitti: there is a tarball of hist jobs, but i was not entirely sure how to debug what he is experiencing. [11:27] apw: if it attempted to start, but failed with an error, it would be in systemctl status [11:27] the attached logs on that bug look like being from older/manual runs [11:28] pitti: how would one check if e.g. multi-user target was reached? and/or list everything that failed? [11:28] pitti, http://paste.ubuntu.com/7633248/ [11:28] maybe apw has more things failing that are needed to run lightdm.... [11:28] xnox: systemctl status shows all successes and failures (at the bottom) [11:29] pitti, http://paste.ubuntu.com/7633249/ [11:29] oh, no plymouht at all? [11:30] i believe i saw plymouth [11:30] though i'd have to reboot to be 100% sure [11:30] no trace of it in that log [11:30] anyway, it's only an After=, not a Requires= [11:31] pitti, ok, i defniatly see plymouth, i have purple, black, purple with ubuntu logo and dots, black VT1 [11:31] apw: is your plymouth started from initramfs, and not from rootfs? as in do you use encrypted root? [11:32] apw: i. e. "systemctl start lightdm" works? or how did you start it manually? [11:32] xnox, i don't use encrypted root, but i do use encrypted disks do i have the tools installed, but i thought you fixed that not to install them in the initramfs [11:32] you should have some plymouth units [11:32] pitti, yes systemctl start lightdm works just fine [11:33] xnox, and if they have plymouth in their name, i do not [11:34] xnox, ok there is a heap of plymouth in my initramfs, i thought you had fixed that [11:34] to not be in there if i didn't use root encrypted [11:34] multi-user.target - Multi-User System [11:34] Loaded: loaded (/lib/systemd/system/multi-user.target; disabled) [11:34] "disabled" - interesting [11:35] can i poke that one more? [11:35] apw: other hooks may pull in plymouth into the initramfs, crypto is just one of them. [11:35] xnox, ok perhaps we can investigate that later :) [11:36] apw: if uninstalling cryptsetup and regenerating initramfs removes plymouth, there is a bug in my logic. [11:36] pitti, is it me or is that both disabled and active ? [11:36] apw: or quicker to check if you have "overlayroot" package installed. [11:36] ah, looks the same here, so nevermind [11:37] dpkg-query: no packages found matching overlayroot [11:37] (is there a more specific cannel for ubuntu systemd we should be using?) [11:37] apw: this is as best as it gets [11:38] apw: we can use #ubuntu-kernel if you preffer that =) [11:38] but pitti doesn't idle there [11:38] graphical.target is also active [11:38] apw: i hear that kernel & systemd are about the same thing, and may only ever be upgraded in lock-step. [11:38] apw: ls -l /etc/systemd/system/graphical.target.wants/lightdm.service ? [11:39] pitti: i don't have that. [11:40] pitti, i dont have that either [11:40] hm, that must be a leftover from some intermediate experimentation then [11:40] i presume systemd is meant to run in initramfs as well, from its command set [11:41] apw: yes. [11:41] apw: well run in "dracut", not just any initramfs. [11:42] we don't want that for now [11:42] phone, brb === ara is now known as Guest77001 === _salem is now known as salem_ === MacSlow|lunch is now known as MacSlow [12:40] seb128: do you think you could spend some minutes to test the silo 017? [12:41] seb128: me and dbarth are testing it, but we are not sure whether it's behaving correctly (it about signon-ui-x11 and u-s-s-o-a coinstallation) [12:41] pitti: do you know how I can test incoming calls with phonesim? want to reproduce a ringtone issue that happens when getting an income voice call, but want to see if I'm able to reproduce using a tablet [12:41] seb128: the obsolete package "signon-ui" is not getting removed when we apt-get the new packages, so the installation of the new packages fails [12:42] rsalveti: yes, phonesim has some magic numbers which cause a callback: http://bazaar.launchpad.net/~phablet-team/dialer-app/trunk/view/head:/tests/autopilot/dialer_app/tests/test_calls.py#L120 [12:42] pitti: cool, will try that, thanks [12:42] rsalveti: in particular, 199 (http://bazaar.launchpad.net/~phablet-team/dialer-app/trunk/view/head:/tests/autopilot/dialer_app/helpers.py#L48) [12:44] mardy, hey, sure I can have a look ... do you have a pastebin of the command/log/error? [12:45] seb128: http://pastebin.ubuntu.com/7633228/ [12:45] seb128: no, sorry, that was wrong [12:45] mardy, why do you try to install signon-ui if it should be removed? [12:46] seb128: actually, what I get is: [12:46] The following packages have unmet dependencies: signon-ui-x11 : Conflicts: signon-ui [12:46] E: Unable to correct problems, you have held broken packages. [12:46] seb128: ^ [12:46] seb128: I'm just using citrain-slurp [12:46] mardy, what command give you that? [12:46] seb128: but maybe that command does not behave well and I should just dist-upgrade instead? [12:47] mardy, what about "sudo apt-get install signon-ui-x11 ubuntu-system-settings-online-accounts signon-ui-service" [12:48] seb128: same error [12:49] i can try dist-upgrade [12:49] but that doesn't tell me that ussoa is involved [12:49] mardy: how is the package rename done? can i check if the packaging was done correctly? [12:49] xnox: sure, let me dig up the MPs [12:50] mardy, the provides might be an issue [12:50] since you B on signon-ui (<< ) and provides are not versionned [12:50] xnox, https://launchpadlibrarian.net/176993740/signon-ui_0.16%2B14.10.20140530-0ubuntu1_0.17%2B14.10.20140605-0ubuntu1.diff.gz [12:50] mardy, ^ [12:50] xnox: https://code.launchpad.net/~mardy/ubuntu-system-settings-online-accounts/signon-ui-service/+merge/222016 and https://code.launchpad.net/~mardy/signon-ui/signon-ui-service/+merge/222017 [12:51] mardy, the issue, I think is that signon-ui-x11 provides signon-ui, or you make -service conflicts with that one [12:51] well with << 0.17, but since provides don't have versions [12:52] you probably need to drop the -x11 P or the -service B [12:52] mardy: that package rename is done incorrectly, which will fail dist-upgrades as well. [12:52] xnox, it's not a rename, it's a split [12:52] xnox, what is incorrect? [12:53] seb128: i don't see a split, well, i guess it's a split & rename. [12:53] xnox, it had one binary, now it has a -x11 and a -service, it's a split & rename yes [12:53] seb128: signon-ui should be provided as a dummy upgrade package [12:54] which depends on the correct thing. [12:54] conflicts & provides dropped [12:54] https://www.youtube.com/watch?v=5Qj8p-PEwbI I hate the news :| [12:55] mardy: i'd deffer to the person who approved your merge-proposals =))))) [12:55] seb128: *wink* *wink* =) [12:56] xnox, it seems we have disagreements on the topic though ;-) [12:56] xnox, dummy transitional are not strictly needed, they help when you have rdepends and apt is having issues resolving upgrades [12:56] seb128: well, signon-ui dummy upgrade package must be provided [12:56] xnox: so, it seems that you are right at least on your guess that dist-upgrade won't work: in fact, it does nothing [12:56] xnox, no it doesn't [12:56] the summary here is what? MIT student can't figure out how to connect to wifi? [12:57] seb128: there is no other way to trigger pkgA to upgrade to pkgB(provides pkgA) [12:57] xnox, we could update rdepends and use a provides, though dummy might make apt's job easier [12:57] xnox, but it's not a "must" [12:57] xnox, there is, C,R,P use [12:57] xnox: I wouldn't like to drop the Provides, otherwise we have to hunt and change the reverse deps [12:57] with updated rdepends [12:58] mardy: dummy package wouldn't require to change depends. [12:58] mardy: and it's only two reverse-depends in the whole archive [12:58] mardy, having a dummy transitional might be the easiest solution [12:58] $ reverse-depends signon-ui --list [12:58] signon-plugin-oauth2 [12:58] signond [12:58] xnox: and the dummy package would depend on the two possible implementations (signon-ui-x11 and u-s-s-o-a)? [12:58] but for 2 rdepends it seems like it's not strictly needed [12:59] xnox: with an ||, of course [12:59] mardy: not sure.... [13:00] mardy, you could just drop the breaks from -services [13:00] those 2 rdepends are not versionned [13:00] * mardy brb [13:00] so the provides ought to be enough [13:00] mardy: it looks like it would have been easier to (a) not rename signon-ui (b) make new signon-ui have whatever signon-ui-service currently has (c) create new signon-ui-x11 which has whatever is not in singon-ui [13:00] and signon-ui-x11 would just have Replaces: signon-ui (<< old) === pete-woods-lunch is now known as pete-woods [13:01] that's how package splits done normally, without renaming everything. [13:01] and one wouldn't need to change any dependencies [13:01] cause i presume reverse dependencies only need what signon-ui-service currently has. [13:02] xnox, things depending on signon-ui expect an UI and they would stop getting one with your suggestion [13:03] the current approach is fine, the provides does the job [13:03] it's just the -services breaks which creates the issue [13:03] right, as one can't do versioned breaks on a provides. provides are versionless. [13:05] * xnox goes back to rebuilding android [13:06] mardy, sorry it turned out in so much discussions, your call on what you want to do [13:06] either you can add a dummy, or try what I just suggested [13:12] mardy: can you update the merge proposal ^^ ? [13:13] mardy: i'd like to free the silo eventually [13:22] wgrant,infinity: There's one other theoretical way I know of to get to the DASBP pages: https://launchpad.net/ubuntu/utopic/i386 and search from there. The reason it's theoretical is that the search nearly always times out [13:24] dbarth: I'll first try seb128's suggestion first, since that's less changes [13:27] dbarth: I updated the signon-ui branch [13:32] mardy: thank you [13:37] ev, bdmurray: the e.u.c database changes create some confusion, maybe that would be a good think to email ubuntu-devel about, just a "fyi, work is ongoing which might creates some issues with the db" === Ursinha is now known as Ursinha-afk [13:45] apw: what is ls -l /etc/systemd/system/display-manager.service for you? [13:45] it should be a symlink to /lib/systemd/system/lightdm.service, unles you have more DMs installed [13:45] that's the multiplexer for making the whole thing compatible to debconf, /etc/X11/default-display-manager, etc. [13:45] xnox: ^ FYI; that's how it's selected/started [13:47] lrwxrwxrwx 1 root root 35 Jun 11 19:48 /etc/systemd/system/display-manager.service -> /lib/systemd/system/lightdm.service [13:50] apw: ok, that's right, thanks [13:52] apw: and $ cat /etc/X11/default-display-manager 2>/dev/null [13:52] apw: is also /usr/sbin/lightdm ... [13:52] pitti: cause there is ^ ExecStartPre check [13:52] right [13:52] fun to support all the gazillion different ways to configure it :) === Ursinha-afk is now known as Ursinha [13:54] /usr/sbin/lightdm [13:55] xnox: the one bit which I'm missing in the puzzle is how default-display-manager.service is started; it's not linked to any *.wants/ [13:56] ./system/graphical.target:Wants=display-manager.service [13:56] ? [13:56] /etc/systemd/system/display-manager.service -> /lib/systemd/system/lightdm.service [13:56] ah, right === timrc-afk is now known as timrc === kenvandine_ is now known as kenvandine [14:31] it seems late command and ubiquity success command are broken for 14.04 [14:32] has anybody a working preseed file with these two commands for ubuntu desktop? [14:33] kdeuser56: all the desktop jobs here are using late commands & fails/success commands https://jenkins.qa.ubuntu.com/view/Trusty/view/Smoke%20Testing/ [14:33] kdeuser56: so the released isos have those working [14:33] seb128: unflagging the stopped SRU => talk to bdmurray and he'll fix it up [14:33] xnox: I have the following:d-i preseed/late_command string sudo poweroff; [14:33] kdeuser56: preseeds can be found in https://code.launchpad.net/~ubuntu-test-case-dev/ubuntu-test-cases/desktop [14:33] kdeuser56: that's not the right way to shutdown ubiquity installs. [14:34] kdeuser56: ubiquity != d-i [14:34] seb128, slangasek: I'm looking into it [14:34] xnox: I know ... but ubiquity ubiquity/poweroff boolean true [14:34] is really broken [14:34] slangasek, thanks (pinged him, waiting for a reply) [14:34]