[00:23] mwhudson: You could add that amd64 as a foreign arch to dpkg? [00:24] mwhudson: I think? [00:33] RAOF: how do i do that again? [00:34] oh dpkg add-architecture [00:34] but no [00:34] W: Failed to fetch http://www.apache.org/dist/cassandra/debian/dists/20x/InRelease Unable to find expected entry 'main/binary-arm64/Packages' in Release file (Wrong sources.list entry or malformed file) [00:40] mwhudson: you can arch-qualify the sources.list entry... I think [amd64] is the syntax, forget where it goes :) [00:41] deb arch=amd64 i think maybe? [00:42] er [00:43] deb [arch=amd64] http://www.apache.org/dist/cassandra/debian 20x main [00:43] apparently [00:43] tarpman: thanks :) === yuning is now known as yuning-lunch === yuning-lunch is now known as yuning [05:41] Good morning [06:39] good morning [06:42] hey dholbach [06:43] hey mvo [07:35] Hey, any SRU team members (other than cjwa tson) around? === timrc-afk is now known as timrc === dholbach_ is now known as dholbach [10:37] pitti: on http://dep.debian.net/deps/dep8/ "current specification" link is 404. [10:38] pitti: can you update it to point to the right place? And what is the right place these days? [10:38] xnox: indeed, should be http://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;a=blob_plain;f=doc/README.package-tests.rst;hb=HEAD [10:38] xnox: I renamed the files to *.rst [10:38] xnox: I can't update it myself, but I'll find out who can [10:39] pitti: ok. Are you setting up read-the-docs for autopkgtest? it could process rst to make it look all dandy and stuff. [10:39] xnox: the package builds nice *.html files from those now and ships them in /usr/share/doc/ [10:39] pitti: ah, cool. [10:39] xnox: I haven't felt a strong urge to put them elsewhere, but if there's demand why not [10:43] pitti: hm, i think dep8 website can parse RST as well, no? Would be nice if that was the thing directly. [10:43] oh, http://dep.debian.net/recentchanges/ looks like some svn [10:44] xnox: I'll check out http://dep.debian.net/depdn-howto/ after I'm done with my current multi-thread unwrangling (sorry, too much brain state) [10:45] =)))) [10:49] xnox, do you happen to know if anyone in foundations works on bug 1323732 (did you discuss it in a meeting perhaps) ? [10:49] bug 1323732 in adduser (Ubuntu) "adduser should support managing additional password/shadow/group files from libnss-extrausers" [High,Confirmed] https://launchpad.net/bugs/1323732 [10:49] (see my last mail to ubuntu-phone) [10:50] steve asked me to initially assign it to hi so he could hand it to someone after malta ... looks a bit like it was forgotten [10:50] *him [10:54] ogra_: there is no confirmation that slangasek has recovered after 4th of july yet. Since it is still assigned to Steve, I believe you should be poking him. [10:54] ogra_: typically he changes assignee when he hands stuff over. === MacSlow is now known as MacSlow|lunch [11:03] xnox, right, just wanted to know if it came up in some team discussion or so [11:03] thanks [12:20] xnox: so I committed http://lists.alioth.debian.org/pipermail/dep-commits/2014-July/000316.html but I guess it'll take a bit to propagate to the website === MacSlow|lunch is now known as MacSlow === _salem is now known as salem_ === ubott2 is now known as ubottu === Trevinho_ is now known as Trevinho === Adri2000 is now known as Guest67185 === ming is now known as Guest65048 [12:51] mvo: FYI, $USER is now set for root tests in CI [12:53] pitti: thanks ! === iulian_ is now known as iulian === Guest67185 is now known as Adri2000_ [13:56] hello :) [13:57] is there a way to install the grub deb in a none interactive way, he is askin "Continue without installing GRUB?" and i want to answer with yes [13:58] setting question priority lower [13:58] i need that for an automated build of ubuntu, but havent found yet a solution for it [14:01] maybe apt-get -qq ? [14:03] shouldn't setting the debconf frontend to non-interactive help? [14:03] oh that one :-) [14:07] Laney, hmm, did you see my latest meta upload ? seems desktop-next inhertis some stuff from somewhere that touch doesnt have ... [14:07] (i added all the entries equally to touch and desktop ... but only tcptraceroute was pulled into desktop) [14:08] link? [14:09] Laney, https://launchpad.net/ubuntu/utopic/+source/ubuntu-touch-meta/1.162 [14:09] Laney, bah, ignore me ... i'm blind [14:09] right... was wondering :) [14:10] (somehow the evolution formatting made me miss "desktop" in all these lines) === desrt_ is now known as desrt === doko_ is now known as doko === tarpman_ is now known as tarpman [15:05] xnox: I suppose we /can/ keep startpar disabled, but is there a specific reason you want to? I hadn't heard about any problems in this regard [15:19] slangasek: hey, you're SRU team, right? [15:20] Just wanted to make sure you saw my email to the ubuntu-devel mailing list [15:20] It would be very much appreciated if you could comment, do whatever is needed to move this along [15:21] slangasek: reasons to keep startpar disabled are as follows -> generally unreliable startpar-bridge integration. (a) task jobs hanging boot/shutdown (b) jobs set to manual (e.g. via override file) hanging boot/shutdown (c) little interim gain in resolution of a/b, taking away time to better support systemd (d) startpar is not used under systemd [16:43] pitti: hi, any idea of a time frame on LP: #1247584 ? [16:43] Launchpad bug 1247584 in systemd (Ubuntu) "[keymap] Since upgrade to Ubuntu 13.10, udev doesn't map middle mouse button." [Undecided,In progress] https://launchpad.net/bugs/1247584 [16:46] I'm unable to find a branch in LP that contains the release of package systemd (204-5ubuntu20.3). Am I not searching where I should, or was that package generated outside of LP/bzr? [16:46] distro is trusty [17:46] jamespage, is this server-team stuff? https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-mongodb/lastBuild/? blocks gcc-4-9, although it is not used === alexisb is now known as alexisb_lunch [18:27] Shock: there is no branch for it, the upload is here however https://launchpad.net/ubuntu/+source/systemd/204-5ubuntu20.3 which also has links to build-records (and thus debs) and a diff against previous upload (20.2) [18:27] Shock: it's been released to updates pocket last thursday. [18:35] xnox: thanks, is there a way to create a daily build if there's no branch for it? [18:36] xnox, Shock: looks like there's a branch for it to me [18:36] dobey: how did you find the branch? [18:38] oh, i guess it didn't import [18:38] Shock: why would you want to create a daily build for a specific version anyway? [18:39] dobey: I want to build udev automatically (with a patch) whenever a new version is released [18:40] Shock: in general, or only to trusty-updates? [18:41] in general, i don't see why you wouldn't use lp:ubuntu/systemd to do that [18:41] dobey: I'm not sure what that means; I'm only interested in trusty atm [18:42] though i don't know how you plan on adding the additional patch exactly [18:42] dobey: I couldn't find the changes that were in https://launchpad.net/ubuntu/+source/systemd/204-5ubuntu20.3 in lp:ubuntu/systemd [18:42] dobey: I plan to use build recipes in launchpad [18:42] yeah i'm not sure why they aren't in utopic there [18:42] stgraber: ^^ why is that? :) [18:43] Shock: i don't see how you will add another patch though [18:43] dobey: merge from a personal branch? [18:43] Shock: you're going to have to manually resolve conflicts every time there's an update, most likely [18:44] dobey: probably because the importer is broken somehow, that happens. [18:44] dobey: IIRC the Ubuntu systemd packaging is maintained in a git branch on alioth, so I usually just upload to the archive and let pitti deal with the VCS [18:44] dobey: the only conflict would be in debian/patches/series [18:44] stgraber: i mean, why are those changes from the trusty update, not in utopic? [18:45] dobey: and I'm pretty sure I can avoid the conflict by putting my patch as the first line in the series [18:45] dobey: they are in utopic [18:46] stgraber: hmm, Shock said he couldn't find them in the utopic package. [18:46] those fixes were uploaded in 204-10ubuntu9 or earlier [18:46] ah ok [18:47] the whole point of the SRU to trusty was to get all the fixes of utopic in there so the cgmanager integration patch is now identical in both [18:47] Shock: what does your additional patch do exactly, anyway? why not just get it into debian/ubuntu? [18:48] dobey: it makes my mouse work :). it's taking too long to get it in ubuntu/upstream LP: #1247584 [18:48] Launchpad bug 1247584 in systemd (Ubuntu) "[keymap] Since upgrade to Ubuntu 13.10, udev doesn't map middle mouse button." [Undecided,In progress] https://launchpad.net/bugs/1247584 [18:49] pitti: ^^ get that in already. :) [18:50] dobey: in any case, knowing how to build a package with changes wrt official package would help me in other situations [18:51] dobey: I'd rather not go through the whole manual ordeal every time the package is updated in the oficial repos [18:51] Shock: i'd suggest doing it against trying to build against lp:ubuntu/systemd then [18:52] dobey: is there a way I can target the trusty version in a lp build recipe? [18:52] directhex, mono ping [18:53] Shock: in the recipe config you specify target distributions to build against.... [18:53] Shock: you mean build it on trusty, or you mean patch against the trusty version? [18:53] Shock: hence yes, you control which distribution(s) a given recipe will be build. [18:53] dobey: patch against the trusty version [18:53] Shock: use the trusty branch, but i don't see why you need to use that specific branch, versus just using the actual newest version [18:54] unless the utopic version outright fails to build on trusty or causes it to explode or something [18:54] Shock: lp:ubuntu/* branches are never guaranteed to be up-to-date, as the archive is authoritative source, not the bzr branches. Thus e.g. kubuntu folks maintain automated rebuilds outside of bzr branches & recipes. [18:55] import failures are pretty common too [18:55] dobey: I had planned to build against lp:ubuntu/trusty/systemd but I couldn't find the latest changes in there [18:55] Shock: instead they automate $ pull-lp-sources; wget -O /tmp/my.patch ....; quilt import /tmp/my.patch; debuild -S; dput ppa:.... [18:55] Shock: no, they should appear in trusty-updates and trusty-proposed, once imported [18:55] assuming a successful import [18:55] Shock: once trusty is released, it's release pocket is frozen. Thus lp:ubuntu/trusty/systemd will never update. [18:55] xnox: hmm, that would work. thanks [18:56] Shock: the pockets which are updated are trusty-updates, trusty-proposed and trusty-security, iff the import succeeds. [18:56] xnox: the latest udev release was in the trusty pocket [18:57] Shock: it's been attempted to fully automate merging builds, but it ultimately fails. Just because your patch still applies, doesn't mean that it will build, or if it builds, it doesn't mean it will be operating correctly. [18:57] I also looked at lp:ubuntu/trusty-proposed/systemd [18:57] Shock: branches are not up to date.... [18:57] $ rmadison -S systemd | grep source [18:57] systemd | 204-0ubuntu18 | saucy | source [18:57] systemd | 204-0ubuntu19.2 | saucy-updates | source [18:57] systemd | 204-5ubuntu20 | trusty | source [18:57] systemd | 204-5ubuntu20.3 | trusty-updates | source [18:57] systemd | 204-12ubuntu1 | utopic | source, amd64, arm64, armhf, i386, powerpc, ppc64el [18:57] it seems I'm misunderstanding something :( [18:59] $ bzr branch lp:ubuntu/trusty-proposed/systemd [18:59] Most recent Ubuntu Utopic version: 204-12ubuntu1 [18:59] Packaging branch version: 204-10ubuntu1 [18:59] Packaging branch status: OUT-OF-DATE [19:00] are the packages in trusty generated from lp:ubuntu/systemd? it seems not [19:00] Shock: Manual source builds are uploaded and published into the archive, once published binaries are build, after that importer walks the archive trying to create bzr branches lp:ubuntu/* if it manages to sucseed. [19:00] Shock: no, ubuntu is not build from bzr branches. [19:00] xnox: ok, that clears up a lot [19:01] Shock: pull-lp-source systemd trusty -> will fetch the latest trusty sources (including security, updates and proposed-updates) [19:01] Shock: if you want at most security -> specify trusty-security; for at most released updates -> specify trusty-updates [19:01] infinity: hey, we're having the grooviest of times looking at the SRU for docker.io. Looking at rmadison output for golang-context-dev, the source pkg version is older than the package version... i'm confused. [19:02] xnox: ^ or you probably know offhand what's going on :) [19:03] hallyn: looking. infinity is on hooligans. [19:03] * holidays [19:03] xnox: ok, that helps. There's no equivalent for "pull-lp-source systemd trusty" in a build recipe, correct? [19:03] Shock: no [19:03] xnox: ah, thanks :) [19:03] Shock: not, inside launchpad that is. [19:04] hallyn: yeah, that looks very very odd. [19:04] hallyn: i'm guessying there was a partial / timed-out copy, and or partial delete/removal. [19:05] * hallyn quickly checks the others i'll be depending on, [19:05] doko, pong [19:05] hallyn: which release are you enquiring about? utopic? [19:05] xnox: golang-pty-dev too [19:05] doko, although i'm about to go to the supermarket [19:06] xnox: yeah, utopic, we'll need those SRUd to trusty [19:06] directhex, could you upload a mono version using my pretty printers patch? [19:06] hallyn: golang-context-dev in utopic looks insane. ditto golang-pyt-dev [19:06] xnox: AND golang-mus-dev too [19:06] golang-mux-dev that is [19:07] doko, where is that patch? LP? [19:08] xnox: so what, we grab the .dsc from lp and re-push with a 'b1' version extension? [19:08] directhex, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752661 [19:08] Debian bug 752661 in src:mono "make the -gdb.py file compatible with python3" [Normal,Open] [19:08] xnox, dobey: thanks [19:08] oh fuck me, i totally forgot about that one [19:08] changelog "rebulid bc solar flares" ? [19:08] doko, yes, totally will do that later today [19:08] directhex, I would appreciate it if you could do a trusty SRU too [19:09] cjohnston: wgrant: slangasek: looking at $ rmadison -S golang-context-dev -> and then inspecting launchpad looks crazy inconsistent. http://archive.ubuntu.com/ubuntu/pool/universe/g/golang-context/golang-context-dev_0.0~git20140522.1.1f3e8a4-2_all.deb is Available to download, yet launchpad has no idea about such a source version number, nor binary version number. [19:09] cjwatson: ^ [19:09] cjohnston seems to be a problem ;-P [19:10] hallyn: it looks beyond my powers. I believe you need people with powers as above, sans s/cjohnston/cjwatson/ (thanks doko ;-PPPPP it's not like i didn't notice ;-) ) [19:10] mdeslaur, pitti (and tyhicks): https://code.launchpad.net/~ubuntu-core-dev/apparmor/master being out of date is just an oversight [19:10] doko: or e.g. do you have special launchpad powers? [19:10] mdeslaur, pitti (and tyhicks): lp:~apparmor-dev/apparmor/apparmor-ubuntu-citrain is an experiment [19:11] jdstrand: oh, hrm, ok [19:11] mdeslaur: we talked about this before with your last upload [19:11] xnox: thanks :) [19:11] well, my memory of that talk was that we were switching to the other one :P [19:11] we don't have a resolution yet cause we haven't done enough experimenting yet [19:12] hallyn: so the source and binary are in the archive, as seen here http://archive.ubuntu.com/ubuntu/pool/universe/g/golang-context/ yet launchpad has no recollection of building of publishing that. [19:12] my resolution was you said that you wanted to always use https://code.launchpad.net/~ubuntu-core-dev/apparmor/master [19:12] xnox: would pull-lp-source, patch locally then bzr push to personal branch that has build recipe work? [19:12] xnox: and same with the other two i assume? [19:12] s/resolution/recollection/ [19:12] jdstrand: heh :) [19:12] Shock: no, pull-lp-source won't grab it [19:12] jdstrand: I'll update it, thanks [19:12] and that I said, "well, it isn't important enough to be distracted by it now, so let's wait" [19:12] (which was why i suggested dget on the .dsc) [19:12] s/that/then/ [19:13] hallyn: pull-lp-source to get archive version of package [19:13] Shock: it will grab the old version [19:13] mdeslaur: you had reservations about all the apparmor devs having commit access. I think that is a valid concern worth discussing [19:13] jdstrand: mdeslaur, hallyn: now that i have you all in one place: libvirt + qemu + apparmor was giving me quite some grief yesterday [19:14] desrt: how so? [19:14] it seems that adding custom commandline arguments to a libvirt vm config is a really great way of triggering apparmor violations [19:14] Shock: it may. pull-lp-source gives you an unpacked debian source package. It's not a branch. You can e.g. bzr init; bzr commit; bzr push as you wish, etc. [19:14] yes, I would think it would be [19:14] which i responded to in the usual way: uninstall apparmor [19:14] * jdstrand shakes head [19:14] desrt: yes, if you customize configs, you need to customize the profile [19:14] but once you do this, libvirt can no longer start qemu instances at all [19:14] why not just update the profile? [19:15] because i don't know how [19:15] so, you should be able to uninstall apparmor and have it work, but you need to restart it [19:15] desrt: so you're looking for a link to the documentation? :) [19:15] uninstalling apparmor shouldn't cause libvirt to stop working in any case... [19:16] desrt: if libvirt thinks it should be able to confine the vm and now it can't, it'd be unsafe for it to do so [19:16] jdstrand: restart libvirt? i did try that.... didn't help. [19:16] desrt: but here, #ubuntu-hardened ,and #ubuntu-servrer are good places to ask how to update the profile :) do you have DENIED messages in syslog? [19:16] hallyn: how do you know about those uploads and binaries? and where are they actually coming from? Since those version numbers do not exist in debian and are mysteriously published [19:16] hallyn: who/where/what uploaded them? [19:16] xnox: i looked at the dpkg-checkbuilddeps for docker.io [19:16] hallyn: yes. finally figured out why my disk image which was owned by the right person (and set 666 out of desperation) was getting me "Permission denied" errors when i checked dmesg [19:16] xnox: i have no idea. lemme try one thing, [19:17] you can also adjust /etc/libvirt/qemu.conf to have: security_driver = "none" [19:17] after an hour and a half of wasting my time... [19:17] jdstrand: great advice. thanks! [19:17] hallyn: scary they happened on 13th of June. I'm not supersticious but still. [19:17] sacre bleu! [19:17] * desrt will try that tonight once home again [19:18] xnox: wow, i see. i figured 'full publishing history' on lp would show the 2014 version [19:19] xnox: do you know who synced docker.io? [19:19] i would bet that person at least knows who did golang-context-dev [19:19] desrt: I maintain adjusting the policy is the safest option. also, libvirtd should be able to run with apparmor uninstalled. I can't really debug what happened over the weekend, but uninstalling apparmor may have left the profile loaded in the kernel. if you uninstalled and rebooted and it didn't start, then there is a bug (it used to work) [19:19] fwiw, i think i discovered a big part of what makes me hate on apparmor so much, and it would not be too hard to fix it: [19:20] returning EACCES on apparmor errors is extremely user-unfriendly [19:20] it is EACCES and not EPERM? [19:21] some new ESECURITY with corresponding "access denied by security framework" or so would mean i don't spend so long pulling my hair out [19:21] may have been EPERM. [19:21] that isn't how the kernel LSM works aiui. perhaps jjohansen could comment [19:22] hallyn: no. actually everything is fine. [19:22] no... it was EACCES -- "Permission denied" (i remember the error message) [19:22] EPERM would have been "Operation not permitted" [19:22] xnox: oh? [19:22] hallyn: golang-context-dev source package got renamed to golang-context in utopic [19:22] hallyn: rmadison -S golang-context [19:22] hallyn: rmadison -S golang-context-dev [19:22] hallyn: and read sanity from that =) [19:23] oh for pete's sake [19:23] jdstrand, desrt: yep mostly we return EACCES that is there error the security frame work is supposed to use [19:23] so same with the others i assume; checking [19:23] yes [19:23] hallyn: yes. [19:23] seems weird to mix "error that happens under normal circumstances" with "error that should only fire if something very very bad has happened" [19:24] desrt: yeah, more info would be nice...Dan Walsh wanted to do that at some point: http://thread.gmane.org/gmane.comp.lib.glibc.alpha/28239 [19:24] * desrt assumes apparmor is in place here to mitigate (for example) the VM guest attacking one of the device drivers in qemu and breaking out of isolation [19:24] cjwatson: wgrant: slangasek: never mind. hallyn and I got confused about golang-*-dev source packages renamed to golang-* whilst keeping all binary names same. [19:24] xnox: and yet not for golang-gocapability-dev :) [19:25] hallyn: for SRU, you'd need to rename them back I believe. as in golang-mux SRU will be for golang-mux-dev, cause it's insane to rename source packages in stable releases =) [19:25] xnox: thanks :) [19:25] * xnox goes out for dinner [19:25] mdeslaur: big +1 on this email from me.... [19:25] xnox: that's gonna hurt - but thanks [19:26] desrt: it is about protecting vms from each other and vms having various resources on the host. it doesn't do anything for hypervisor (which are in kernel) [19:26] his words about "lucky enough or skilled enough to know where to look..." is completely true.... (not to mention adding on "connects the dots and remembers....") [19:27] jdstrand: ya... but the various device drivers are implemented in the qemu binary... if you figured out a way to buffer-overflow one of those (for example) then you could run code as the qemu binary [19:27] and for example, open files on the host and pass their contents into the guest... [19:27] yes, the qemu device drivers are an attack vector [19:28] desrt: the qemu binary is run under confinement. what you describe is one thing apparmor protects [19:30] i've noticed that libvirt goes out of its way to pass most things into qemu via file descriptors.... that's nice. [19:30] yeah [19:32] seems like a good usecase for seccomp :) [19:32] yep [19:34] that has been something qemu upstream has wanted for quite a while === alexisb_lunch is now known as alexisb [19:36] looks like they do utilize seccomp nowadays, but the syscall whitelist is pretty large [19:37] * desrt waits until capsicum is completely reimplemented [19:39] package versioning question :) from trusty to utopic, source package was renamed from golang-pty-dev to golang-pty. [19:39] to sru that back to trusty, we need to change the source name back. what to call the version number? [19:39] in utopic, it's now 0.0~git20140315.1.67e2db2-1 [19:39] should we call it 0.0~git20140315.1.67e2db2-1ubuntu1.14.04.1 ? [19:40] hopefully someone will fix LSM stacking before capsicum gets implemented [19:40] mdeslaur: har har [19:40] yeah, exactly :) === salem_ is now known as _salem === mwhudson_ is now known as mwhudson [20:45] michagogo: yes, I did see that mail and it's in my queue to answer [20:46] slangasek: Great, thanks. [20:46] (I just want to avoid it stagnating again) [20:47] xnox: so if we don't enable startpar, what happens to an init script that has a dependency on a script that shadows an upstart job? Are we force-starting the upstart job from the init script hooks, ignoring the upstart job's own dependency declarations? Or are we letting the dependent init script start without its dependencies guaranteed to be satisfied? Or are we assuming this case is negligible? [20:49] slangasek: it must source /lib/lsb/init-functions and if there is matching /etc/init/foo.conf and we are running under upstart it gets short-cirtuited in favor of upstart. [20:50] what does "short circuited" mean in this context? pass-through, or no-op? [20:50] (this is not present in debian, where instead startpar & startpar-bridge is envofrced) [20:50] because both have implications for reverse-dep init scripts [20:50] slangasek: if called as /etc/rc?.d/[KS]??* -> no-op. If called as /etc/init.d/$foo -> pass through. [20:51] slangasek: imho we should be removing init.d scripts where both systemd unit & upstart jobs exist. [20:52] xnox: "we" being Ubuntu, I guess, since that's a non-starter for Debian? That implies more divergence where we would like less [20:52] slangasek: and all "key dependency" init.d scripts -> are either no-op upstart jobs on some arbitrary events (always satisfied before going into a particular runlevel) or symlinked to /dev/null on systemd side. [20:52] slangasek: yes, "we" being Ubuntu. [20:52] well, what's a key dependency here? [20:53] slangasek: non-LSB defined dependencies currently used by debian scripts. "umountroot checkfs unmountfs" etc. [20:54] mountall [20:54] slangasek: does startpar enforce dependencies? apart from ordering based on dependencies? [20:54] xnox: what I mean is, have you reviewed all such dependencies provided by packages that also ship an upstart job and confirmed that only ones in /etc/rcS.d matter? [20:55] doko, building, for sid. SRU will take longer [20:57] slangasek: i have not. But isn't my fastest path to systemd by default to (a) write systemd units for packages that have upstart jobs only (b) keep init.d scripts as they are, or if they need event ordering replace them by systemd units [20:58] thus all non-trivial init.d scripts, and upstart-only should get systemd treatment and job's done. [20:58] non-trivial init.d scripts are those that e.g. currently depend on upstart-tasks. [20:59] or are in rcS etc. [21:00] slangasek: we have insserv enabled today, without startpar. And that's enough for correct behaviour under systemd, and is correct enough under upstart with our lsb-initfunctions.d hook. [21:01] xnox: fastest path> we definitely have to have the boot working correctly for our users under either of upstart or systemd for 14.10; it sounds like you're proposing to sacrifice correctness under upstart in order to speed up the transition [21:02] I'm not convinced of the "correct enough" without seeing the data to back this up [21:03] slangasek: enabling startpar will regress boot under upstart for user in 14.10. I would like to avoid regressions under upstart (e.g. boot hangs for whatever reason, and didn't previously) [21:04] xnox: my doubt is whether reintroducing the init scripts (which were previously stripped from Ubuntu packages) is enough on its own to regress boot for some overlapping set of users [21:04] introducing init.d scripts, as we have to this point, is also regressing boot under upstart. [21:04] true. [21:04] yes [21:05] but we do want inserv support, given that there are packages in debian today that don't support non-inservv installation. [21:05] that's necessary. [21:07] where insserv gives us the symlink ordering on disk, but does not do the dependency-based boot of init.d [21:07] so, if I do a diff of sid vs utopic: if an init.d script is missing in utopic, but present in sid, it must have both upstart+systemd jobs in utopic. [21:08] slangasek: well, insserv gives us on-disk correct ordering - same as we have to date with upstart, and it works well enough. (no regression) [21:08] if we're not using startpar, and the initscript is a no-op at boot, I don't see any reason to remove the init script in Ubuntu [21:08] slangasek: and systemd parses lsb-headers itself and can do dependencies without startpar et.al. [21:08] slangasek: true. [21:09] slangasek: it's just we need to identify them correctly. [21:09] identify them for what purpose? [21:09] for removal in ubuntu =) [21:09] we re-introduced a bunch of them by now. [21:10] *we have re-introduced a bunch of them by now. [21:10] but removing them doesn't improve anything [21:10] so we should just not remove them, in which case we also don't need to identify them [21:10] =)))) [21:11] the one impact this *will* have is on boot speed under upstart [21:11] which was part of what startpar was meant to address [21:11] the fork+exec+source for each reinstated init script will be non-negligible [21:11] slangasek: true, boot speed will regress under upstart. And we will no longer have fair comparison against systemd to spot regressions. [21:12] slangasek: how do I make startpar bridge reliable for real? one suggestion, is to make upstart-startpar-bridge instances write out files in /run, which startpar can inspect to get complete cold-boot picture, in addition to interractive notifications. [21:13] (b) how to properly "pass" init.d scripts that bailed-out in pre-start [21:13] (c) how to properly "pass" init.d scripts for which upstart job got "manual"-ed [21:14] (a) above was, how to get correct state from before startpar is executed (i.e. catch tasks) [21:16] xnox: "reliable for real"> so requiring all upstart jobs that map to existing init scripts be non-task non-instance jobs was insufficient to make it reliable? [21:17] the /run trick wouldn't help for c) [21:18] slangasek: that resolves (a). It doesn't resolve (b) nor (c). And doesn't help to resolve (a) for sysadmin/3-rd party vendor installed system upstart job & init.d script (e.g. plex server) [21:18] i.e. making upstart jobs non-task/non-instance in distro, only resolves it in distro. [21:18] xnox: plex server both has a task/instance upstart job, and reverse-dependencies of its init script? [21:19] bearing in mind that otherwise, the failure scenario here should be "startpar never finishes", not "system hangs on boot" [21:19] slangasek: [and reverse-dependencies] is redundant. [21:19] no [21:19] because nothing else should care if startpar hangs waiting for a single job that will never finish [21:19] slangasek: starpar hangs on instance/tasks that are in TARGETS = without any reverse-depends. [21:20] yes, but "startpar hangs" doesn't break the system, it just leaves an annoying startpar process running === _salem is now known as salem_ [21:20] unless this has changed? [21:20] hanging startpar => fail to reach runlevel 2 => fail to run tty1 => fail to start startpar for shutdown. [21:20] no [21:20] startpar is run twice, once for rcS and once for rc2 [21:20] that's what pitti and I have seen. [21:20] we need startpar for rcS to be reliable, if it's used [21:20] but there should be no third-party init scripts in rcS [21:21] ok. [21:21] and for rc2, startpar is called *after* the runlevel event is emitted; and nothing else cares if startpar finishes [21:21] slangasek: i beg to differ. [21:21] the 'rc' job will never finish, until another 'runlevel' event is sent [21:22] xnox: for runlevel 2, the runlevel event is emitted by rc-sysinit; startpar is invoked from rc [21:22] slangasek: tty1.conf is start on stopped runlevel [2345], hanging rc runlevel 2 job, prevents tty1.conf from running. [21:22] sorry [21:22] tty1.conf is start on stopped *rc RUNLEVEL=[2345]* [21:22] right, tty1 is a special case [21:22] specifically because we want the prompt to wait until all our startup jobs have finished outputting [21:22] and not-starting tty1 imho is a critical regression. [21:23] hmm, I don't agree [21:23] anyone who cares about the prompt on tty1 should certainly also know how to switch VTs to log in on tty2 [21:23] and everyone who doesn't care about the prompt on tty1 is looking at lightdm anyway, which has no such dependency [21:23] clouds don't know how to switch ttys =) [21:23] you just broke cloud-init [21:24] the cloud's console isn't on tty1 either, is it? [21:24] some of them are [21:24] I have used crappy clouds though =) [21:24] hmm [21:24] * xnox being Latvian and all that shady torrent-boxes of mine [21:24] I know there was talk about supporting consoles in the cloud images, but I thought they were serial console [21:25] smoser: ^^ can you set me straight here? [21:25] slangasek: it depends on the cloud. There are clouds with all sorts of console. OpenStack clouds tend to offer consoles. [21:26] utlemming: a console in the form of tty1 with no VT switching? [21:26] slangasek: easier than that. "cloud-final is start on (stopped rc RUNLEVEL=[2345] and stopped cloud-config) [21:26] " [21:26] man [21:26] slangasek: thus without a complete rc, we don't have complete cloud-init, thus all instances stuck in initialising states. [21:26] slangasek: yeah, you don't get a VT to switch between [21:28] slangasek: which kind of brings us to another point. How do I see us supporting systemd for cloud images? Install systemd & reboot? publish a (limited) image flavour which boots with systemd? [21:28] slangasek: hanging rc, means hanging startpar, and two startpars don't like to run in-parallel to each other. Which is what pitti found out, but i didn't reproduce/investigate yet. [21:29] xnox: so that brings us back to /run; that addresses your a), but doesn't seem to address either b) or c). But the alternative to making startpar reliable is just to not enable it at all [21:29] "don't like to run in parallel" - doesn't the previous one die when the rc job dies on 'stop on runlevel [!$RUNLEVEL]'? [21:30] slangasek: it should. Hence I say, didn't investigate yet. [21:30] ok [21:31] slangasek: would you agree, that things that have no reverse depends in .depends.* files, and are listed in TARGETS, should be simply skipped without any notifications from starting, if they happen to have an equivalent upstart job? [21:31] xnox, for 15.04, or whenver we fully cut over [21:31] it will just be /sbin/init and work as expected [21:31] prior to that, my goal was to create a cloud-config syntax that cloud-init would see [21:31] smoser: ok. and before that, we test/develop it however we need/like/can. [21:32] and then would change the init system of the image and reboot [21:32] smoser: ack. [21:32] thats why I asked about dpkg-divert [21:32] smoser: i'm sure slangasek would cringe over dpkg-diverting /sbin/init =))) [21:32] it is orders of magnitude easier if i can switch the init system by simply replacing /sbin/init [21:33] wut [21:33] you do not need to dpkg-divert anything. You install systemd-sysv and remove upstart. [21:34] if you need to tinker locally prior to that, you can either pass init=/lib/systemd/systemd on the kernel commandline, or you can dpkg-divert *locally*; but please don't distribute images that use dpkg-divert [21:34] it would be locally. [21:34] we're not distributing different images. [21:35] ok [21:35] i'm fairly adverse to that. [21:35] then that's fine, feel free to trash your local filesystem any which way ;) [21:35] slangasek: $ apt-cache show systemd-sysv [21:35] NikTh: Can't select versions from package 'systemd-sysv' as it is purely virtual [21:35] hm...? [21:35]