[00:25] infinity: ping [00:28] balloons: hey! [00:29] balloons: what's up with releasing music app and calendar app? === jackson is now known as Guest1184 === broder_ is now known as broder === balkamos_ is now known as balkamos === yp is now known as ypwong === Chipzz_ is now known as Chipzz === mwhudson is now known as 5EXAAR2RG [01:41] whoa... just noticed today at the vuds there was a discussion on switching to systemd... when the heck did this come about? I see nothing on -devel about this and last time it was brought up everyone said we would be sticking with upstart... and debian just decided to go with upstart, so... wtf? [01:42] ( and I think their decision was based in large part on our viewpoint on the matter ) [01:42] psusi: http://www.markshuttleworth.com/archives/1316 [01:42] debian went with systemd... [01:42] what? I swear I read last week on lwn they went with upstart [01:42] good to know if i ever need a contact from an alternate dimension i have one, tho [01:43] psusi: you didn't :P [01:43] "weekly world news" rather than "linux world news" perhaps? :) [01:44] I swear they kept saying upstart was completely expected because we were dead set on it and half the debian tcce was ubuntu developers and that it finally went that way last week [01:44] I certainly can't find any mention on ubuntu-devel about going this way lately [01:45] the other half of the debian tcce, including the one with the casting vote, didn't go upstart. so, systemd. [01:45] I'm not opposed to it, I actually have felt for some time that it would probably be better to follow what most other distros are doing in that area, but it feels like a total shocking about face [01:45] i expect there wasn't much external discussion ubuntu-side, seems like sabdfl made an executive decision there (which is better than having another argument on this side of the fence would have been imho) [01:45] it's giving me a bit of whiplash [01:45] hehe [01:46] psusi: Well, looking into switching. Possibly by 16.04 if it looks easy, probably in 16.10. :) [01:47] psusi: So, whiplash in ~2 years time or so, perhaps :) [01:47] well, with two whole years until 16.04, I'd hope we could get it done in that time frame ;) [01:47] especially with debian going that route [01:48] is it really that big a deal? [01:48] it requires all system service type packages to be fixed to ship systemd config files instead of upstart, which is what we had to do when we moved to upstart from sysvinit [01:49] haven't other distros done most of the hard work there for us? [01:49] so its been done once, it will be even easier the second time :) [01:49] probably, yea [01:49] i know i've been able to boot with systemd on debian testing for quite a while [01:50] rww: Part of that is that systemd still works with init scripts. [01:50] I've been wanting to play with it for a while now but never got around to it... and the way the devs keep trying to strongarm things like udev into it in an inseperable way, and refusing to support !linux was starting to turn me off [01:50] Unit193: yep. iirc i ended up with surprisingly few of those [01:52] hell, I haven't been paying attention to our initramfs for some time.. did we ever put upstart in there? [01:55] psusi: No. [01:55] it's getting a bit confusing with some form of init now possible in the initramfs, system startup, and session startup ;) [01:55] psusi: And I still think systemd-in-initrd is the wrong thing too, but upstream disagrees. :P [01:56] I'm not so sure... we do have several serious and long standing bugs that could be solved by that [01:56] * psusi looks at degraded md/lvm/crypt/etc [01:56] infinity: how come? [01:57] rww: I'm not fond of the "shove everything in initramfs, it's the new /" mentality. [01:57] Which was the driving force behind the /usr merge. [01:57] it's a brave, new, plug and play world though, and that has not jived well with shell scripts in initramfs [01:57] It entirely discounts systems where you don't want an initrd, systems where loading the initrd is incredibly expensive, so you want to keep it small, etc. [01:58] I thought it handled !initrd systems too === ssweeny` is now known as ssweeny [01:59] psusi: If initramfs is the new /, it only handles non-initrd systems if you use one filesystem. [01:59] (But, yes, that's the most common configuation today) [02:00] And, if you run Fedora, it's the only configuration, cause / is dead. :P [02:00] ohh... yea.. I guess you did used to be able to have enough in / and not /usr to fsck the root fs and *then* initialize the rest of the system... I can't really find a reason to care about that though ;) [02:01] Should also make it take longer to compress the initrd, having dropbear and cryptsetup makes it slow enough as it is. Also, the possibility of breakage... [02:01] psusi: No, and neither can Lennart, and our new overlords believe that if they don't value a use-case, no one should. [02:01] * infinity isn't bitter. [02:01] true [02:02] And thats my gripe. We are a little closer to being controlled more by our overlords. [02:02] I can live with the decision though. [02:02] indeed, that's the one reason why I've been a bit turned off on systemd lately, even though I originally thought his ideas really sounded good [02:02] I think following suit with Debian here is absolutely the right decision. I'm less certain that Debian made the right decision. [02:02] he's a bit too dictatorial [02:03] Yep I feel the same. [02:03] indeed [02:03] psusi: Try having a conversation with him. [02:03] psusi: (don't, if you value your sanity) [02:04] I have the same problem with David Zuthern and udisks [02:04] But udisk isn't trying to eat all of early userspace. [02:04] and all this is making me suspicious of kdbus [02:05] kdbus will solve every problem that ever existed. [02:05] Apparently. [02:05] And, while this is meaningless to Ubuntu, I'm really non-plussed about tying the larger GNU/GNOME/KDE/etc userspace to Linux, which it never had been before. [02:05] it starts with k, so it'll probably be good [02:05] I for one, welcome kdbus if it means better performance. [02:06] Yep agreed, just because I'll likely never use BSD, doesn't mean they should get dropped like a sack of potatoes. [02:06] it sounds great for dbus users... I just don't see why everything has to be done with dbus... the unix way is to run a small, stand alone executable, and the mass push to convert everything to dbus just feels like the way Microsoft puts everything in dlls [02:07] indeed... especially if there are some bsd users that are willing to write and maintain patches to support it, there's no reason to refuse to accept them [02:07] But afaik it has solved security concerns with IPC, but my understanding may be missing the mark. [02:07] psusi: We put everything in DLLs too... [02:07] to be fair, I've heard the opensolaris 10 stuff described as "sun / oracle put all the functionality in libraries" ... [02:08] psusi: In fact, if all of the systemd functionality was in libraries, I'd have very, very few complaints. [02:08] A lot of it is; just private libraries. [02:08] psusi: But instead, they do things like the "single cgroup writer" fiasco in the systemd binary itself, and tell us all the get stuffed. [02:09] RAOF: A library I can't reasonable leverage isn't a library worth discussing. [02:09] Absolutely. [02:09] s/reasonable/reasonably/ [02:09] why use a library when exec works fine? gparted is still quite happy to run mkfs, fsck, etc instead of running libraries in process [02:10] I presume once systemd settles down all those things will end up as real, honest-to-god libraries with actual ABIs and stuff. [02:10] but gnome-disk-utility has to have everything cross the dbus and be run in a server... I dunno... just seems like a lot of unneeded complexity [02:10] RAOF: If history is anything to go by, I doubt it. [02:10] psusi: I'm not particularly fussed about if your coupling method is exec() or ld.so, but I'm a big fan of sane reuse of small components, somehow. [02:11] RAOF: "actual ABIs", I like the optimism... [02:11] true [02:11] RAOF: That seems pretty much completely counter to what Lennart and Kai want, so I doubt it. [02:11] infinity: init will eventually be boring, and the adults can take over :P [02:11] [02:12] Yep, aka how Lennart left pulseaudio development without saying anything. [02:12] it -was- boring, once, when it was just thirty lines long.. [02:13] Yeah, but it was boring and seriously underpowered. There'll come a time when it'll be boring and feature-complete. [02:13] RAOF: Ahh, like Emacs, which never sees any new develop-- oh, wait. [02:13] * psusi just hopes he can finally get debian+ubuntu off of parted 2.3 [02:15] RAOF: Anyhow, init will never be boring as long as systemd keeps finding new bits of userspace to absorb. [02:16] point him at launchpad [02:16] RAOF: When you're linking everything against systemd-libc, using systemd-gcc, spinning up systemd-qemu to try something on another arch with systemd-gdb, maybe it'll be feature-complete. [02:17] lol [02:17] I still say udisks has no buisiness configuring things like drive standby timers, while at the same time being a demand start service [02:19] RAOF: On the plus side, I assume that systemd-wayland becoming inextricably linked will put a rest to this pesky Mir thing. === 5EXAAR2RG is now known as mwhudson_ [02:19] psusi: don't worry, systemd-udisks will fix that [02:19] lol [02:20] one of these days I'm going to fix those broken udisks standby timers, and convert it to use the new kernel runtime pm [02:20] Yeah, please do so! [02:21] probably after I get my kernel patches accepted to avoid spinning up little used disks at all after system resume [02:33] * psusi wonders where lamont has been hiding === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === FourDollars_ is now known as FourDollars === FlannelKing is now known as Flannel [05:15] Good morning === salem_ is now known as _salem === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === bigon_ is now known as bigon === yofel_ is now known as yofel === Guest1184 is now known as Noskcaj === Wellark_ is now known as Wellark === warp10_ is now known as warp10 [09:48] hi, whom do I contact regarding updating the libaccounts-qt package? [09:48] since it seems to be updated by a bot which hasn't updated it in over 4 months [09:55] shadeslayer, try mardy [09:56] mardy: poke poke @ libaccounts-qt package [09:56] mardy: next KDE SC release that we want in Trusty requires libaccounts-qt 1.11 , current package reports version 1.11 but doesn't have a header that's require to build things [09:57] since this is a snapshot of the 1.11 tree, I would argue for an update to the final release [09:59] @pilot in === udevbot changed the topic of #ubuntu-devel to: Trusty Beta 1 released! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: pitti [10:00] morning pitti :D [10:01] hey shadeslayer, how is it going? [10:01] good, packaging a new KDE SC :) [10:02] pitti: how about you [10:02] shadeslayer: quite fine, thanks! enjoying the spring, not enjoying fighting QA infrastructure :) [10:04] * shadeslayer sighs about not being able to enjoy spring from work :( [10:04] pitti: just get loads of coffee and fix it when you get a sugar rush :P [10:04] or caffeine rush, or both [10:05] shadeslayer: I'm not a coffee drinker, but a big enough hammer will do :) [10:08] hah :D [10:33] slangasek: I took the liberty of applying the "isolation-machine" autopkgtest fix for systemd-shim in Debian's collab-maint [10:33] slangasek: so we are back in sync [10:39] Launchpad, where are thou? === dkessel_ is now known as dkessel [11:19] https://apps.ubuntu.com/cat/applications/precise/kipi-plugins/ <-- formatting on this page looks broken [11:20] Missing newlines. [11:47] greetings ubuntu-sponsors [11:47] I'm seeking sponsorship for the following package: [11:47] https://bugs.launchpad.net/ubuntu/+source/light-locker-settings/+bug/1291324 [11:47] Launchpad bug 1291324 in light-locker-settings (Ubuntu) "[needs-packaging] light-locker-settings 1.0.1" [Undecided,Confirmed] [11:47] Please let me know if there are any changes that need to be made [11:50] bluesabre: I'll have a look [11:50] bluesabre: the changes look quite a bit more intrusive than a microrelease update suggests.. [11:50] thanks pitti [11:50] bluesabre: but still okayish, I'll look at the diff [11:51] thanks, functionally its the same, it was a cleanup to be sure [11:56] pitti: Hi Martin! [11:56] hey GunnarHj, how are you? [11:56] pitti: Fine thanks, how about you? [11:56] pitti: See that you are piloting. Any chance that you can take a look at bug #1284701? Laney did a first review at mentors, but he's on holiday this week. [11:56] bug 1284701 in Ubuntu "[FFE] Please upload mythes-sv to the archive" [Medium,In progress] https://launchpad.net/bugs/1284701 [11:56] GunnarHj: great, thanks! just sponsoring your locales patch :) === MacSlow is now known as MacSlow|lunch [11:56] pitti: Aha, thanks. :) [11:56] GunnarHj: yep, it's in the sponsoring queue, I'll get to it [11:57] pitti: Great! [11:59] dholbach: can you handle https://code.launchpad.net/~mitya57/ubuntu-sponsoring/bold-fix-for-new-packages/+merge/208961 ? I think you have a much better idea about this than I [11:59] dholbach: meta-sponsoring FTW! [12:02] shadeslayer: hi! What header is missing? [12:02] pitti, done [12:02] thanks [12:02] dholbach: *hug*, danke [12:02] * dholbach hugs pitti back [12:10] * pitti watches his laptop emitting smoke from all the sbuilding today [12:11] bluesabre: uploaded, thanks! [12:11] pitti, you're the best! :D [12:11] * bluesabre hopes that doesn't offend the other uploaders [12:13] bluesabre: *shrug* if it does, and it leads to them sposoring more, so much the better :-) [12:13] speaking of more, I need more "n"s apparenlty [12:32] Laney: bug 1290823 should be trivial, mind having a look with your release hat on? [12:32] bug 1290823 in Ubuntu "FFe: [needs-packaging] Sync appdata-tools 0.1.7-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1290823 [12:33] Laney: bug 1290291 as well, that looks pretty much "bug fix" to me; but rbasak seems to think it needs release team ack? [12:33] bug 1290291 in cmigemo (Ubuntu) "[FFe] Sync cmigemo 1:1.2+gh0.20140306-1 (universe) from Debian sid (main)" [Wishlist,New] https://launchpad.net/bugs/1290291 [12:36] pitti: ah. I just went with the original subject that said it needed an exception. [12:36] pitti: looking at it now, I guess perhaps it doesn't? [12:37] rbasak: by the description in #5 I would just have synced it === _salem is now known as salem_ [12:46] pitti: agreed. Sorry, I should have paid more attention. === tkamppeter_ is now known as tkamppeter [13:14] mardy: moment, let me check === MacSlow|lunch is now known as MacSlow [13:19] rbasak: no worries, it's far from clear in the bug [13:25] mardy: ../../../../resources/google/../shared/getcredentialsjob.h:27:30: fatal error: SignOn/SessionData: No such file or directory [13:25] #include [13:27] shadeslayer: that comes from libsignon-qt5-dev, not libaccounts-qt5-dev [13:29] uhhhh [13:31] mardy: http://paste.ubuntu.com/7079296/ [13:32] mardy: so it finds signon but can't find that header, weird, apt-file search says it can find it [13:35] shadeslayer: weird, the cflags seem to be correct, I see it's using " -I/usr/include/signon-qt5" [13:35] shadeslayer: possibly unrelated, but I see that that package is mixing qt4 and qt5 libs, which is probably very wrong [13:36] mardy: how so? it's using libsignon-qt-dev [13:36] oh huh [13:37] /usr/include/signon-qt5 does seem very very wrong [13:42] xnox: are you working on any of the still unported apps? i want to work on them, but not step on any branches of yours in progress [13:48] GunnarHj: the licensing of that package is still wrong [13:48] GunnarHj: doc/Info-en.txt only says MIT and nothing else at all anywhere [13:48] GunnarHj: so it can't be CC-BY-SA [13:48] GunnarHj: if it's meant to be, then doc/Info-en.txt needs to be adjusted accordingly [13:51] barry: i still have a few clicks to convert, i didn't look into deb based ones yet. [13:51] barry: there is a tweak/hotfix i'm pushing for gallery-app, cause it's blocking landing phablet-tools. [13:51] xnox: cool. i'll likely pick them off (under FUTURE port/test in the bp) alphabetically. i already have branches in progress for many of them [13:52] xnox: ack [13:52] barry: cool! thanks =) add links ;-) [13:52] xnox: of course! :) [13:52] GunnarHj: replied on mentors [14:10] pitti: the burp sync you sponsored seemed to have incomplete autoreconfage, since it broke ppc64el [14:11] cjwatson: ah thanks, I'll have a look [14:12] single-digit sponsoring queue! http://reqorts.qa.ubuntu.com/reports/sponsoring/index.html [14:25] cjwatson: odd, I thought --with autoreconf would also update config.* [14:25] cjwatson: reuploaded the "with autotools_dev", thanks [14:27] rsalveti: err.. the changelog of https://code.launchpad.net/~boiko/ubuntu/trusty/telepathy-qt5/conf_call_client_side/+merge/210302 is exactly the one in https://launchpad.net/ubuntu/+source/telepathy-qt5/0.9.3-0ubuntu7 [14:28] pitti: mind also joining #ubuntu-touch, we discussed that there [14:28] pitti: but basically boiko forgot to update debian/changelog [14:28] he's doing that now [14:28] rsalveti: ah; so that also needs to be merged with the previous upload then? [14:28] pitti: only if the package is using automake+libtool [14:29] pitti: yeah [14:29] pitti: but there are some cases where the package uses autoconf + AC_CANONICAL_FOO, and in that case config.* is required but isn't updated by autoreconf [14:29] pitti: you might want to combine autoreconf and autotools_dev here [14:29] this is a case when that's sensible [14:29] cjwatson: yes, that's what I did [14:29] ok, cool [14:29] -…………………dh $@ --with autoreconf [14:29] +…………………dh $@ --with autoreconf,autotools_dev [14:30] buidls fine here on amd64 [14:30] and https://launchpad.net/ubuntu/+source/burp/1.3.48-2ubuntu1/+build/5805268 is at "test", so looks good [14:30] pitti: Looks more like the autoreconf isn't hitting subdirectories. [14:30] thanks [14:30] yeah, that could be too [14:31] pitti: The top level configure is rebuilt, relibtoolizes, and config.* updated fine, it's a later subdir that falls over. [14:32] right, so the usual rune for that is something like: [14:32] autoreconf: [14:32] autoreconf -fi [14:32] cd subdir && autoreconf -fi [14:32] infinity: ah, thanks; I relayed that to the Debian maintainer via the sponsoring bug [14:32] override_dh_autoreconf: [14:32] dh_autoreconf debian/rules -- autoreconf === kyleN is now known as kyleN-afk [14:34] Hi [14:35] I'm trying to sort out the build issue on ppc64el of OpenLAP patch i've submitted on LP #1287730 [14:35] Launchpad bug 1287730 in openldap (Ubuntu) "openldap segfault on startup with delta-syncrepl MMR" [Undecided,Fix committed] https://launchpad.net/bugs/1287730 [14:36] (but since I don't have access to ppc64el hardware it's a little complicated :)) [14:36] pitti: you told in the bug that you can test build on such hardware. Have you some time to look on this issue ? [14:37] PierreF: I can do test builds, yes; but I know next to nothing about openldap itself [14:37] PierreF: The openldap/ppc64el build failure is libdb bug, it's in progress. [14:37] oh, nice [14:37] the previous version's tests ran fine, and that patch wasn't really intrusive [14:37] infinity: i. e. we'll just retry the build after a fixed libdb lands? [14:38] pitti: The previous version went fine because the buildd was running a kernel with 4k pages, this build was on a buildd with 64k pages. [14:38] pitti: So, yes, once libdb is fixed, a retry will make it happy. [14:38] infinity: sweet, thanks [14:38] PierreF: *phew* :) [14:38] Good to know :) [14:38] thanks [14:54] pitti: Is the solution to the license issue with mythes-sv to simply state MIT in debian/copyright and disregard what's stated at the web page? [14:54] dholbach: wow, for the first time ever I actually got "done" with the sponsoring queue -- 4 items left which are non-actionable [14:54] holy cow [14:54] * dholbach hugs pitti [14:54] GunnarHj: that's how it appears to me [14:55] you're unstoppable! [14:55] great work! :-D [14:55] thanks :) [14:55] pitti: Ok, will do that. [14:55] pitti: And thanks a bunch for your great sponsoring work! :) === caribou_ is now known as caribou [15:07] slangasek: would have been nice to be able to comment on your blog [15:07] re @ cubox i [15:08] @pilout out [15:08] Error: "pilout" is not a valid command. [15:08] @pilot out === udevbot changed the topic of #ubuntu-devel to: Trusty Beta 1 released! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [15:09] shadeslayer: feedback noted, but I'm not going to install a comment system any time in the foreseeable future :) [15:09] :( [15:09] slangasek: anyway, how does it perform? [15:09] * shadeslayer is on the edge of buying one [15:11] shadeslayer: I'm still working on the "enablement" aspects and haven't measured its performance at all... I don't even get hdmi out with any kernel except the 3.0 BSP kernel, I don't get USB keyboard with *any* kernel even though other people say that works, and I'm only using the SD card so any conclusions about I/O performance would be invalid [15:11] slangasek: the enablement aspect is why I want to buy one :P [15:11] shadeslayer: I know that it's *supposed* to do HD video out quite well, but right now I'm still tinkering :) [15:12] :D [15:12] * shadeslayer is very tempted to order one from the March batch [15:12] s/March/April [15:13] slangasek: how much did it cost you? [15:14] shadeslayer: eh, whatever it says on the website? :) === superm1__ is now known as superm1 [15:14] slangasek: just wanted to compare if there was a change in price when compared with the december batch :P [15:15] I don't think so [15:15] hm, ok, might as well order [15:15] going to use it with owncloud + 4 TB HDD \o/ [15:17] * infinity has too many random ARM things littering his desk already. [15:18] slangasek: does it have drivers for hardware video decoding? [15:18] mdeslaur: it's meant to, but I haven't started chasing that side yet - it's possible they're only available for the 3.0 BSP kernel [15:19] infinity: ah, but this one's small [15:19] slangasek: Most of them are. [15:19] slangasek: Though, small in different directions. [15:33] hi [15:33] i can't boot my machine... i keep getting "The disk drive for /dev/mapper/ubuntu--vg-swap_1 is not ready yet or not present" under plymouth :( [15:33] i installed ubuntu-touch which caused the problem [15:34] on my laptop [15:34] rebooted, causing the problem, removed ubuntu-touch and its dependencies, but still get this error message [15:34] attente: you shouldn't install ubuntu-touch on your laptop, unity8 / unity8-session* packages are the most you may install. [15:35] attente: can you boot into recovery? e.g. press shift, get grub menu, select advanced features, select any kernel with (recovery mode). [15:35] xnox: yeah... i'm realizing that now [15:35] attente, do you have the list of the packages that got included? (e.g /var/log/dpkg.log) [15:37] xnox: i can boot into recovery [15:37] attente: so you should be able to get root shell, and figure out what's wrong. [15:38] attente: you may need to mount/remount things rw. [15:38] initctl: Event failed [15:42] /scripts/local-top/cryptroot: line 1: can't open /dev/mapper/ubuntu--vg-root: no such file [15:47] attente: you don't pass initramfs, so do break=top kernel command line option and figure out why cryptsetup is not mounting your crypt/lvm in the right orders. [15:47] attente: or boot of a live cd & mount target for easier debug. [15:48] attente: if it's problem with initramfs, you should be able to boot older kernel/initramfs combo, if you have any around. [15:49] xnox: seb128: ok, works now, i just ended up purging those packages instead of just removing them [15:49] which ones? [15:50] attente: lvm2 and cryptsetup? [15:50] attente: oh, i wonder if you got initramfs-tools-ubuntu-touch installed, which is a borked up initramfs =) [15:50] If there are packages that break on remove-but-not-purge, that's a bug that needs fixing. [15:50] (borked up for normal desktops) [15:52] seb128: just all of the ubuntu-touch dependencies [15:52] i'm not sure which package caused in specifically... [15:59] attente, ok, good that you got it back working in any case [16:04] awe__: http://git.kernel.org/cgit/network/ofono/ofono.git \o/ [16:06] pitti, did you fix it first ? [16:06] ogra_: I don't have any fix at the moment; but of course I'll send patches for stuff that comes up [16:06] pitti, awesome! bonus points that we both got added to the AUTHORS list! [16:06] ;D [16:07] pitti, much thanks again for your help on this too [16:07] awe__: no worries [16:07] I'll look at dialer-app tomorrow morning (UDS/patch pilot today) [16:07] * pitti watches rbasakTV now [16:07] haha [16:08] does it go "arm ARMARM arm armarmarm ... server" ? [16:10] ogra_: more like cloudvmcloudvmcloudvmcloudvm ... virt! [16:10] heh [16:12] .. [16:14] cjwatson: i'd expect each major qt 5.x release to have something major in it ;-) and it did harm us not moving to 5.1 first. We only started fixing 5.1 issues post 5.1 got released, thus those fixes landed in 5.2 only. [16:14] ditto our 5.2 fixes are landing in 5.3 only. [16:14] cjwatson: ideally, we'd have touch images with 5.3-trunk available under test. [16:15] xnox, ECHAN ? [16:15] :) [16:15] ogra_: yes. [16:45] slangasek, are we expecting https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1160079 fix ? [16:45] Launchpad bug 1160079 in plymouth (Ubuntu) "plymouth aborts in cloud images" [Medium,Confirmed] [16:46] xnox: ^^ did you have a chance to smoke-test plymouth yet? [16:48] slangasek: i didn't test crypt yet. let me do that now. === snatan is now known as sassyn [17:14] hi. is there any chance on getting updated libimobiledevice packages into trusty? the current ones (1.1.5) don't work with iOS7. I built new packages based on the debian/* files in trusty and the current git master of libimobiledevice. They work nicely. How would one go about getting a new version into Ubuntu? The current version is in main and maintained by Debian maintainers. They won't update until there's a new release of libimobiledevice (which is p [17:14] slangasek: looks good, still doesn't fix my problem that my boot.log is incomplete. [17:14] dakira: you got cut off after "(which is p" [17:15] (which is probably never). [17:15] xnox: oh, what's the issue with your boot.log being incomplete? [17:16] slangasek: i believe i did attach 10x of my boot.log's basicallly on my SSD laptop, 7 out of 10times it only has like 3-4 of the last jobs in boot sequence that are started and nothing else. [17:17] xnox: attached where? bug #? [17:17] yeah, trying to find now. [17:17] dakira, you need a ffe, read https://wiki.ubuntu.com/FreezeExceptionProcess for details [17:20] seb128: okay. But the question I ask myself is how would one go about the package. Mine is not up to standards, I just did a git clone, copied over and fixed debian/*, updated the changelog and told dpkg-gensymbols to ignore warnings. [17:21] dakira, do you know if upstream plans to roll a new version or if there are specifics commit we can backport for iOS7 support? [17:22] seb128: a new version is not on the way, i'm not sure if they are releasing at all anymore (there is only some github activity on iOS updates to support new versions). [17:23] seb128: The iOS7 support could probably be tracked to a certain commit. [17:25] slangasek: filed a fresh bug #1291498 [17:25] bug 1291498 in plymouth (Ubuntu) "only partial boot.log is recorded" [Undecided,New] https://launchpad.net/bugs/1291498 [17:25] xnox: thanks [17:25] slangasek: maybe it's expected for one boot.log to be 312 bytes and anothers e.g. 1.5kB === kyleN-afk is now known as kyleN [17:28] seb128: I found the commit: https://github.com/libimobiledevice/libimobiledevice/commit/ec720cc1c30ac3f9b7996575e835565f60ce2b3e [17:28] dakira, that seems non trivial... [17:30] seb128: yup. but the current state of libimobiledevice is completely broken (i.e. iOS7 doesn't work at all). [17:30] seb128: but it is "hardware enablement" iOS users upgrade very aggresively, and thus trusty will not work with iDevices at all without this =/ [17:31] seb128: thus it's even acceptable as an SRU, thus it should be fine for FFe as well. [17:31] well, I'm going to let somebody who owns an iOS device update [17:31] xnox, ^ [17:31] dakira: the news on the homepage figures ios7 should work in 1.1.5 but with some hiccups, which would be resolved in 1.1.6 ... what changed? [17:31] xnox, sure, I'm not arguing against that, I just can't sanity check that commit from a look and I don't own hardware to test [17:32] xnox, would be nice if somebody with access to a device could test... [17:33] tarpman: if your device was ever authenticated and then upgraded to ios7, 1.1.5 does work. If not, you can't get past the "trust this device?" dialog on the phone. [17:35] xnox: so, certainly the plymouth-upstart-bridge job will race the rest of the startup [17:35] dakira: so no luck for anyone who bought a newer device (ie. ios7 included) then [17:35] seb128: here's what I built: https://launchpad.net/~mniess/+archive/libimobiledevice/ [17:37] tarpman: exactly. There is no way to get an iOS7 device working on a fresh Ubuntu install [17:37] slangasek: but plymouth-upstart-bridge should not be "start on (started dbus or runlevel [06])" it should be on "start on startup or runlevel [06]", no?! [17:38] xnox: presumably so - I don't know why it's 'on started dbus', maybe it's trying to use the public upstart socket currently and shouldn't? [17:39] slangasek: i think that's what cjwatson mentioned to me in passing on monday. Let me see if I can fix that up. [17:42] xnox: so currently, plymouth-upstart-bridge talks to the system bus, which explains the listed start condition [17:42] s/talks to the system bus/talks to upstart over the system bus/ [17:56] slangasek: when I wrote plymouth-upstart-bridge, it didn't look as if the private upstart socket was going to be a stable interface, and I felt I shouldn't rely on it [17:56] (arguably I should have put it in upstart rather than plymouth, but that's definitely not worth changing now) [17:56] slangasek: at this point it's probably reasonable to distro-patch to use the private socket, since we're not expecting to have a new interface [17:57] xnox: ^- [17:58] cjwatson: ack. [17:58] seb128: is there anything else I can do about the issue? [17:58] cjwatson: ah, k. I wasn't aware that there was ever expected to be a difference between the public and private sockets, other than the root-only / depends-on-dbus-daemon aspects [17:59] it was a private API and I was being a good boy :-) [18:00] dakira, open a bug on launchpad, add the link to your work/the upstream patch, subscribe ubuntu-sponsors [18:07] seb128: There is this. https://launchpad.net/bugs/1207812 [18:07] Launchpad bug 1207812 in libimobiledevice (Ubuntu) "iOS 7, Trust Prompt Looping" [Medium,Triaged] [18:07] seb128: should I create a new bug? [18:08] dakira, no, use that one [18:12] seb128: okay done, thank you. === cody-somerville_ is now known as cody-somerville [19:01] cjwatson: slangasek: 1 file changed, 10 insertions(+), 129 deletions(-) -> and it seems to use upstart private socket now bypassing dbus system bus, but that's with plymouth-x11. [19:01] let me test this actually works =)))) [19:24] cjwatson: slangasek: please review/test https://code.launchpad.net/~xnox/ubuntu/trusty/plymouth/private-upstart-socket/+merge/210672 [19:24] cjwatson: slangasek: mostly it simply opesn private connection, and kicks off statemachine with listing jobs, without registering any filters/rules/nameowerchanges, since org.freedesktop.dbus interface is not there and none of those are needed. [19:25] i now get a 6.2kB boot.log starting with "mounting filesystems" =)))) [19:25] heywow [19:26] xnox: I don't have time to test it today; maybe stgraber and smoser can give it a whirl? [19:28] xnox, interesting. so it turns out that i would never have known i was missing boot.log or data in it. [19:28] well, we were missing data in it because of bug 1160079 [19:28] bug 1160079 in plymouth (Ubuntu) "plymouth aborts in cloud images" [Medium,Confirmed] https://launchpad.net/bugs/1160079 [19:28] which i REALLY want fixed. [19:31] smoser: well lp:ubuntu/upstart has a staged fix for bug 1160079 [19:31] bug 1160079 in plymouth (Ubuntu) "plymouth aborts in cloud images" [Medium,Confirmed] https://launchpad.net/bugs/1160079 [19:31] smoser: and now i will be collecting boot.log, even if dbus is not installed. [19:32] smoser: with my merge proposal. [19:32] smoser: so, can you test lp:~xnox/ubuntu/trusty/plymouth/private-upstart-socket ? it should fix bug 1160079 _and_ create a useful boot.log. [19:32] bug 1160079 in plymouth (Ubuntu) "plymouth aborts in cloud images" [Medium,Confirmed] https://launchpad.net/bugs/1160079 [19:33] :) [19:33] i see what you did there. [19:33] tricky [19:33] xnox, yeah, i'll give it a go === FJKong is now known as FJKong_afk [20:04] dholbach: mhall119: sergiusens: running $ webbrowser-app --help; coredumps. Running $ webapp-container -h; also coredumps. [20:05] xnox, interesting [20:05] xnox, but you pinged the wrong people ;) bfiller ^^ [20:06] dbarth: ^ ?! [20:06] xnox: I think a fix for that just was proposed [20:07] bfiller: a manpage would be good, explaining all the options. [20:07] bfiller: since e.g. http://developer.ubuntu.com/publish/webapp/packaging-web-apps/ is incomplete. [20:07] bfiller: g+ can use _any_ url hypothetically, due to redirects for 3rd party authentication. [20:07] xnox: https://code.launchpad.net/~osomon/webbrowser-app/fix-crash-help/+merge/210655 [20:08] xnox, yeah, that's why I mentioned to avoid the containment [20:09]