| cjwatson | feel free to remove my block if you folks reach consensus, or update it as necessary ... I'm off to bed shortly | 00:00 |
|---|---|---|
| cjwatson | oh, hell, blocks is unversioned | 00:02 |
| infinity | cjwatson: Luckily, a versioned block doesn't fail to block, but completely crashed britney! | 00:03 |
| * cjwatson updates | 00:03 | |
| infinity | ("luckily") | 00:03 |
| slangasek | hah | 00:03 |
| cjwatson | infinity: feature | 00:03 |
| infinity | s/crashed/crashes/ | 00:03 |
| slangasek | /failsafe/, n.: | 00:04 |
| doko | slangasek, infinity, cjwatson: please lets go with this: http://paste.ubuntu.com/7631134/ | 00:04 |
| slangasek | ok | 00:05 |
| infinity | doko: WFM. | 00:05 |
| infinity | We'll need to delete the old one before you upload. | 00:05 |
| infinity | Doing that now. | 00:05 |
| doko | ok | 00:05 |
| infinity | doko: I assume you test-built locally and checked gcc/g++/cpp binaries for sanity? | 00:06 |
| doko | yes, installed these using a dist-upgrade | 00:07 |
| infinity | 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:07 |
| infinity | doko: When the fresh builds are done, I'll give them a once-over here too, and then undo Colin's block. | 00:09 |
| === doko_ is now known as doko | ||
| doko | infinity, i386 upload was rejected | 00:15 |
| doko | old packages still in the archive | 00:15 |
| cjwatson | It's possible you'll have to build them in a PPA and copy back | 00:17 |
| infinity | doko: I'll sort it out. | 00:17 |
| cjwatson | But we'll see once the publisher processes the deletions | 00:17 |
| infinity | cjwatson: Nah, the publisher just raced. | 00:17 |
| doko | ok, I'm afk now | 00:17 |
| infinity | cjwatson: It published the binaries after I deleted, and had a sad, I imagine. | 00:17 |
| infinity | cjwatson: Happened for armhf too, and those were the two arches that published this cycle. | 00:17 |
| infinity | So, next cycle should clear it up. | 00:17 |
| infinity | I think. | 00:18 |
| cjwatson | OK, so a retry later will clear it? OK. | 00:18 |
| infinity | Should do. | 00:18 |
| infinity | If not, there's a pretty icky soyuz bug here. | 00:18 |
| cjwatson | Too late, I'm at my quota of soyuz bugs fixed today | 00:18 |
| infinity | Heh. | 00:18 |
| * wgrant reads scrollback | 00:18 | |
| infinity | wgrant: Highlighting on "soyuz bug"? | 00:19 |
| wgrant | soyuz in general, IIRC | 00:19 |
| infinity | wgrant: Anyhow, probably just a misfeature not a bug. We'll see after another publisher run. | 00:19 |
| infinity | 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 |
| infinity | wgrant: My assumption is that the next publisher run will clean them up. Or maybe I'll have to delete harder. :P | 00:20 |
| wgrant | infinity: It won't require a publisher. You probably need to re-delete. | 00:21 |
| wgrant | You probably deleted it before process-accepted ran | 00:21 |
| wgrant | So the binaries didn't exist to be deleted yet. | 00:21 |
| infinity | wgrant: Kay, so those binaries live on forever now without a second deletion? That does seem like a bit of a bug. | 00:21 |
| infinity | (ie: the pending pubs should have been deleted too...) | 00:21 |
| infinity | But I'll re-delete. | 00:22 |
| wgrant | infinity: There are no pubs until process-accepted runs; that's the problem. | 00:22 |
| wgrant | mumble soyuz redesign mumble | 00:22 |
| infinity | Deleted harder. | 00:22 |
| wgrant | infinity: I'd check the DASBP pages to be sure. | 00:23 |
| infinity | That means remembering how to navigate to the page I can never find. | 00:23 |
| wgrant | I think cjwatson knows | 00:23 |
| wgrant | But it has the best URL in Launchpad | 00:24 |
| infinity | https://launchpad.net/ubuntu/utopic/i386/cpp | 00:24 |
| infinity | That'll do. | 00:24 |
| wgrant | Yep | 00:24 |
| wgrant | I think I managed to click through to it once. | 00:24 |
| wgrant | Only once. | 00:24 |
| infinity | I just did. | 00:24 |
| infinity | Well, sort of. | 00:24 |
| wgrant | On-screen keyboards don't count. | 00:25 |
| infinity | 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 |
| infinity | I'm not convinced you can get there completely with clicks. | 00:25 |
| wgrant | infinity: See the "Package relationships" section | 00:25 |
| wgrant | And the breadcrumbs. | 00:26 |
| infinity | wgrant: Okay, so if I found something else that depended on cpp, I could navigate to it. That doesn't count. :P | 00:26 |
| wgrant | infinity: Breadcrumbs on that page get you straight there! | 00:26 |
| wgrant | DistroArchSeriesBinaryPackageRelease is finally useful for something :) | 00:26 |
| infinity | wgrant: The breadcrumb, indeed. | 00:26 |
| infinity | wgrant: SUPER INTUITIVE. | 00:26 |
| wgrant | I'm disappointed that it wasn't DistributionArchitectureSeriesBinaryPackageRelease | 00:27 |
| infinity | Alright, deleting with extra violence cleared up the binary rejects. We're good to go. | 00:28 |
| infinity | And a quick once-over of the resulting binaries appears sane. As sane as 4.9 depending on 4.8 can be. | 00:28 |
| infinity | So, I shall unblock. | 00:28 |
| infinity | (base)adconrad@cthulhu:~/build/britney/hints-ubuntu$ bzr u | 00:29 |
| infinity | bzr: ERROR: unknown command "u" | 00:29 |
| infinity | Martin missed a golden opportunity there to respond with 'No, U!" | 00:30 |
| RAOF | infinity: So, what would bzr U do? :) | 00:31 |
| infinity | RAOF: Something to "your mom", I imagine. | 00:32 |
| pitti | Good morning | 03:52 |
| Unit193 | Howdy. | 03:52 |
| === Saviq is now known as Saviq|QtCS | ||
| seb128 | 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 | 08:09 |
| === jamesh_ is now known as jamesh | ||
| seb128 | shrug | 08:20 |
| seb128 | e.u.c seems to not be working properly | 08:20 |
| seb128 | 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 |
| seb128 | same on other sources | 08:21 |
| seb128 | e.g I tried evince or unity-control-center | 08:21 |
| seb128 | like picking the week view gives the same numbers | 08:22 |
| ev | seb128: we cut over to a new database. All the reports you are seeing are new as of yesterday | 08:42 |
| tvoss | infinity, ping | 08:42 |
| tvoss | doko, ping | 08:42 |
| seb128 | ev: did we loose history? :-( | 08:42 |
| ev | seb128: this is part of a plan to reunify the previous databases and upgrade us to cassandra 2.0 | 08:42 |
| ev | nope, we still have everything | 08:42 |
| ev | it's just warehoused | 08:42 |
| doko | tvoss, evil dbus-cpp pong | 08:42 |
| seb128 | ev, k, is it going back to the e.u.c frontend? | 08:43 |
| seb128 | 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:43 |
| seb128 | 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 |
| infinity | tvoss: What doko said. | 08:44 |
| tvoss | 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:46 |
| tvoss | infinity, the mutex member causes the issues, both for 4.7 -> 4.8, and for 4.8 -> 4.9 | 08:47 |
| tvoss | not sure why, though | 08:47 |
| infinity | tvoss: My C++ is weak, but doko might have some ideas? | 08:47 |
| tvoss | infinity, doko is looking into it, sent him a pm in German :) | 08:48 |
| Laney | es ist kaputt | 08:48 |
| infinity | 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:48 |
| tvoss | infinity, I'm abusing the language at itmes, yes. Not in this particular case, though | 08:49 |
| tvoss | if the std::mutex and std::lock_guard abi is stable, this should cause issues | 08:49 |
| tvoss | shouldn't, obviously | 08:49 |
| ev | seb128: just trying to dig you up some background material | 08:50 |
| infinity | tvoss: mutexex might invoke static inlining that isn't guaranteed stable. Though that would seem unfortunate. | 08:50 |
| infinity | 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 |
| seb128 | 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 |
| tvoss | 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:51 |
| ev | 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:52 |
| seb128 | ev, ok, thanks, I'm waiting for them to be online then | 08:53 |
| ev | 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 |
| ev | 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 |
| ev | 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 |
| ev | sorry I couldn't be of more help on the phased updates stuff | 08:58 |
| Laney | doko: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1328838 | 09:02 |
| ubottu | 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 |
| Laney | please look at that and see if you think it could be the same thing | 09:02 |
| mvo | doko: thats probably a dupe of #1329089 | 09:04 |
| Laney | I mention it partially because of the attempts to lay the blame on dbus-cpp. :) | 09:08 |
| mvo | Laney: oh, sorry I missed that bit | 09:10 |
| doko | mvo, do you know why this is the same issue? | 09:15 |
| doko | or is this guessing? | 09:15 |
| mvo | doko: just guessing | 09:17 |
| doko | mvo, the please undo the duplicate | 09:18 |
| mvo | doko: done | 09:18 |
| tvoss | doko, what is our rebuild policy if the toolchain changes? Do we rebuild the world? | 09:21 |
| doko | tvoss, no, only for ABI changes. and until now I can't find any intentional ones ... | 09:22 |
| doko | Laney, what does ldd say about /usr/lib/arm-linux-gnueabihf/libapt-pkg.so ? | 09:27 |
| Laney | which version? | 09:27 |
| doko | e.g. libstdc++ | 09:27 |
| doko | the one you mentioned in the bug report | 09:28 |
| tvoss | doko, reading https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html right now | 09:29 |
| tvoss | doko, outstanding issues explicitly says: "Because of this, mixing C++ ABIs is not recommended at this time." | 09:29 |
| tvoss | doko, and I think that is the case we are hitting right now | 09:29 |
| doko | Laney, which cross compiler did you use? | 09:33 |
| Laney | doko: whatever I get when I do sbuild --host=armhf foo.dsc | 09:33 |
| doko | so 4.8 | 09:33 |
| Laney | oh you mean which version, yes | 09:35 |
| doko | tvoss, that's why I'm fighting versioned build dependencies on g++ like in dbus-cpp ... | 09:37 |
| tvoss | doko, the versioned build-dependency has gone | 09:38 |
| tvoss | doko, we upgraded everything to latest | 09:38 |
| tvoss | doko, including the platform api | 09:38 |
| Laney | libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0xb6d53000) | 09:40 |
| doko | does it have a dep on libstdc++ (>= 4.9)? I assume not ... | 09:40 |
| Laney | but I guess it could be this problem tvoss mentions if the cross toolchain is behind the native one | 09:40 |
| Laney | 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 |
| doko | hmm | 09:40 |
| xnox | hm. | 09:41 |
| doko | well, wanted to wait with the cross toolchain updates ... but looks I should start with this ... | 09:42 |
| ricmm | there is no versioned build dep accross our components, as tvoss said | 09:47 |
| ricmm | we removed all of that a bit over a month ago | 09:47 |
| === vrruiz_ is now known as rvr | ||
| ricmm | do you think the archive needs a run of stdc++s reverse build deps to rebuild? that sounds painful | 09:47 |
| cjwatson | last resort | 09:48 |
| doko | 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 |
| tvoss | cjwatson, admittedly, but: even the gcc guys themselves advice against mixing ABIs | 09:49 |
| cjwatson | mixing ABIs isn't strictly the same as mixing compiler versions | 09:49 |
| tvoss | cjwatson, sure, but I think it strikes in this case | 09:50 |
| infinity | 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 |
| cjwatson | and my point is investigate first, don't sweep it under the carpet with a rebuild. | 09:50 |
| tvoss | cjwatson, I'm all in for that | 09:50 |
| cjwatson | we can talk about what rebuilds are needed (and how to make sure that partial upgrades work, etc.) AFTER investigating the root cause. | 09:50 |
| tvoss | 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 |
| cjwatson | we aren't going to rebuild everything C++ on every toolchain change | 09:51 |
| cjwatson | just not happening :) | 09:51 |
| tvoss | cjwatson, sure, I just would like to understand what prevents us from doing so in theory | 09:52 |
| doko | $ apt-cache rdepends libstdc++6|wc -l | 09:52 |
| doko | 5695 | 09:52 |
| cjwatson | 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 |
| cjwatson | rebuilding frivolously is expensive | 09:52 |
| cjwatson | both for us and our mirrors | 09:52 |
| tvoss | cjwatson, tracking down build issues and weird behavior is expensive, too. Just saying that it is a balance | 09:53 |
| cjwatson | 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 |
| cjwatson | this is peanuts compared to the cost of rebuilding 5000 packages | 09:53 |
| cjwatson | I don't think you appreciate the scale there | 09:53 |
| ricmm | lukasz is saying in another channel that they saw issues with the OSK | 09:54 |
| ricmm | between 4.8 -> 4.9 | 09:54 |
| ricmm | so, there are stones unturned that might only show up as bugs | 09:54 |
| ricmm | that people wont be able to diagnose | 09:54 |
| ricmm | sil2100: ^ | 09:54 |
| doko | OSK? | 09:54 |
| cjwatson | on-screen keyboard | 09:54 |
| sil2100 | In case of ubuntu-keyboard these were FTBFS issues, so nothing serious | 09:55 |
| tvoss | cjohnston, I surely appreciate the scale | 09:55 |
| tvoss | cjwatson, even :) I surely appreciate the scale | 09:55 |
| cjwatson | we have done C++ ABI changes in the past, but only after we understood exactly what was causing them | 09:55 |
| cjwatson | package name changes and rebuilds in response to ABI changes I mean | 09:56 |
| cjwatson | and such things need to be synced with Debian | 09:56 |
| tvoss | 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:56 |
| cjwatson | obviously it needs to be investigated | 09:57 |
| cjwatson | my point is precisely the opposite of let's ignore ABI breaks | 09:57 |
| infinity | 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 |
| cjwatson | but rebuilding everything C++ is a lot of expense that could maybe be avoided by root-causing the ABI change | 09:58 |
| infinity | (And we clearly didn't have to rebuild half the archive for that switch) | 09:58 |
| doko | tvoss, I don't know yet. so starting with obvious things, mayb start testing for class sizes, offsets, etc ... | 09:58 |
| cjwatson | infinity: IIRC that was a C++11 specific thing | 09:58 |
| cjwatson | and hardly anything uses that yet | 09:59 |
| cjwatson | 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 |
| cjwatson | ... 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:05 |
| tvoss | cjwatson, sure, I'm not arguing that gcc version change results in abi changes (not necessarily breaks) | 10:10 |
| tvoss | 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 |
| tvoss | s/thing/think/g | 10:11 |
| xnox | 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:29 |
| doko | xnox, libstdc++ is build for both | 10:38 |
| cjwatson | libstdc++ has to be built for both otherwise c++11 wouldn't work at all, I expect | 10:42 |
| xnox | ok. | 10:42 |
| xnox | meh, checked mutex classes/headers and it well, obviously, doesn't use complex numbers to do mutexes. so yeah futile. | 10:43 |
| seb128 | 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 |
| cjwatson | seb128: Yup | 10:44 |
| seb128 | :-/ | 10:44 |
| Laney | I suppose it can be made conditional in one way or another | 10:45 |
| seb128 | k, need to way for mterry then | 10:45 |
| Laney | the build-dep | 10:45 |
| seb128 | yeah, we could disable the wizard build on the other archs | 10:45 |
| Laney | Either avoid whatever functionality or make the wizard a compile-time option | 10:45 |
| seb128 | 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:46 |
| cjwatson | making that part of it conditional seems reasonable | 10:47 |
| cjwatson | until we get unity-mir ported | 10:47 |
| seb128 | right | 10:47 |
| * seb128 commented on the bug, waiting for mterry to get online to discuss it more | 10:50 | |
| seb128 | cjwatson, Laney: thanks | 10:50 |
| seb128 | bug->mr | 10:50 |
| === pete-woods is now known as pete-woods-lunch | ||
| === MacSlow is now known as MacSlow|lunch | ||
| xnox | pitti: apw has tried running with systemd yesterday and his lightdm doesn't come up and he gets dropped to tty1 | 11:25 |
| apw | pitti, yeah it is reliable i've rebooted 3-4 times and it occurs each time | 11:26 |
| pitti | xnox, apw: anything in sudo systemctl status lightdm ? | 11:26 |
| xnox | bug 1329056 | 11:26 |
| ubottu | bug 1329056 in lightdm (Ubuntu) "lightdm does not start under systemd" [Undecided,New] https://launchpad.net/bugs/1329056 | 11:26 |
| apw | it was saying something (dead) | 11:26 |
| xnox | pitti: that was inactive (dead) or somesuch | 11:26 |
| pitti | no log? | 11:26 |
| apw | i am about to reboot | 11:26 |
| apw | pitti, where would i find the said log | 11:26 |
| xnox | pitti: there is a tarball of hist jobs, but i was not entirely sure how to debug what he is experiencing. | 11:27 |
| pitti | apw: if it attempted to start, but failed with an error, it would be in systemctl status | 11:27 |
| pitti | the attached logs on that bug look like being from older/manual runs | 11:27 |
| xnox | pitti: how would one check if e.g. multi-user target was reached? and/or list everything that failed? | 11:28 |
| apw | pitti, http://paste.ubuntu.com/7633248/ | 11:28 |
| xnox | maybe apw has more things failing that are needed to run lightdm.... | 11:28 |
| pitti | xnox: systemctl status shows all successes and failures (at the bottom) | 11:28 |
| apw | pitti, http://paste.ubuntu.com/7633249/ | 11:29 |
| pitti | oh, no plymouht at all? | 11:29 |
| apw | i believe i saw plymouth | 11:30 |
| apw | though i'd have to reboot to be 100% sure | 11:30 |
| pitti | no trace of it in that log | 11:30 |
| pitti | anyway, it's only an After=, not a Requires= | 11:30 |
| apw | pitti, ok, i defniatly see plymouth, i have purple, black, purple with ubuntu logo and dots, black VT1 | 11:31 |
| xnox | apw: is your plymouth started from initramfs, and not from rootfs? as in do you use encrypted root? | 11:31 |
| pitti | apw: i. e. "systemctl start lightdm" works? or how did you start it manually? | 11:32 |
| apw | 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 |
| xnox | you should have some plymouth units | 11:32 |
| apw | pitti, yes systemctl start lightdm works just fine | 11:32 |
| apw | xnox, and if they have plymouth in their name, i do not | 11:33 |
| apw | xnox, ok there is a heap of plymouth in my initramfs, i thought you had fixed that | 11:34 |
| apw | to not be in there if i didn't use root encrypted | 11:34 |
| pitti | multi-user.target - Multi-User System | 11:34 |
| pitti | Loaded: loaded (/lib/systemd/system/multi-user.target; disabled) | 11:34 |
| pitti | "disabled" - interesting | 11:34 |
| apw | can i poke that one more? | 11:35 |
| xnox | apw: other hooks may pull in plymouth into the initramfs, crypto is just one of them. | 11:35 |
| apw | xnox, ok perhaps we can investigate that later :) | 11:35 |
| xnox | apw: if uninstalling cryptsetup and regenerating initramfs removes plymouth, there is a bug in my logic. | 11:36 |
| apw | pitti, is it me or is that both disabled and active ? | 11:36 |
| xnox | apw: or quicker to check if you have "overlayroot" package installed. | 11:36 |
| pitti | ah, looks the same here, so nevermind | 11:36 |
| apw | dpkg-query: no packages found matching overlayroot | 11:37 |
| apw | (is there a more specific cannel for ubuntu systemd we should be using?) | 11:37 |
| xnox | apw: this is as best as it gets | 11:37 |
| xnox | apw: we can use #ubuntu-kernel if you preffer that =) | 11:38 |
| xnox | but pitti doesn't idle there | 11:38 |
| pitti | graphical.target is also active | 11:38 |
| xnox | apw: i hear that kernel & systemd are about the same thing, and may only ever be upgraded in lock-step. | 11:38 |
| pitti | apw: ls -l /etc/systemd/system/graphical.target.wants/lightdm.service ? | 11:38 |
| xnox | pitti: i don't have that. | 11:39 |
| apw | pitti, i dont have that either | 11:40 |
| pitti | hm, that must be a leftover from some intermediate experimentation then | 11:40 |
| apw | i presume systemd is meant to run in initramfs as well, from its command set | 11:40 |
| xnox | apw: yes. | 11:41 |
| xnox | apw: well run in "dracut", not just any initramfs. | 11:41 |
| pitti | we don't want that for now | 11:42 |
| pitti | phone, brb | 11:42 |
| === ara is now known as Guest77001 | ||
| === _salem is now known as salem_ | ||
| === MacSlow|lunch is now known as MacSlow | ||
| mardy | seb128: do you think you could spend some minutes to test the silo 017? | 12:40 |
| mardy | 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 |
| rsalveti | 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 |
| mardy | 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:41 |
| pitti | 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 |
| rsalveti | pitti: cool, will try that, thanks | 12:42 |
| pitti | rsalveti: in particular, 199 (http://bazaar.launchpad.net/~phablet-team/dialer-app/trunk/view/head:/tests/autopilot/dialer_app/helpers.py#L48) | 12:42 |
| seb128 | mardy, hey, sure I can have a look ... do you have a pastebin of the command/log/error? | 12:44 |
| mardy | seb128: http://pastebin.ubuntu.com/7633228/ | 12:45 |
| mardy | seb128: no, sorry, that was wrong | 12:45 |
| seb128 | mardy, why do you try to install signon-ui if it should be removed? | 12:45 |
| mardy | seb128: actually, what I get is: | 12:46 |
| mardy | The following packages have unmet dependencies: signon-ui-x11 : Conflicts: signon-ui | 12:46 |
| mardy | E: Unable to correct problems, you have held broken packages. | 12:46 |
| mardy | seb128: ^ | 12:46 |
| mardy | seb128: I'm just using citrain-slurp | 12:46 |
| seb128 | mardy, what command give you that? | 12:46 |
| mardy | seb128: but maybe that command does not behave well and I should just dist-upgrade instead? | 12:46 |
| seb128 | mardy, what about "sudo apt-get install signon-ui-x11 ubuntu-system-settings-online-accounts signon-ui-service" | 12:47 |
| mardy | seb128: same error | 12:48 |
| dbarth | i can try dist-upgrade | 12:49 |
| dbarth | but that doesn't tell me that ussoa is involved | 12:49 |
| xnox | mardy: how is the package rename done? can i check if the packaging was done correctly? | 12:49 |
| mardy | xnox: sure, let me dig up the MPs | 12:49 |
| seb128 | mardy, the provides might be an issue | 12:50 |
| seb128 | since you B on signon-ui (<< ) and provides are not versionned | 12:50 |
| seb128 | xnox, https://launchpadlibrarian.net/176993740/signon-ui_0.16%2B14.10.20140530-0ubuntu1_0.17%2B14.10.20140605-0ubuntu1.diff.gz | 12:50 |
| seb128 | mardy, ^ | 12:50 |
| mardy | 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:50 |
| seb128 | mardy, the issue, I think is that signon-ui-x11 provides signon-ui, or you make -service conflicts with that one | 12:51 |
| seb128 | well with << 0.17, but since provides don't have versions | 12:51 |
| seb128 | you probably need to drop the -x11 P or the -service B | 12:52 |
| xnox | mardy: that package rename is done incorrectly, which will fail dist-upgrades as well. | 12:52 |
| seb128 | xnox, it's not a rename, it's a split | 12:52 |
| seb128 | xnox, what is incorrect? | 12:52 |
| xnox | seb128: i don't see a split, well, i guess it's a split & rename. | 12:53 |
| seb128 | xnox, it had one binary, now it has a -x11 and a -service, it's a split & rename yes | 12:53 |
| xnox | seb128: signon-ui should be provided as a dummy upgrade package | 12:53 |
| xnox | which depends on the correct thing. | 12:54 |
| xnox | conflicts & provides dropped | 12:54 |
| Bluefoxicy | https://www.youtube.com/watch?v=5Qj8p-PEwbI I hate the news :| | 12:54 |
| xnox | mardy: i'd deffer to the person who approved your merge-proposals =))))) | 12:55 |
| xnox | seb128: *wink* *wink* =) | 12:55 |
| seb128 | xnox, it seems we have disagreements on the topic though ;-) | 12:56 |
| seb128 | xnox, dummy transitional are not strictly needed, they help when you have rdepends and apt is having issues resolving upgrades | 12:56 |
| xnox | seb128: well, signon-ui dummy upgrade package must be provided | 12:56 |
| mardy | 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 |
| seb128 | xnox, no it doesn't | 12:56 |
| Bluefoxicy | the summary here is what? MIT student can't figure out how to connect to wifi? | 12:56 |
| xnox | seb128: there is no other way to trigger pkgA to upgrade to pkgB(provides pkgA) | 12:57 |
| seb128 | xnox, we could update rdepends and use a provides, though dummy might make apt's job easier | 12:57 |
| seb128 | xnox, but it's not a "must" | 12:57 |
| seb128 | xnox, there is, C,R,P use | 12:57 |
| mardy | xnox: I wouldn't like to drop the Provides, otherwise we have to hunt and change the reverse deps | 12:57 |
| seb128 | with updated rdepends | 12:57 |
| xnox | mardy: dummy package wouldn't require to change depends. | 12:58 |
| xnox | mardy: and it's only two reverse-depends in the whole archive | 12:58 |
| seb128 | mardy, having a dummy transitional might be the easiest solution | 12:58 |
| xnox | $ reverse-depends signon-ui --list | 12:58 |
| xnox | signon-plugin-oauth2 | 12:58 |
| xnox | signond | 12:58 |
| mardy | xnox: and the dummy package would depend on the two possible implementations (signon-ui-x11 and u-s-s-o-a)? | 12:58 |
| seb128 | but for 2 rdepends it seems like it's not strictly needed | 12:58 |
| mardy | xnox: with an ||, of course | 12:59 |
| xnox | mardy: not sure.... | 12:59 |
| seb128 | mardy, you could just drop the breaks from -services | 13:00 |
| seb128 | those 2 rdepends are not versionned | 13:00 |
| * mardy brb | 13:00 | |
| seb128 | so the provides ought to be enough | 13:00 |
| xnox | 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 |
| xnox | and signon-ui-x11 would just have Replaces: signon-ui (<< old) | 13:00 |
| === pete-woods-lunch is now known as pete-woods | ||
| xnox | that's how package splits done normally, without renaming everything. | 13:01 |
| xnox | and one wouldn't need to change any dependencies | 13:01 |
| xnox | cause i presume reverse dependencies only need what signon-ui-service currently has. | 13:01 |
| seb128 | xnox, things depending on signon-ui expect an UI and they would stop getting one with your suggestion | 13:02 |
| seb128 | the current approach is fine, the provides does the job | 13:03 |
| seb128 | it's just the -services breaks which creates the issue | 13:03 |
| xnox | right, as one can't do versioned breaks on a provides. provides are versionless. | 13:03 |
| * xnox goes back to rebuilding android | 13:05 | |
| seb128 | mardy, sorry it turned out in so much discussions, your call on what you want to do | 13:06 |
| seb128 | either you can add a dummy, or try what I just suggested | 13:06 |
| dbarth | mardy: can you update the merge proposal ^^ ? | 13:12 |
| dbarth | mardy: i'd like to free the silo eventually | 13:13 |
| cjwatson | 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:22 |
| mardy | dbarth: I'll first try seb128's suggestion first, since that's less changes | 13:24 |
| mardy | dbarth: I updated the signon-ui branch | 13:27 |
| dbarth | mardy: thank you | 13:32 |
| seb128 | 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" | 13:37 |
| === Ursinha is now known as Ursinha-afk | ||
| pitti | apw: what is ls -l /etc/systemd/system/display-manager.service for you? | 13:45 |
| pitti | it should be a symlink to /lib/systemd/system/lightdm.service, unles you have more DMs installed | 13:45 |
| pitti | that's the multiplexer for making the whole thing compatible to debconf, /etc/X11/default-display-manager, etc. | 13:45 |
| pitti | xnox: ^ FYI; that's how it's selected/started | 13:45 |
| apw | lrwxrwxrwx 1 root root 35 Jun 11 19:48 /etc/systemd/system/display-manager.service -> /lib/systemd/system/lightdm.service | 13:47 |
| pitti | apw: ok, that's right, thanks | 13:50 |
| xnox | apw: and $ cat /etc/X11/default-display-manager 2>/dev/null | 13:52 |
| xnox | apw: is also /usr/sbin/lightdm ... | 13:52 |
| xnox | pitti: cause there is ^ ExecStartPre check | 13:52 |
| pitti | right | 13:52 |
| pitti | fun to support all the gazillion different ways to configure it :) | 13:52 |
| === Ursinha-afk is now known as Ursinha | ||
| apw | /usr/sbin/lightdm | 13:54 |
| pitti | 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:55 |
| xnox | ./system/graphical.target:Wants=display-manager.service | 13:56 |
| xnox | ? | 13:56 |
| xnox | /etc/systemd/system/display-manager.service -> /lib/systemd/system/lightdm.service | 13:56 |
| pitti | ah, right | 13:56 |
| === timrc-afk is now known as timrc | ||
| === kenvandine_ is now known as kenvandine | ||
| kdeuser56 | it seems late command and ubiquity success command are broken for 14.04 | 14:31 |
| kdeuser56 | has anybody a working preseed file with these two commands for ubuntu desktop? | 14:32 |
| xnox | 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 |
| xnox | kdeuser56: so the released isos have those working | 14:33 |
| slangasek | seb128: unflagging the stopped SRU => talk to bdmurray and he'll fix it up | 14:33 |
| kdeuser56 | xnox: I have the following:d-i preseed/late_command string sudo poweroff; | 14:33 |
| xnox | kdeuser56: preseeds can be found in https://code.launchpad.net/~ubuntu-test-case-dev/ubuntu-test-cases/desktop | 14:33 |
| xnox | kdeuser56: that's not the right way to shutdown ubiquity installs. | 14:33 |
| xnox | kdeuser56: ubiquity != d-i | 14:34 |
| bdmurray | seb128, slangasek: I'm looking into it | 14:34 |
| kdeuser56 | xnox: I know ... but ubiquity ubiquity/poweroff boolean true | 14:34 |
| kdeuser56 | is really broken | 14:34 |
| seb128 | slangasek, thanks (pinged him, waiting for a reply) | 14:34 |
| seb128 | bdmurray, hey | 14:34 |
| xnox | kdeuser56: ubiquity/reboot: automatically reboot when the installer completes. Be sure to add 'noprompt' to the kernel command line to also skip the "please remove the disc, close the tray (if any) and press ENTER to continue" usplash prompt. | 14:34 |
| xnox | kdeuser56: https://wiki.ubuntu.com/UbiquityAutomation | 14:35 |
| kdeuser56 | xnox: I know all of that, but believe me, it does not work here | 14:35 |
| xnox | kdeuser56: d-i preseed/late_command is not excecuted by ubiquity. | 14:35 |
| kdeuser56 | xnox: I can give you all my scripts | 14:35 |
| xnox | kdeuser56: you want ubiquity/success_command & / or ubiquity/failure_command: | 14:35 |
| kdeuser56 | xnox: neither is ubiquity ubiquity/success_command shutdown -h now | 14:35 |
| kdeuser56 | xnox: the ubiquity reboot command works, but ubiquity poweroff command gets ignored ... if the install finishes, it boots to desktop | 14:36 |
| bdmurray | seb128: one issue was that the url in the email and the package version two times. this is sorted now. | 14:36 |
| bdmurray | s/and/had/ | 14:36 |
| kdeuser56 | xnox: my kernel commandline when booting the desktop is: "file=/cdrom/preseed/install.seed noninteractive noprompt initrd=/casper/initrd.lz quiet splash --" | 14:37 |
| kdeuser56 | xnox: I mean when booting my remastered live cd | 14:38 |
| bdmurray | slangasek: how do you feel about disabling the rate increase check for ~24 hours | 14:38 |
| kdeuser56 | xnox: the preseed works fine, but the success commands do not work, no matter how simple they are. | 14:39 |
| slangasek | bdmurray: probably a good idea | 14:39 |
| slangasek | bdmurray: otherwise you're just going to have to play whack-a-mole with them all | 14:39 |
| kdeuser56 | xnox: ubiquity/reboot works, poweroff is broken ... the live cd boots desktop after a successful install, even if I have set the poweroff value | 14:39 |
| === timrc is now known as timrc-afk | ||
| kdeuser56 | xnox: A messy version of what I tried to do: http://paste.ubuntu.com/ | 14:41 |
| kdeuser56 | xnox: damn ... http://paste.ubuntu.com/7634008/ | 14:41 |
| kdeuser56 | xnox: anything else you can advise me? | 14:44 |
| seb128 | bdmurray, slangasek: could somebody send an email to the devel list to have a public status update/fyi on what is happening? e.u.c appears to miss datas and SRU trigger weird emails, that probably deserve some communication | 14:48 |
| bdmurray | slangasek: https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/no-rate-increase-check/+merge/222957 | 14:48 |
| kdeuser56 | xnox: no respone anymore? :-( | 14:48 |
| slangasek | bdmurray: wasn't it decided that IS was going to handle communicating to the list about this? I guess that hasn't happened | 14:49 |
| === timrc-afk is now known as timrc | ||
| bdmurray | slangasek: that was my understanding too, I'll send something I guess | 14:50 |
| slangasek | bdmurray: ok | 14:50 |
| slangasek | bdmurray: merged | 14:50 |
| xnox | kdeuser56: you should not presseed both reboot and poweroff | 14:52 |
| Laney | bdmurray: just fixed that whoopsie/ubuntu-system-settings bug you told me about in malta btw | 14:52 |
| kdeuser56 | xnox: I tried all combinations ... | 14:52 |
| bdmurray | Laney: oh, cool thanks! | 14:52 |
| xnox | kdeuser56: and ubiquity/poweroff should work. | 14:52 |
| kdeuser56 | xnox: I am already pretty frustrated because I kinda bruteforced to find out what works ... and that command clearly does not work | 14:53 |
| xnox | kdeuser56: please file a bug with complete installer syslog in debug mode. | 14:54 |
| xnox | kdeuser56: but do it against stock/released isos, not a customized one. | 14:54 |
| kdeuser56 | xnox: my remaster iso is the original iso, I simply modified the boot options | 14:55 |
| xnox | kdeuser56: you seem to mix d-i & ubiquity presseed values.... | 14:55 |
| xnox | kdeuser56: ubiquity doesn't run tasksel for example, and etc. | 14:55 |
| kdeuser56 | xnox: since there is really really bad documentation, how would I do it right? | 14:55 |
| xnox | kdeuser56: which documentation did you use? | 14:56 |
| kdeuser56 | xnox: lol, the tasksel tasksel commands are from the official kubuntu iso | 14:56 |
| kdeuser56 | xnox: in kubuntu.seed | 14:56 |
| kdeuser56 | xnox: regarding the doc: really bad situation imho | 14:57 |
| kdeuser56 | xnox: one example: https://help.ubuntu.com/14.04/installation-guide/example-preseed.txt | 14:57 |
| xnox | and embedding btrfs filesystems on lvm2 volumes -> i'm not sure that would do what you believe it. | 14:57 |
| xnox | kdeuser56: that's not docs for ubiquity preseeding. | 14:57 |
| xnox | kdeuser56: but for d-i, server and netboot. | 14:58 |
| kdeuser56 | xnox: that is not noted anywhere | 14:58 |
| kdeuser56 | xnox: I searched various examples on the net for the desktop | 14:58 |
| kdeuser56 | xnox: everywhere its nearly identical | 14:58 |
| xnox | https://wiki.ubuntu.com/DesktopCDOptions | 14:58 |
| xnox | https://wiki.ubuntu.com/UbiquityAutomation | 14:58 |
| xnox | kdeuser56: above two links really list the limited subset of individual keys one can pressed for ubiquity & the custom keys ubiquity accepts for preseeding. | 14:59 |
| kdeuser56 | xnox: http://www.filewatcher.com/p/dell-recovery_0.98.2.tar.gz.1421121/dell-recovery.natty/casper/seeds/ubuntu.seed.html | 14:59 |
| xnox | kdeuser56: dell-recovery is not ubiquity, nor d-i. it has it's own presseeding mechanism. | 15:00 |
| xnox | kdeuser56: dell-recovery is a derivative projects from ubiquity. | 15:00 |
| kdeuser56 | xnox: where can I get a list of all working keys? | 15:00 |
| kdeuser56 | xnox: and how is succes command supposed to work? | 15:00 |
| xnox | kdeuser56: i gave you two urls for ubiquity. | 15:00 |
| xnox | <xnox> https://wiki.ubuntu.com/DesktopCDOptions | 15:00 |
| xnox | <xnox> https://wiki.ubuntu.com/UbiquityAutomation | 15:00 |
| kdeuser56 | xnox: yeah, but there are like 5 keys listed ... | 15:01 |
| kdeuser56 | xnox: nobody can work stuff with that | 15:01 |
| kdeuser56 | *get to work | 15:01 |
| xnox | kdeuser56: if you want to use full d-i preseeding, then use a mini.iso and then you can preseed everything that d-i supports. | 15:01 |
| kdeuser56 | xnox: okay, if I understand right now, ubuntu desktop offers nearly no option to automate installs ... | 15:02 |
| xnox | kdeuser56: it offers bare minimal of things that one would want to preseed. and we automate with that: OEM installs, LVM, multiple language installs. | 15:03 |
| kdeuser56 | xnox: almost everything works in the preseed stuff that I linked you, apart from: success_command and ubiquity poweroff ... | 15:04 |
| kdeuser56 | xnox: I already tested that | 15:04 |
| kdeuser56 | xnox: so I find all of that really strange now ... it works although you tell it is not supposed to work? | 15:04 |
| xnox | kdeuser56: please file a bug about poweroff and/or success command not working. | 15:06 |
| mdeslaur | kdeuser56: they work for me | 15:06 |
| xnox | kdeuser56: did you try booting stock cd, and presseeding just those two values on kernel cmd line (not full preseed) | 15:06 |
| mdeslaur | kdeuser56: hold on a sec, I know what you're doing wrong | 15:06 |
| mdeslaur | kdeuser56: try this: ubiquityubiquity/rebootstringtrue | 15:06 |
| mdeslaur | kdeuser56: it's a string, not a bool | 15:06 |
| mdeslaur | kdeuser56: ubiquityubiquity/success_commandstringblahblah.sh | 15:07 |
| mdeslaur | kdeuser56: that's a string too, you forgot the type keyword in your example | 15:07 |
| kdeuser56 | mdeslaur: okay my bad, I screwed up the paste ... | 15:09 |
| kdeuser56 | mdeslaur: the reboot works with boolean too ... | 15:09 |
| kdeuser56 | mdeslaur: only poweroff does not work with boolean | 15:09 |
| kdeuser56 | mdeslaur: I'll try now, with the string, thx for the suggestion | 15:09 |
| mdeslaur | kdeuser56: FYI, this is what I use in one of my scripts: http://bazaar.launchpad.net/~ubuntu-bugcontrol/ubuntu-qa-tools/master/view/head:/vm-tools/uvt#L1971 | 15:10 |
| kdeuser56 | mdeslaur: okay now it gets really messy: when to use uiquity, when d-i, and what about console setup? | 15:12 |
| kdeuser56 | mdeslaur: where do you get the info from? | 15:12 |
| kdeuser56 | mdeslaur: and why does my script work with d-i too apart from the things I mentioned? | 15:13 |
| mdeslaur | kdeuser56: you basically have to look into those packages and see what debconf command they honour | 15:13 |
| mdeslaur | kdeuser56: there's no good list, AFAIK | 15:13 |
| kdeuser56 | mdeslaur: any simple/automated way to that stuff with debconf? | 15:14 |
| kdeuser56 | maybe canonical should have invested in creating a sane new installer than mixing up debian stuff with some in house stuff | 15:15 |
| kdeuser56 | mdeslaur, xnox: but thanks very much anyway for your support | 15:17 |
| mdeslaur | well, debconf is pretty cool as you can preseed everything | 15:17 |
| kdeuser56 | mdeslaur, xnox: sorry for my frustration | 15:17 |
| mdeslaur | it would be nice to get a master list, and I certainly understand your frustration | 15:17 |
| kdeuser56 | mdeslaur: link to some debconf tutorial? | 15:18 |
| mdeslaur | this perhaps? http://www.fifi.org/doc/debconf-doc/tutorial.html | 15:19 |
| kdeuser56 | mdeslaur: so would debconf instead of pressed look like? | 15:20 |
| kdeuser56 | mdeslaur: *how | 15:20 |
| kdeuser56 | mdeslaur: okay, poweroff works as string ... thanks | 15:21 |
| mdeslaur | kdeuser56: that's what preseeding does, it pre-populates debconf | 15:22 |
| mdeslaur | so you can preseed all packages that use debconf | 15:22 |
| mdeslaur | the trick is figuring out how each package uses debconf | 15:22 |
| kdeuser56 | mdeslaur: oh no wrong alert ... I only got a stuck reboot using a prior version of the script | 15:22 |
| === timrc is now known as timrc-afk | ||
| kdeuser56 | mdeslaur: okay, red hats/fedoras kickstart is way superior for sure | 15:23 |
| kdeuser56 | mdeslaur: thats really messy to find that out package wise and a pain to automate | 15:24 |
| mdeslaur | kdeuser56: i disagree...preseeding work with any package, kickstart is only for install | 15:24 |
| kdeuser56 | mdeslaur: might be true, but kickstart does one thing and does it pretty good in a clearly documented way | 15:25 |
| kdeuser56 | mdeslaur: preseed is a real pain already ... maybe I am just too stupid | 15:25 |
| mdeslaur | kdeuser56: breathe in, breathe out :) | 15:26 |
| kdeuser56 | mdeslaur: yeah, thanks very much for now ... I will go out for a while | 15:27 |
| kdeuser56 | mdeslaur: ciao and thanks so much! | 15:27 |
| mdeslaur | np! | 15:27 |
| === timrc-afk is now known as timrc | ||
| barry | mvo: can you point me to the branch/code that solves the coverage problem for you in click w/dbus? i have code that *should* be working according to the coverage.py docs, but it still seems not to collect subproc coverage. i'd love to compare my approach to yours | 15:31 |
| mvo | barry: sure! please check https://code.launchpad.net/~mvo/click/coverage/+merge/221871 | 15:31 |
| mvo | barry: oh, but not w/dbus, we "just" use subprocess calls | 15:32 |
| mvo | barry: if you can point me to your branch I'm happy to check it out | 15:32 |
| barry | mvo: cool, thanks. let me spend a little time reviewing and hacking. i'll send you a branch url when i have something | 15:33 |
| mvo | barry: sure :) | 15:33 |
| slangasek | bdmurray: so should I just ignore the spate of new regressions reported for the unity SRU yesterday? I guess they're all either duplicates or false-positives | 15:34 |
| === Saviq|QtCS is now known as Saviq | ||
| bdmurray | slangasek: I wouldn't ignore the new regressions rather check on them and see if the previous package version appears on the problem page today or tomorrow | 15:37 |
| slangasek | bdmurray: ok | 15:38 |
| slangasek | bdmurray: would it be possible to reset the state for these packages, so that the uploaders don't have to re-poll? | 15:38 |
| slangasek | i.e., clear the list of newly-associated crashes | 15:39 |
| bdmurray | slangasek: I'm not following | 15:39 |
| doko | barry, libreoffice isn't blocking python3.4 migration. tests which did always fail don't block | 15:40 |
| slangasek | bdmurray: the mails I got are because the phased-updater sees these crashes as regressions, and has recorded this somewhere - could we clear all such data that was added in the last day, and let the phased updater check again in 24h? | 15:40 |
| doko | but now openssl triggered a python3.4 autopkg test failure ... | 15:40 |
| barry | doko: oh, now i see that on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html | 15:41 |
| barry | i was only looking at the python3.4 package | 15:41 |
| mvo | doko: could this be https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1329297 ? | 15:42 |
| ubottu | Ubuntu bug 1329297 in openssl (Ubuntu Utopic) "openssl CVE-2014-0224 fix broke tls_session_secret_cb and EAP-FAST" [Undecided,Confirmed] | 15:42 |
| barry | mvo, doko https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-python3.4/lastBuild/ARCH=i386,label=adt/console | 15:42 |
| mdeslaur | grr...what'd I break? | 15:42 |
| barry | looks like a borken test run more than anything else | 15:42 |
| doko | looks like it needs a give back | 15:43 |
| mvo | yeah, something else I think | 15:43 |
| mvo | sorry for the noise | 15:43 |
| mdeslaur | I hate Mr. Hash Sum | 15:43 |
| barry | no worries. i restarted the build - let's see if that helps | 15:43 |
| doko | but everything is now blocked on libffi and some haskell packages using it | 15:43 |
| bdmurray | slangasek: we could override the specific problem by adding it to the phased update overrides branch temporarily and then remove it again | 15:44 |
| * mvo needs to land this by-hash branch to make the update more robust | 15:45 | |
| mvo | *sigh* | 15:45 |
| slangasek | bdmurray: well, I'm not aiming to override it for the specific case of unity, since I'm the uploader there and have a rough idea of what's going on - more interested in the general problem, and any SRUs other people have uploaded that might be affected by this | 15:46 |
| slangasek | bdmurray: but if this is too much work, then nevermind | 15:47 |
| === timrc is now known as timrc-afk | ||
| bdmurray | slangasek: I mean add that problem https://errors.ubuntu.com/problem/4858f7a856a0ceb65b4dfb0ffc48015fc52848a4 to https://bazaar.launchpad.net/~ubuntu-sru/+junk/phased-update-overrides/view/head:/phased-updates-overrides.txt for ~24 hours to allow more crashes to come in (and maybe one about the previous version) and then remove it. | 15:48 |
| slangasek | bdmurray: right, but how would we do that comprehensively, for any other SRUs that have already had their phasing stopped? | 15:50 |
| bdmurray | slangasek: it'd have to be done for each individual problem identified as a regression yesterday. I get cc'ed on all the emails so have a list of those problems. | 15:51 |
| === bschaefer_ is now known as bschaefer | ||
| === s1aden is now known as sladen | ||
| === psivaa is now known as psivaa-afk | ||
| cjwatson | doko: somewhat tempted to override that, as that's waiting for builds that need haskell-http-conduit to be fixed which is blocked on stuff currently in Debian NEW ... | 16:59 |
| cjwatson | yeah, let's do that | 17:00 |
| cjwatson | doko: should migrate next run | 17:01 |
| slangasek | mterry, stgraber, xnox, cjwatson, dbarth, dpm_, mvo: developer track session summaries to http://pad.ubuntu.com/uos-1406-development-summary, please :) | 17:32 |
| stgraber | slangasek: out for lunch (on my phone). I'll write something about system-image for servers when I get back (I think that's the only session I led which was in the dev track, the rest were in devops) | 17:34 |
| dpm | slangasek, cool, thanks. Are you going to present the summary? | 17:34 |
| slangasek | dpm: yes | 17:34 |
| slangasek | stgraber: ok | 17:34 |
| dpm | great, thanks | 17:34 |
| dbarth | slangasek: done | 17:38 |
| xnox | slangasek: added a few bits from things i've been in. | 17:42 |
| kdeuser56 | mdeslaur: I can confirm for sure now, that ubiquity ubiquity/poweroff boolean true is broken ... it does neither work with string instead of boolean | 17:57 |
| mdeslaur | kdeuser56: ok, please file a bug | 17:58 |
| kdeuser56 | but I can't provide debug stuff ... no experience with that | 17:58 |
| kdeuser56 | mdeslaur: I can only write 14.04, poweroff does not work ... | 17:59 |
| kdeuser56 | mdeslaur: I think nobody will care as long as I do not provide the information needed for someone to debug without trying it | 17:59 |
| mdeslaur | write the bug # here, and I'll take a look when I get a minute | 18:00 |
| === timrc-afk is now known as timrc | ||
| kdeuser56 | mdeslaur: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1329417 | 18:25 |
| ubottu | Ubuntu bug 1329417 in ubiquity (Ubuntu) "Ubiquity not powering off with "ubiquity ubiquity/poweroff boolean true" in preseed file " [Undecided,New] | 18:25 |
| === jono is now known as Guest93557 | ||
| === salem_ is now known as _salem | ||
| doko | xnox, libboost-python1.55-dev recommends again libgccxml-dev | 18:44 |
| doko | pitti, jibel: give back https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-lintian/lastBuild/? ? | 18:46 |
| cristian_c | Hi | 19:18 |
| cristian_c | I was testing a wiki guide to enable the EOL repositories | 19:18 |
| cristian_c | apt-get update is working, but apt-get install no | 19:18 |
| cristian_c | I get many 404s not found | 19:19 |
| cristian_c | Investigating, I discovered that EOL repositories are not updated | 19:19 |
| cristian_c | I was suggested to open a bug report for these problems | 19:19 |
| cristian_c | Can you confirm this problem and explain how to open the report in my case? | 19:19 |
| slangasek | Trevinho, bregma: mterry seems to have fallen off IRC, and I don't have a summary of the "Unity8 Desktop Preview" session for the wrap-up; any chnace one of you might be able to add something to the etherpad? http://pad.ubuntu.com/uos-1406-development-summary | 19:20 |
| slangasek | (your names are on the list as attendees, so I'm assuming you know - if not, please redirect me) | 19:20 |
| slangasek | seb128: ^^ or maybe you would be able to say | 19:20 |
| seb128 | slangasek, not much decisions, we did a summary of the goals for the cycle | 19:21 |
| seb128 | "having an iso with unity8 on mir, no xorg, being able to run gtk & qt apps fullscreen, work on session management for unity8" | 19:21 |
| bregma | sounds about right | 19:22 |
| seb128 | "being able to install & run clicks" | 19:22 |
| slangasek | seb128: ok, thanks | 19:22 |
| seb128 | we are going to have an installer, it might not be in the live session | 19:22 |
| seb128 | we are looking at using system-images as well | 19:23 |
| seb128 | </summary> | 19:23 |
| seb128 | slangasek, yw | 19:23 |
| === _salem is now known as salem_ | ||
| === roadmr is now known as roadmr_afk | ||
| jdstrand | slangasek: well, not that it matters, but in section 4.5.1 of the upstart cookbook, step 16 of job lifecycle says "The started(7) event is emitted. For services, when this event completes the main process will now be fully running. If the job refers to a task, it will now have completed (successfully or other‐wise)." | 19:56 |
| jdstrand | istr reading somewhere else that stopped should be used with a task too | 19:57 |
| jdstrand | slangasek: I think we need some expert advice in that bug. what would you (or xnox, or really anyone) suggest for when to start the job, if it should be a task or not (it seems it should be-- it is a discete set of operations) and what lightdm should have (don't have to comment here-- in the bug would be fine) | 19:59 |
| slangasek | jdstrand: isn't that just what I've done? :) You may be right that you'll get a 'started' event when the task finishes, but I prefer to see this done the way /etc/init/network-interface-security.conf is - tasks are more suitable when you want the job to be run multiple times across a system's lifecycle | 20:00 |
| jdstrand | slangasek: hmm, this task could be run at other times-- eg an apparmor upgrade | 20:01 |
| slangasek | oh? | 20:01 |
| jdstrand | slangasek: ok, well, I see mdeslaur is also commenting in the bug, perhaps it should be taken there? | 20:02 |
| slangasek | ok | 20:02 |
| mdeslaur | slangasek, jdstrand: disregard my last comment in that bug, not sure what I was thinking of | 20:13 |
| === roadmr_afk is now known as roadmr | ||
| Chipaca | slangasek: bdmurray: ping about #1328285 | 20:36 |
| Chipaca | that is bug #1328285 | 20:36 |
| ubottu | bug 1328285 in whoopsie (Ubuntu) "can not find hardware address" [High,Triaged] https://launchpad.net/bugs/1328285 | 20:36 |
| Chipaca | thanks ubottu | 20:36 |
| bdmurray | Chipaca: yes? | 20:37 |
| Chipaca | bdmurray: currently whoopsie uses the "first" network interface | 20:37 |
| Chipaca | bdmurray: do you know how that order is determined? | 20:38 |
| Chipaca | to preserve it when looking at /sys/class/net | 20:38 |
| Chipaca | ooooh, ifindex | 20:39 |
| * Chipaca pokes | 20:39 | |
| bdmurray | Chipaca: no, I don't. slangasek or stgraber might | 20:39 |
| Chipaca | there's an ifindex | 20:39 |
| Chipaca | that'll work | 20:39 |
| Chipaca | bdmurray: are you working on that, or would you mind if I picked it up? | 20:39 |
| Chipaca | __lucio__ is going to start shouting at me if the whoopsie id is broken fur much longer | 20:40 |
| Chipaca | for, too | 20:40 |
| Chipaca | maybe that's a slangasek question too ^ | 20:40 |
| michagogo | !info whoopsie | 20:41 |
| ubottu | whoopsie (source: whoopsie): Ubuntu error tracker submission. In component main, is optional. Version 0.2.24.5 (trusty), package size 20 kB, installed size 110 kB | 20:41 |
| slangasek | Chipaca: I hadn't been working on it, it's fine for you to pick it up if bdmurray says so :) | 20:41 |
| slangasek | Chipaca: however, ifindex is fairly useless here too, interface ordering is not stable | 20:42 |
| Chipaca | slangasek: ok, but I want to be just as broken as the current code in that sense | 20:42 |
| Chipaca | not differently broken | 20:42 |
| Chipaca | ev: unless you have different ideas? | 20:43 |
| ev | hi | 20:44 |
| Chipaca | hi. | 20:44 |
| slangasek | Chipaca: but it's not a stable ordering, so it doesn't /matter/ if it's differently broken ;) | 20:44 |
| ev | hm, could we lexicographical sort the non-loopback interfaces? | 20:44 |
| slangasek | Chipaca: I was going to suggest sorting lexically | 20:44 |
| ev | boom | 20:44 |
| bdmurray | Chipaca: I'm not working on it | 20:45 |
| Chipaca | ev: non-loopback, or ethernetty (type 1)? | 20:45 |
| slangasek | Chipaca: the latter | 20:46 |
| Chipaca | ev: sorting lexically will mean you'll get a different whoopsie id if the user brings up an rfcomm0 interface on a wifi-only device | 20:47 |
| slangasek | Chipaca: and you should be able to grab /sys/class/net/$foo/address directly from the fs | 20:47 |
| Chipaca | slangasek: yes; need some fiddlery to filter by type, but yes | 20:48 |
| slangasek | (since you're already rooting around with files, no sense in using completely separate interfaces for querying the ethernet address...) | 20:48 |
| Chipaca | heh, yeah, all that code is going out :) | 20:48 |
| Chipaca | ev: are you bashing you head on the desk still? | 20:49 |
| slangasek | Chipaca: rfcomm0 shouldn't have an ethernet iftype, should it? But regardless, this comes back to the fact that once the system ID is generated it should be stored on the fs | 20:51 |
| Chipaca | it is looking a lot like that, yes | 20:52 |
| ev | I worry about us storing it on the filesystem | 21:29 |
| ev | then we wont get the same identifier from the same system across installs | 21:29 |
| ev | given the amount of unique data in the hardware, there must be a way of calculating a stable signature | 21:30 |
| infinity | ev: How are the two concepts orthogonal? You can calculate it with a deterministic algorithm but still store it on the filesystem so it's not recalculated at every boot. | 21:53 |
| infinity | ev: This also has the advantage that, say, me replacing a piece of hardware in a whitebox system doesn't change my system ID (at least, not until I reinstall). | 21:53 |
| infinity | Ahh, memories of Microsoft Product Activation. | 21:54 |
| === salem_ is now known as _salem | ||
| sarnold | but didn't you feel better knowing you had a genuine product? wasn't that an advantage? | 22:09 |
| slangasek | ev: you currently don't get the same identifier from the same system across /boots/, let alone across installs. At least storing it to the fs, if it's done at a point that should give reproducible results, gives us a chance at having the same id across installs while also ensuring that it's the same across reboots | 22:17 |
| infinity | sarnold: Yes, I felt very priviledged to have to call a hotline every time I installed Windows. | 22:30 |
| sarnold | infinity: a valued customer! | 22:30 |
| Chipaca | xnox: ping | 22:32 |
| infinity | sarnold: I'm not sure I would have minded if the online activation actually worked, but while retail keys usually work fine, MAPS, MSDN, and volume licensing keys are all notorious for not working automatically. | 22:33 |
| infinity | sarnold: Seems like a system designed to annoy the very customers you should be treating as well as possible might be a bit flawed. :P | 22:34 |
| sarnold | infinity: yeah, the music industry didn't really make headway against piracy until getting music legally was easier than getting it illegally; microsoft could have learned from that experience.. | 22:35 |
| infinity | sarnold: Honestly, as much as I'd love to think all our customers share my hippie ideals, I suspect that "It's not a royal pain to obtain and install across thousands of machines" may well be what got us in the position we are today. | 22:38 |
| infinity | sarnold: Not that I mind at all winning on technical merits, but it's painful to then have to turn around and explain what "Free Software" is, and why we care. :P | 22:38 |
| sarnold | infinity: heh, having been held hostage to a closed-source database once at one job was enough for me to care about free software from then on... | 22:39 |
| xnox | Chipaca: hey | 22:44 |
| Chipaca | xnox: so... did you get anywhere thinking about blacklisting macs and/or imeis? | 22:45 |
| xnox | Chipaca: not yet. | 22:49 |
| Chipaca | ev: slangasek: bdmurray: xnox: https://code.launchpad.net/~chipaca/whoopsie/no-moar-siocyadda/+merge/223007 | 22:49 |
| Chipaca | ooh, i should point at the bug | 22:49 |
| * Chipaca fixes | 22:49 | |
| xnox | Chipaca: need to fix duplicates first before blacklisting them. | 22:49 |
| Chipaca | xnox: I'm not entirely sure I understood what you meant | 22:51 |
| Chipaca | but my brain just did the nokia "low battery" sound at me | 22:51 |
| xnox | sarnold: which one was it. | 22:51 |
| Chipaca | so this is where I go to bed | 22:51 |
| xnox | Chipaca: what do you expect?! in a similar state here as well. only had one coffee today as well. | 22:51 |
| xnox | =)))) | 22:52 |
| Chipaca | xnox: I dunno, I thought latvians ran on potato | 22:52 |
| xnox | Chipaca: don't make me go all putin on you, to explain that i'm russian =) | 22:52 |
| xnox | and well british. | 22:52 |
| Chipaca | xnox: :) | 22:52 |
| xnox | I shall post you a letter with my thoughts =) | 22:53 |
| Chipaca | xnox: fwiw i knew that was going to offend you for entirely different reasons than the apparent :) | 22:53 |
| Chipaca | anyway. bed. yes. good. | 22:53 |
| sarnold | xnox: it was a front-end by one vendor on top of informix that ran on an sco unix system without compiler or headers available at a price we could afford... | 22:53 |
| slangasek | Chipaca: you should have called him a Lithuanian for maximum points | 22:54 |
| xnox | sarnold: i think i'm glad that to me SCO stands for Shanghai Cooperation Organisation | 22:55 |
| Chipaca | slangasek: i only wanted to rib him, not start a war | 22:55 |
| xnox | slangasek: that causes one to smile and start explaining geography, very politely, whilst exploding with rage inside. | 22:56 |
| doko | is this the land of draculas? | 22:56 |
| xnox | no we are not talking about east germany =) | 22:57 |
| sarnold | xnox: hah, you're lucky. :) | 22:57 |
| xnox | anyway all of us should be asleep anyway | 22:57 |
| * Chipaca puts down the emacs and steps away | 22:57 | |
| sarnold | too true. it'd be a good afternoon for a nap :) | 22:57 |
| doko | don't know about east germany, Ich bin ein Berliner | 22:58 |
| sarnold | mmm lekker | 22:58 |
| xnox | doko: wunderbar =) | 23:04 |
| infinity | doko: Mmm, doughnuts. | 23:04 |
| doko | no, these are Berliners | 23:04 |
| doko | "Pfannkuchen" | 23:05 |
| doko | xnox, gcc-4.7 4.7.4 uploaded, time to update the android cross toolchains | 23:05 |
| xnox | sarnold: SCO is a funny coupe - represent ~42% of world population, yet their meetings are never reported by G7 members | 23:05 |
| xnox | doko: yeap, will do. and the toolchain-base packages as well, i guess. | 23:06 |
| Unit193 | mdeslaur: https://bugs.launchpad.net/ubuntu/+source/libxml2/+bug/1321869/comments/10 | 23:06 |
| ubottu | Ubuntu bug 1321869 in libxml2 "xmllint 2.9.1+dfsg1-3ubuntu4.1 does not load entities any more" [High,Fix released] | 23:06 |
| doko | xnox, I was waiting for infinity to integrate the cross build changes ... | 23:07 |
| infinity | Surely, if they built a few months ago, they should still build today. | 23:07 |
| xnox | doko: guten nacht, Matthias =) | 23:08 |
| doko | yep, nothing did change within the past two years :-/ | 23:08 |
| === robert_ancell_ is now known as robert_ancell | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!