[00:00] jtaylor: To be fair, the s390x ABI break (and a SuperH ABI break I need to commit) was widely discussed, and everyone went into it with eyes wide open. [00:00] jtaylor: It would never happen on x86, because there's zero chance of getting everyone to recompile everything. [00:00] that's the best way t oget a gnat in your eye [00:00] yeah, I guess if debian wouldn't test s390x no one would have noticed [00:00] or cared [00:00] yeah but debian is insane [00:00] they even have an x86-freebsd distro now [00:01] I often think Debian builds for architectures just for the hell of it [00:01] this topic is somewhat offtopic for this channel though [00:02] yeah I was just trying to probe a simple question [00:03] it always turns into a huge philosophical debate when I do that [00:18] hallyn_: I'm no expert, but I expect that adding a patch to debian/patches/README instead of debian/patches/series probably won't apply it? [00:20] hallyn_: Oh, nevermind, it's simple-patchsys. Ew. === _salem is now known as salem_ === salem_ is now known as _salem === Spr0cket- is now known as Spr0cket [01:33] infinity: :) === Malsasa_ is now known as Malsasa === Malsasa_ is now known as Malsasa [05:10] dobey: I'd say MIR, not a high maintenance package with purely language pack like content === Malsasa is now known as Guest94873 === Malsasa_ is now known as Malsasa [06:00] Good morning [06:01] Howdy. [06:02] hey Unit193, how are you? thanks for confirming [06:03] pitti: Sure. Only seen the random "session out of sync" issue (can't reboot, suspend, poweroff, etc.) and some strange bug on upgrade that unmutes and sets the volume to 90%, but otherwise smooth sailing. [06:11] Unit193: but the logind one should be fixed now, right? [06:11] volume> that's nothing that the init systemd touches, I'm afraid [06:13] Haven't seen it within the past week or two. And figured it might be systemd/logind as it seemed to hit only with systemd upgrades, but no matter. [06:39] smoser, utlemming: oh, cloud images switched to systemd already? there are some "unable to connect to upstart" messages, and they hang now; is that from https://launchpad.net/ubuntu/+source/cloud-init/0.7.7~bzr1072-0ubuntu1 or was the init system changed in the image build process? [06:40] ah, they are timing out trying to talk to 169.254.169.254 [06:41] hm, odd, http://cloud-images.ubuntu.com/vivid/current/vivid-server-cloudimg-amd64.manifest shows that it has upstart, and no systemd-sysv; but the output is definitively systemd [06:42] ah, init=/lib/systemd/systemd [06:52] filed bug 1427999 to track this [06:52] bug 1427999 in cloud-init (Ubuntu) "cloud images don't boot with systemd" [Undecided,New] https://launchpad.net/bugs/1427999 [07:02] Hey, anyone feel like giving a second-opinion on https://code.launchpad.net/~afrantzis/mir/automate-package-abi-versioning/+merge/251442 ? [07:03] I'm uncomfortable with the extent of debian/control generation, and it's location, but maybe other people are more sanguine :) === marcusto_ is now known as marcustomlinson [07:47] good morning [08:27] cjwatson: could I pick your brain about seed handling? (bug 1428026) [08:27] bug 1428026 in ubuntu-touch-meta (Ubuntu Vivid) "fork required/minimal seed to keep upstart as init system" [Undecided,New] https://launchpad.net/bugs/1428026 [08:33] cjwatson: i. e. do I need to copy required (for keeping upstart) and minimal (no actual change) to ubuntu-touch.vivid as {required,minimal}-touch, and adjust STRUCTURE accordingly, or is there an easier way? [08:33] also, I'm not sure whether we shoudl actually build an ubuntu-minimal-touch package; we could just fold everything into ubuntu-sdk and ubuntu-touch, as on touch you can't individually uninstall/upgrade them anyway [08:34] ogra_: ^ do you have an opinion on this? or "I don't care"? [08:40] pitti, as long as we dont regress in any way and as long as the new way is slightly documented (with a mail or so) i'm in the "don't care" dept. [08:41] it is not like minimal changes a lot [08:41] ogra_: ack, thanks; I'm leaning towards the "put all dependendies into ubuntu-touch", I don't see much value in having an ubuntu-touch-minimal binary metapackage [08:42] (as soon as I figure out how to do either solution.. :) ) [08:42] right, just make it a clear section in the seed file [08:43] you might want to check with the SDK guys, not sure if they need minimal in their builder chroots (i dont know how the SDK creates them) [08:43] ogra_: how do you mean? add a comment to it that says that the only difference should be upstart vs. systemd-sysv? [08:43] ack [08:43] pitti, no add a caption at the bottom "minimal" or some such ... [08:44] ogra_, cjwatsonL [08:44] erk [08:44] ogra_, cjwatson: http://paste.ubuntu.com/10524629/ is my first attempt, but that's apparently not sufficient yet [08:44] and add them below ... i.e. dont merge them alphabetically in the other sections in the touch seed or some such :) === Malsasa_ is now known as Malsasa [08:45] ogra_: oh, I didn't move them around (see pastebin); I don't know whether the order matters, but I'm fine with reordering them [08:46] (I just don't understand what you mean) [08:46] * pitti <- seed n00b [08:46] pitti, ah, i thought you would just add them to the "touch" file [08:47] ogra_: hm, wouldn't that make them harder to maintain? I thought in STRUCTURE I could just add the "dependency" [08:47] though i see that would break sdk-libs [08:47] and I don't wnat to copy them into both sdk-libs and touch [08:47] yeah, i didnt know there were other "required" deps === doko_ is now known as doko [09:11] jamespage, zul: libvirt-daemon isn't packaged in libvirt. looks like the package was never merged [09:20] tjaalton, you synced freeipa, now ftbfs on powerpc and ppc64el, stuck in -proposed [09:20] pitti: Where/how are you booting those cloud images? [09:21] Odd_Bloke: locally in QEMU (adt-buildvm-ubuntu-cloud) [09:21] Odd_Bloke: i. e. with a local seed .iso image [09:22] doko: ok, I'll have a look [09:24] cjwatson: my current progress is in https://bugs.launchpad.net/ubuntu/+source/ubuntu-touch-meta/+bug/1428026/comments/1 but I'm afraid now I really need your help [09:24] Launchpad bug 1428026 in ubuntu-touch-meta (Ubuntu Vivid) "fork required/minimal seed to keep upstart as init system" [Undecided,New] === greyback_ is now known as greyback [09:32] tbb: you synced tbb, now ftbfs on arm64, powerpc, ppc64el [09:35] Logan: you synced tbb, now ftbfs on arm64, powerpc, ppc64el [09:36] pitti: Aren't we going to have terrible problems getting debootstrap to do the right thing during image builds? [09:36] cjwatson: yeah, that would have been my next question -- how does ubunut-minimal actually land on images, given that it's not a dependency of anything [09:37] debootstrap doesn't install ubuntu-minimal, or does it? it's priority: important, not required [09:37] debootstrap installs Priority: important stuff, unless you take special measures to tell it not to. [09:37] I would have assumed that ubuntu-minimal is hardcoded somewhere in the touch image build process, and it would need to change to ubuntu-minimal-touch [09:37] ah, so that's how it gets there [09:37] Avoiding ubuntu-minimal is Really Hard. [09:38] I mean, as it happens, the touch build process does hardcode ubuntu-minimal (in livecd-rootfs) [09:38] But I'm fairly sure it's there already by the time that takes effect ... would have to check build logs [09:42] cjwatson: aye, confirmed that debootstrap pulls in ubuntu-minimal [09:43] cjwatson: that might explain why "init" is required/essential in Debian, but systemd-sysv or sysvinit-core aren't [09:44] pitti: I will have to think about this; how to express it in the seeds is a secondary concern [09:44] cjwatson: do alternatives work in seeds, i. e. could we change ubuntu-minimal to "systemd-sysv | upstart" and explicitly seed upstart in ubunut-touch? [09:44] pitti: Well, Essential isn't transitive, but required is [09:44] pitti: No [09:45] pitti: We could manually hack the ubuntu-meta source package to express that, but I'd prefer to explore other options first [09:45] then as a third option we could replace upstart with "init" in ubuntu-minimal, and seed upstart in touch? [09:45] and promote init to main and to required [09:45] pitti: That might work, but will still require the build process to remove systemd-sysv when installing upstart, which it may not be willing to do === kickinz1|afk is now known as kickinz1 [09:46] pitti: systemd-sysv is functionally Priority: required in Debian according to debootstrap, even if the overrides don't say that [09:46] *nod* [09:47] That's just a lazy ftpmaster bug :) [09:47] I'm fixing a Universe package that is synced from debian. Should I remove debian's Uploader: field in the control file and only leave the XSBC-Original-Maintainer ? [09:47] caribou: Just run update-maintainer [09:47] (which leaves Uploaders alone) [09:47] cjwatson: hmm thanks; didn't know about this one [09:48] didrocks, doko, grilo-plugins-extra should stay in universe, just -base is getting promoted to main [09:48] pitti: The third option will potentially leave germinate a bit confused, but it *might* not matter [09:49] * pitti sends a summary to the bug [09:50] cjwatson: so it seems the main thing to test is whether the image build process gets along with replacing systemd-sysv with upstart; can this be tested locally somehow? [09:53] pitti: It can with some effort, but I'm still caffeinating and thinking about this [09:54] cjwatson: woudl it help if I put the ubuntu-minimal upstart->init and adding "upstart" to ubuntu-touch changes in a PPA? [09:55] (we also need to seed systemd-sysv on ubuntu-standard then, so that we actually get this on upgrades; but I'll test that myself) [09:55] pitti: Not really [09:55] Too many variables confounding the test when PPAs are involved [09:55] (At least at that level) [09:59] pitti: Did you decide against using the "init" package to mirror the Debian setup? [10:00] infinity: we haven't really done any decision wrt. "init"; just mostly ignored it so far [10:00] I think, at least, having ubuntu-minimal depend on init is a good idea at minimum for this, because it will mean we don't have to remove ubuntu-minimal to make ubuntu-touch work. [10:00] Oh, I see, the touch/non-touch split makes it a Very Bad Idea to make anything Essential. [10:01] init doesn't have to be Essential, just used as indirection from ubuntu-minimal. [10:01] infinity: we merely updated its dependencies to reflect ubuntu's init systems (no sysvinit, upstart the defualt), but even the package description is still wrong :) [10:01] Although it wouldn't hurt *this* part of it if it were. [10:01] cjwatson: Well, init as Essential (which it is in Debian), and then dropping all but the systemd dep seemed like a simple way to force the issue on upgrade. But that's not what touch wants, so that wouldn't work. [10:01] Both touch and non-touch would have init, just its dependencies satisfied in a different way. [10:01] at least it needs to be in main, and at the same time we coudl also fix its priority? [10:02] Its priority will be (semi-)magically fixed after it's seeded in the place we want. [10:02] infinity: right, hence my other idea of adding systemd-sysv to ubuntu-standard [10:02] (standard isn't on touch) [10:02] pitti: I guess if we take the view that any system without standard installed isn't ubuntu proper, and thus we don't care if upgrades do the switch...\ [10:02] I tested upgrade with upstart -> systemd in ubuntu-minimal (in a PPA); I expect it to work the same way with init+systemd-sysv in standard, but of course I'll test that again [10:03] standard is an option, but I'm a bit wary of having to chase up other debootstrapped environments that historically expect an init. [10:03] cjwatson: init as Essential fixes debootstrap. [10:03] cjwatson: The standard dep is just how pitti proposes forcing the switch. [10:03] infinity: Sure, in which case it would also be in ubuntu-minimal. [10:03] yeah, with "init" it would have some init === kickinz1 is now known as kickinz1|afk [10:03] infinity: Oh, umm, pretty sure germinate-update-metapackage would filter that [10:04] It'd have to be written manually in ubuntu-meta/debian/control [10:04] That's not rocket surgery. [10:04] so ubuntu-minimal is on touch+desktop+server and has "init", ubuntu-standard is not on touch and has systemd-sysv, ubuntu-touch has upstart === kickinz1|afk is now known as kickinz1 [10:04] And could be dropped post-16.04 [10:04] cjwatson: you mean it would filter out an explicit upstart or sytemd-sysv seed? [10:05] Yeah, because it won't include stuff that's already effectively in inner seeds [10:05] But as I say it can be written by hand [10:05] ah, so that wouldn't affect -touch, but -standard, I see [10:05] Probably both actually [10:05] pitti: So as I read it that leaves two questions: (1) is that enough to fix upgrades, (2) will the touch build process work with this scheme [10:06] as upstart isn't in the "inner seed" [10:06] Er, yeah, you're right [10:06] cjwatson: right; I'm happy to test (1), that's easy; I'm not sure how to test (2) without actually having it in the archive [10:06] for (1) I'm going to prepare a PPA, but you said that doesn't help with (2) [10:06] I can test (2) [10:06] It only needs testing that the relevant apt-get line DTRT [10:06] we need to promote init to main for that, right? [10:07] I can set it up by hand [10:07] But for actually implementing this, yeah [10:07] * pitti promotes it, should be harmless [10:07] ... he says, before triggering an apt bug. [10:07] at worst the next archive admin will demote it again in a few days, if we don't update the seeds by then? [10:07] mvo_: Did we ever hunt down that weird apt bug that seemed to cause a massive sad on upgrades when the required/essential sets changed? [10:08] infinity: is that just your usual optimistic self, or do you actually know an apt bug that gets triggered by thaht? [10:08] eek [10:08] well, promoting to main doesn't change hte optional priority yet, that'll just appear in priority-mismatches.txt [10:14] infinity: I'm not sure, do you have a example issue? if so I can have a look [10:16] mvo_: We had examples long ago. Remember it happened when I made util-linux depend on initscripts to force initscripts into the Essential set, and the world exploded? [10:17] mvo_: And we had to back that out a day or two before release. [10:18] mvo_: I think you set up reproduction environments at the time and such, but then probably got sidetracked with Other Things and stopped being my whipping boy. :P [10:19] tseliot: good morning! [10:19] pitti: good morning to you [10:19] tseliot: FYI, the nvidia-304 regression with the new kernel is tracked in bug 1427924 now [10:19] bug 1427924 in nvidia-graphics-drivers-304-updates (Ubuntu) "autopkgtest failures if nvidia dkms module fails to build" [High,Triaged] https://launchpad.net/bugs/1427924 [10:19] mvo_: Annoyingly, it didn't break on small-scale upgrades (like buildd chroots or minimal schroots), but apt shot itself in the head doing desktop upgrades after the Essential set changed. [10:20] pitti: good, as I'm going to fix it today [10:20] infinity: I think that particular one got fixed, but I need to dig into the logs, there was one issue right before 14.04 that sounds a lot like this [10:20] tseliot: I'm not sure whether we should drop the tests from u-d-common, given that they are useful to spot these (I do agree they run at the wrong time) === iahmad_ is now known as iahmad [10:20] mvo_: But maaaaybe this was actually a weird side-effect of the "command line too short, breaking loop detection" bug, which you fixed, right? [10:21] pitti: I think we should keep them. As - somehow - I didn't catch the failure in my chroot [10:21] mvo_: Seems plausible, given that small upgrades worked, but large ones broke. [10:21] pitti: I've just read slangasek's comment though [10:24] pitti: OK, I can't be absolutely certain as there's some probably-unrelated confusion here with packagekit, but it looks OK to me, once I hit it only slightly harder it's happy to remove systemd-sysv [10:24] cjwatson, infinity: https://launchpad.net/~pitti/+archive/ubuntu/systemd has the above changes now (seeding init in minimal, adding systemd-sysv to ubuntu-standard, adding upstart to ubuntu-touch) [10:24] let's try your PPA to see [10:24] * pitti tests upgrades from trusty and utopic now [10:25] infinity: I think 2f58969150b0daec1de407f61385ccf5b2065aa3 was a fix for the preconfigure issue, the ordering code was buggy, I'm not sure if I ever tried this with the old bug we had back in the day [10:25] pitti: Hmm, I still seem to have to say "apt-get install ubuntu-touch upstart packagekit" [10:26] It's not happy with just ubuntu-touch on its own [10:26] http://paste.ubuntu.com/10525402/ [10:26] cjwatson: that's in which environment now? [10:26] debootstrap [10:27] mvo_: Am I just dreaming, or didn't you also crank up DPkg::Max{Bytes,Args} too, to fix some "upgrading lots of packages causes bad breaks in loops" issues? [10:27] ah; my last test just directly changed the ubuntu-minimal dep, and apt was happy enough to replace the package (after fixing ureadahead) [10:27] debootstrap vivid, install systemd-sysv, then upgrade to your PPA and put ubuntu-minimal back, then try to install ubuntu-touch [10:27] However, the worst case from this is that we have to hack livecd-rootfs a little bit, it isn't actually awful [10:27] cjwatson: that's not just because init is still in universe? [10:27] pitti: No I forced that [10:27] pitti: the reverse dependencies test makes a lot of sense to me [10:27] installed init [10:28] pitti: Still, I think this plan is the closest we're likely to get to a right answer, and it's mostly trivial to implement in seeds [10:28] cjwatson: "apt-get install ubuntu-touch systemd-sysv-" would probably be more elegant, to preserve apt's manual/auto ideas. [10:28] infinity: Yeah, true [10:28] infinity: Still something odd with packagekit, I don't understand that [10:28] I get http://paste.ubuntu.com/10525435/ on apt-get dist-upgrade from trusty and utopic, to vivid+PPA; looks okay [10:30] pitti: Note that do-release-upgrade isn't apt-get dist-upgrade, so might behave slightly differently. [10:30] infinity: yeah, I'll check that next; but plain dist-upgrade also ought to work [10:30] But given that it tries hard to make sure metapackages stay installed, it's likely going to get the right result. [10:31] pitti: I agree, dist-upgrade should work. [10:32] ok, so I debootstapped vivid, added universe and PPA, upgraded (installed init and new ubuntu-minimal) [10:32] indeed apt-get install ubuntu-touch now fails on packagekit [10:33] pitti: And "apt-get install ubuntu-touch systemd-sysv-"? [10:33] Yeah same [10:33] http://paste.ubuntu.com/10525468/ from earlier [10:33] (ok, upstart vs. systemd-sysv-, but should be the same for this purpose) [10:34] https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972 -- seems fixed, when will it make it into libexo-helpers on the repos? [10:34] Launchpad bug 1425972 in exo (Ubuntu) "Firefox no longer supports -remote parameter" [Medium,Confirmed] [10:34] cjwatson: Not necessarily. [10:34] also, will it be on Precise as well? [10:34] I get some more issues with other packages, but likely just follow-ups of upstart: http://paste.ubuntu.com/10525469/ [10:34] infinity: it had the same end effect. I'll get problem resolver output once I've rebootstrapped [10:35] pitti: Yeah those are all consequences [10:35] pitti: Add systemd-sysv- and then it works [10:35] confirmed [10:35] so we need another package to depend on upstart, to bump its scores, or so? [10:36] pitti: 10:27 However, the worst case from this is that we have to hack livecd-rootfs a little bit, it isn't actually awful [10:36] yeah, I saw that, I was just wondering if there's a better way [10:36] I would actively prefer that over fragile score guesswork [10:37] ah, initramfs-tools-ubuntu-touch and others also depend on upstart, so it should already have plenty of dependencies [10:38] So http://paste.ubuntu.com/10525503/ [10:38] cjwatson: but all in all this looks more promising than trying to split ubuntu-minimal{,-touch}, WDYT? [10:38] I completely agree [10:39] These are comparatively minor issues [10:40] ok, so AFAICS we can add the upstart seed to -touch and change the minimal seed to "init" right now, and they should be no-ops (except for getting the additional empty "init" metapackage) [10:40] Yeah [10:40] and the live-build change too, as long as systemd-sysv isn't actually installed [10:40] then the flip woudl just be to upload init with switched dependencies, and add it to ubuntu-standard [10:41] and -touch would be prepared to keep upstart [10:41] livecd-rootfs but yes [10:41] Yep [10:41] agreed, sounds like a plan [10:42] cjwatson, infinity: many thanks for your help! [10:44] cjwatson: OOI, is there a syntax for purge? with - it'll get removed, but not purged, right? [10:46] mvo_: ^ [10:46] mvo_: i. e. "apt-get install foo-" removes foo, is there a "purge foo"? [10:46] pitti: Not AFAIK, but doesn't matter in this case since systemd-sysv has no postrm. [10:46] So remove == purge [10:46] ok [10:46] Though apt-get --purge install foo- works [10:47] But passing that through live-build is probably a pain [10:47] it's no big deal anyway, I just wondered [10:51] pitti: what cjwatson said, if you need a real purge via "pkgname-" I can do that too [10:52] pitti: but early lunch first :) [10:52] mvo_: ack, thanks [10:52] mvo_: nah, not a biggie; --purge is fine [10:56] * sil2100 silently pokes didrocks regarding a certain endorsement request [10:56] ;) [10:56] apw: hey, I have some questions on name_to_handle_at vs overlayfs. I see that it's supposed to be supported (from http://goo.gl/OJoowv), but when I'm using a simple example (like the one on the manpage) on our livecd, I'm getting errno == EOVERFLOW, any idea? [10:57] sil2100: oh, mind if that waits on Friday? Sorry about the delay [10:57] sil2100, you mean he's as bad a slacker as i am ? [10:57] that cant be ! [10:57] didrocks: no worries, any time in the nearest few weeks is fine [10:57] good :) [10:57] ;) [10:57] ogra_: uh oh! [10:57] I'm just kindly poking, no haste ;) [10:58] heh [10:59] ogra_: no one is as bad a slacker as you dude ;) [10:59] hmm, probably true :) [11:00] cjwatson: ./update says "? Unknown required package: init" (http://paste.ubuntu.com/10525662/), seems we need to adjust the priority beforehand? [11:00] didrocks, what code is using that call, as i expect it to be handled by the underlying fs [11:00] ogra_: if it isn't a device you don't care about it. Maybe if they made it snappy, you'd write his review to test that the snap worked, maybe that is the way round it ;) [11:00] cjwatson: ah no, perhaps the mirror is just slightly out of date wrt. the promotion to main; http://archive.ubuntu.com/ubuntu/pool/main/i/init-system-helpers/ is fine, but I'll try a bit later [11:00] davmor2, lol [11:01] pitti: Yeah, that's about presence not priority [11:01] apw: I just tried t_name_to_handle_at.c from man name_to_handle_at [11:02] apw: context is, tracking a systemd issue when it detects all individual files as mount point in systemd code when used over overlayfs, I'm using that code as the source of this issue ^ [11:06] didrocks, it seems to be returning ENOSUPP for me [11:06] didrocks, on overlayfs, not EOVERFLOW [11:07] apw: sorry, you're right, it's just that it returns -1 as expected [11:07] didrocks, well it failed, as expected [11:08] apw: so, I guess this is expected that overlayfs doesn't support it [11:08] hum, I wonder how I can detect if a file is a mount point (meaning, I guess, in that context, being overridden) [11:08] apw: the systemd logic is to test a path, test the parent path, and check mount_id [11:09] the fallback is using stat() [11:09] and comparing st_dev [11:10] which sounds ok ? [11:10] oh perhaps not if the path is a file and the parent a directory [11:11] apw: yeah, that exactly what happens here, path is file, parent a dir [11:11] its not clear that name_to_handle_at would work any better if it did work of course [11:11] this seems like an odd way to work out what is a mountpoint to me, then again it is systemd [11:12] apw: I'm not debating how it is working ;) but yeah, tracking down a crash due to this [11:13] ScottK, Riddell: https://projects.kde.org/projects/playground/libs/libqinfinity/repository libqinfinity needs an update for the new libinfinity in proposed. are there official tarballs available, or should a snapshot be packaged? [11:15] xnox: ah, apparenlty we have some hardcoded dbus-daemon paths (http://d-jenkins.ubuntu-ci:8080/view/Vivid/view/AutoPkgTest/job/vivid-adt-notify-osd/38/ARCH=amd64,label=adt/console), I'll look [11:15] didrocks, i am unsure if we have any good way to detect this right now ? [11:16] I would need a sponsor for openafs-modules-dkms on Trusty : it no longer build following a kernel struct change [11:16] pitti: i know, uploaded at-spi2-core [11:16] pitti: once that's rebuild, notify-osd test will need a rerun. [11:16] the bug seems to be impacting many people [11:16] xnox: ah, yay you [11:17] apw: just run a test, and I confirm that st_dev is different if path == file from parent == dir. [11:18] apw: hum, yeah, seems tricky to even think of a workaround… [11:18] the easiest way would be to take another file (if any) into the same dir, but doesn't seem efficient… [11:18] doko: what's the new version of libinfinity it needs to work with? [11:19] Riddell, 0.6.5 [11:19] apw: the fact that major = 0 will only be return by dirs on overlays or am I on crack? [11:20] no, tmpfs would as well… [11:20] slangasek: hm, you test-forced http://d-jenkins.ubuntu-ci:8080/view/Vivid/view/AutoPkgTest/job/vivid-adt-libtest-requiresinternet-perl/ although the history makes it pretty clear that this is not just a random failure [11:20] apw: maybe the openafs sponsoring should be looked at by someone from the kernel team; it's a dkms build failure [11:21] the uninstallables caused by the perl upgrade still hold it in -proposed, but otherwise it would go in [11:21] . [11:21] caribou, oh goody [11:22] apw: https://bugs.launchpad.net/bugs/1423151 [11:22] Launchpad bug 1423151 in openafs (Ubuntu Trusty) "openafs-modules-dkms 1.6.7-1: openafs kernel module failed to build" [Medium,In progress] [11:22] apw: main part of the patch is one single commit, but I had to bring in two #defines so it would build [11:23] doko: there's no new releases, do you know if it compiles with git snapshot? why is this being updated after FF? it's only used by an experimental plugin so qinfinity can be removed if it has to be [11:23] pitti: see the commit message in hints https://code.launchpad.net/~ubuntu-release/britney/hints-ubuntu [11:24] 910. By Steve Langasek 6 hours ago [11:24] Override failures from libtest-requiresinternet-perl; discovering that you [11:24] have no Internet is a perfectly valid test result from a module whose [11:24] purpose is *to detect whether or not you have Internet*. [11:24] pitti: i'm subscribed to that branch =) very useful stuff to get notified about. [11:25] xnox, slangasek: well, something is still wrong; the same package/test succeeds for me locally on vivid (in teh schroot runner), and fails on vivid-proposed [11:25] doko: upstream says.. 11:25 < scummos> Riddell: it has been a while but I think I ported it to 0.6, but did not release it yet [11:25] 11:25 < scummos> libqinfinity-0.5 does not work with 0.6.5 [11:26] Riddell, it was uploaded on 2015-01-22, way before feature freeze. I can't help if you guys don't address things in -proposed ... [11:26] xnox, slangasek: sorry, it fails in both, but it both cases the test does have internet.. [11:27] doko: I asked about a git snapshot 11:26 < scummos> Riddell: if that is possible for you, yes, and I will try to get a release for 0.6 some day [11:27] xnox: I'll ignore the upstart failure for dbus; that's not the new dbus' fault [11:30] cjwatson: oh, is this alright? minimal/i386: Skipping package init (package not in debootstrap) [11:31] pitti: at-spi2-core seems to be in, can you re-queue notify-osd test (unless you already have, I only see "public" jenkins) [11:31] cjwatson: the pacakge is clearly there now (wget -qO- http://archive.ubuntu.com/ubuntu/dists/vivid/main/binary-i386/Packages.bz2| bzcat -cd |grep '^Package: init$') [11:31] xnox: done 2 mins ago [11:31] pitti: tah. [11:31] apw: do you think I should just return False or bail out if the system is overlayfs? [11:32] didrocks, well not knowing why systemd cares to know, it is hard to say [11:33] xnox: ah, I got upstart to succeed again after 6 retries.. [11:34] apw: this is a common functionality for some units to have a ConditionIsMountPoint=. We are using it as /etc/machine-id is not writable if empty at systemd startup (due to our ro mount, contrary to fedora and others), so systemd will overmount it as tmpfs. Then, we detect in a service (triggered by that ismountpoint condition) and do the swapping to a committed rw version to persist across reboots [11:34] for snappy [11:34] apw: but basically, this is just one example, maybe we will have other services using ConditionIsMountPoint= [11:35] pitti: Ah, *now* it needs to have its priority promoted first [11:35] ah, http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt :) [11:35] cjwatson: ack [11:35] I'm fine to bail out in that specific case, but that wouldn't fix for other services if they expects mount points to perform their operations [11:35] pitti: Go ahead and do that, wait a publisher run, retry [11:35] cjwatson: *nod*, thanks [11:37] xnox: notify-osd success, so dbus should go in now [11:39] pitti, hmm [11:39] ogra_: I'm scared if you say "hmm"! [11:39] * pitti hugs ogra [11:39] pitti, i'm not sure you should add upstart to the desktop file in the touch seed [11:40] this is the base of desktop-next [11:40] ogra_: that's for desktop-next, isn't it? aren't these system images? [11:40] no, isos afaik ... [11:40] ogra_: I seede it to touch-core [11:40] Laney, seb128 ^^^^ [11:40] * Added upstart to desktop, touch. This ensures that we keep upstart on [11:40] Touch even when we switch Ubuntu to systemd. (LP: #1428026) [11:41] Launchpad bug 1428026 in ubuntu-meta (Ubuntu Vivid) "change seeds to keep upstart as init system on Ubuntu Touch" [Undecided,In progress] https://launchpad.net/bugs/1428026 [11:41] ogra_: so at most it's over-cautious, but I'm not sure anyone ever tested desktop-next with systemd yet [11:41] i was just commenting to your chanelog entry [11:41] definitely nobody i think [11:41] but i also think it wants to use the standard core system [11:41] tricky one :) [11:42] If the jobs left to port are phone/android/whatever specific then it's probably fine [11:42] ogra_: right, so we'd move upstart from touch-core to touch [11:42] but someone should check before we do the switch there I guess [11:42] for now I thought we'd rather switch stuff step by step [11:42] Laney, right, i thinnk there will be some that arent ported even for the non phone specific stuff [11:43] a few more stuff has direct upstart dependencies, like initramfs-tools-ubuntu-touch (but that's in touch-android, so we're fine) [11:43] ogra_: yes, for sure [11:43] right [11:43] although, xnox' property watcher fixes are for android only [11:44] anyway, not too many fronts at once, please :) [11:44] i dont think -next uses properties [11:44] doko: I don't see any commits in the repository newer than the current release (about 6 months ago) [11:44] ogra_: right, no android container I presume [11:44] misses the android backend :) [11:44] ogra_: but thanks for bringing it up; it seems to me that moving touch-core is a nice intermediate step [11:44] pitti: hm, i don't like that at-spi2-core is valid candidate, yet dbus is not. the two should go in together..... [11:45] ogra_: argh, of coruse I mean s/touch-core/desktop-next/ [11:45] pitti, ok [11:45] xnox: ah, no versioned deps/breaks? [11:45] pitti: nah, no change rebuild =))))) [11:45] * xnox is good like that [11:51] pitti, i assume you want a test image build once everything landed ? [11:52] ogra_: it's still a no-op, so not that interesting; but can't hurt indeed [11:53] well, i guess you want to at least make sure that trying to remove systemd-sysv doesnt make the build fall over if it isnt installed [11:53] ogra_: right; unlikely, but good to verify [11:53] I'm pretty confident in that, but indeed, good to verify [11:54] http://paste.ubuntu.com/10526088/ [11:54] xnox: btw, dependencies did save you somehow :) (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt) [11:54] looks good [11:55] xnox: i. e. now it's accepting both in the same run, before that at-spi2-core was held back due to uninstallability [11:55] interesting that you had to add packagekit ... [11:55] I don't understand that bit, but it wasn't worth a lot of time investigating [11:55] If mvo_ gets round to finishing the native-dbus work in click then packagekit goes away anyway [11:55] (Which probably has to happen for desktop-next?) [11:56] And we have to finish the native-dbus work before packagekit is upgraded under our feet to a version that no longer supports plugins [11:56] right, i just dont get why it is explicitly needed, it is seeded in touch-core [11:57] cjwatson: re:native-dbus work in click -> what's that about? [11:57] * xnox is happy to do dbus work. [11:57] Well, that makes it a dependency of ubuntu-touch, but apt probably hasn't worked that out yet :) [11:57] ah === MacSlow is now known as MacSlow|lunch [11:57] xnox: https://code.launchpad.net/~cjwatson/click/native-dbus but mvo_ had something on top of that [11:58] I don't think it needs significant extra code at this point IIRC, but I also don't know exactly where it's sitting [11:58] https://code.launchpad.net/~mvo/click/native-dbus [11:58] mvo_ probably got eaten by snappy before remembering to finish it :) [11:59] haha [11:59] now i finally get the namin scheme [11:59] the point was to stop relying on packagekit's dbus interface, which click only ever used in the first place because it was expedient [11:59] +g [11:59] but it's a bit awkward for various reasons, it means people have to remember to use pkcon and "click install" doesn't just DTRT internally [12:00] and it's unsustainable because packagekit has removed the "plugin" facility in newer upstream versions, which the current design utterly relies upon [12:00] so if we give click its own dbus service, then we can ditch the dependency on packagekit entirely and simplify the dependency structure, so we no longer have the awkward conflict with aptdaemon [12:02] however it's a three-step thing: first we add the native dbus service to click, then we whack-a-mole all the stuff that's using pkcon or possibly even packagekit's dbus service directly to interact with click packages, then we remove the packagekit plugin from click [12:02] I planned this all out towards the end of last year, but then got burned out and moved to LP [12:08] didrocks, yes, i can see it is an issue not being able to implement that check, i just right now don't have any answers [12:11] apw: ok, I'll get the workaround in for now for that specific case, keep me posted if you can think of anything [12:19] Odd_Bloke, smoser, utlemming: I updated bug 1427999, it's much less severe than I thought [12:19] bug 1427999 in cloud-init (Ubuntu) "cloud-init does not purge with systemd" [Medium,New] https://launchpad.net/bugs/1427999 [12:20] pitti: Good to know, thanks. [12:20]