[00:01] rbalint: A diversion that attempts to remount / to see if we can remount /? Seems pretty gross. [00:02] rbalint: And a disgusting workaround for "we're shipping bogus cruft in a config file". [00:03] infinity: yeah, i think we need to decide on the intention of the images [00:03] infinity: i'll take it as a todo to converse with CPC on it, at least [00:03] rbalint: yeah i think i pasted in the bug the bit from the CPC livecd-rootfs hook that adds the fstab entry unconditionally [00:05] nacc: So, there's absolutely value in having a single image to rule them all, from an 'easier to QA' perspective, if nothing else. But fstab still shouldn't be bogus (and then worked around on every boot!), so either the lxd metadata trick, or a first-boot one-shot that checks the state of the world and whacks fstab, both seem vaguely acceptable to me. [00:05] Not sure how early cloud-init gets its tendrils into things, but I suppose maybe it could be involved in that. [00:05] infinity: ack, they do seem clean (and if nothing else, easy to document why we do it) [00:06] infinity: the idea was just make -f /, to see if remounting would work [00:06] infinity: but if there is a cleaner solution, that would be better [00:09] infinity: s/make -f/mount -f/ [00:10] rbalint: Sure. The problem there is that (a) you'd want to do that for all the possible filesystems in /etc/fstab, and (b), if remounting stuff in fstab fails for reasons other than "this is a container and we think we shouldn't", that service SHOULD fail. :P [00:11] So, again, I'm sticking with "fstab shouldn't be bogus". [00:11] If a sysadmin wants to make it bogus after first-boot, they're welcome to keep the failing systemd service that comes with it. [00:11] infinity: yes, it should not be [00:12] yeah, and in this particular case, we are shipping a known-bogus fstab, so i think cleaning it up, somehow, is the most reasonable approach [00:13] nacc: Well, cleaning it up, or having an earnest discussion with CPC about why they think they need an fstab at all. [00:13] infinity: yeah, true [00:13] nacc: It's not needed to boot (root= on the kernel cmdline handles that), and a modern linux system is entirely functional with an empty fstab. [00:13] infinity: that's a good point, i don't know why it would be needed in any default cloud image [00:14] nacc: So, the path of least resistance here might be deleting it, or making it comment-only. [00:14] (I prefer comment-only, but that's just cause my old UNIX beard shrivels slightly at the file literally not existing) [00:15] (Both should work) [00:17] ok, i'm leaving now, maybe tomorrow will bring a nice solution :-) [00:17] looking in `bzr log` ... it seems like it might have been added originally for "Minimal setup required for systemd to provide a r/w FS" [00:17] but that was a slightly different hook [00:18] nacc: So, it's also possible that systemd is braindead, and needs / in fstab to get a r/w / ... But that's easy enough to test. :) [00:20] infinity: yep, on my todo now [00:28] lol lol lol jinja2 build depends on itself [00:29] mwhudson: it does? i don't see it in b-d in debian (synced currenty i think)? [00:29] nacc: via sphinx i think [00:30] ah python3-sphinx -> python3-jinja :) [00:30] fun! [00:30] sounds like you need to bootstrap build it? [00:30] well i'm trying to make it work with python3 but i created a broken package instead (in a ppa) [00:30] heh [00:31] *python3.6 [00:31] so i can't just upload a fixed version, i have to delete the bad one from the ppa first [00:31] #550059 [00:31] no disaster but it's another bit of the yak to shave [00:32] sad to see such old circular dependencies :-( [00:33] well, I repeated the process and I think I did it right this time. Hopefully, all this is done now :) [00:34] oh crap, the scroll got locked above this conversation. infinity, I meant the entire entry that is in the file it creates. It seems the last entry in the changelog [00:36] gsilvapt: Yes, you should run dch -i before dpkg-source --commit if you want it to fill in useful info. ;) [00:36] (I always do it in the wrong order too) [00:37] okay then apparently I did it right this time. I kept the "additional fields" down below just for reference but I guess that's okay [00:37] nacc: Hah, systemd may well be braindead enough to require / in fstab. [00:38] nacc: In fact, I think I ran into this when upgrading some fstab-less machines from upstart to systemd, but I *thought* someone fixed it. :P [00:38] infinity: heh :) [00:38] Evidently not. [00:38] pitti: Hey. Hey you. Upstream guy. Why does systemd still require an fstab just to remount / rw? [00:38] pitti: plzfix, kthx. [00:39] That should sort it. [00:39] pitti: PS: Even upstart/mountall got this right. [00:43] * gsilvapt off for tonight. See you guys later o/ === maclin1 is now known as maclin [05:39] infinity: well, somewhere you need to say how you want fstab and other fses mounted -- why not use the canonical file that has been there for years :) [05:40] nacc: on your lvm2 question ubuntu[34] were timeouts on proposed verification [05:40] infinity: who says that you want the root fs mounted r/o? that's not the case in many container or embedded use cases, and there's been a lot of work towards making systems work with a r/o root [05:41] nacc: therefore they were removed on the following upload of ubuntu5 which "in itself" was to fix the bug mentioned in the changelog [05:41] infinity: so, this behaviour can't be changed willy-nilly, but of course it can be discussed whether there could be a kernel boot option instead [05:41] pitti: I assume you mean r/w [05:42] err, yes [05:42] pitti: Of course, from an Ubuntu perspective, this did change "willy-nilly" already. :P [05:42] pitti: And I'd argue that if you wanted an (abnormal) r/o root, that overriding it in fstab would be your best bet. [05:44] pitti: But it's also just irritating that root is the only fs that doesn't have a set of 99%-correct defaults (which it did with mountall), allowing the joy and wonder of an empty /etc in a systemd world. [05:44] pitti: Sort of ironic, given that's one of systemd's goals. [05:45] pitti: But I'll find a bucket of hats and eat them if you can prove that r/o root is the "usual" systemd use-case. ;) [05:45] with GPT partitions of the proper type and no fstab, systemd-gpt-auto-generator will generate some .mount units where the root fs is r/w, but that doesn't help with the classic MBR case, of course [05:46] (The system should have expected and sane defaults, and /etc should be for overrides is the mantra, is it not?) [05:46] infinity: I'm not saying it's the "usual" case, I'm saying that this is the kind of behaviour that can't just be changed [05:46] pitti: Irksome that it wasn't yelled about earlier, when it could be? [05:47] pitti: For Ubuntu, though, I'd still argue you're wrong that it can't be. ;) [05:47] As upstart behaved in this way for years. [05:47] And, indeed, it also would have done so in RHEL. [05:47] Which muddies the waters a bit. [05:47] infinity: "stockholm syndrome", at some point those who would yell about it instead start to identify with the 'new features' [05:48] pitti: In neither Ubuntu nor RHEL, could one argue that the behaviour with a lack of fstab has been reliably unchanged. [05:49] pitti: Which could lead to the conclusion that almost no one cares one way or the other, and it's a moot point if changing it "breaks" anything, then we're back to philosophical arguments over "useful defaults" and "rare overrides". ;) [05:50] heh :) [08:26] doko, slangasek: for the python 3.6 transition when we can get 3.6 compatibility by importing a new upstream, i guess we should tend that way? [08:26] we're not getting upstream updates much from debian currently because freeze [09:09] mwhudson: yes, there's no freeze, and maybe Debian will be still frozen... you could ask here mitya57, jtaylor, maybe Tumbleweed (currently not here) [09:10] we're going to end up with a stack of delta to get this done [09:10] no way around that i guess, we'll just have to try to unwind it as much as we can when we can [09:14] bah https://bugs.launchpad.net/ubuntu/+source/pygobject/+bug/1679831 [09:14] Launchpad bug 1679831 in pygobject (Ubuntu) "pygobject FTBFS on all arches during zesty test rebuild" [Undecided,New] [09:30] doko, mwhudson, Debian is frozen but it is possible to upload to experimental. I would be happy to commit/sponsor any fixes for DPMT maintained packages. [09:31] mitya57: noted [10:04] mwhudson: about pygobject: maybe there is some DEPRECATED flag in glib2.0 ... or just avoid -Werror, or new pygobject upstream? Laney or seb128 could help [10:05] yeah, avoiding -Werror would probably do the trick [10:05] mwhudson: http://people.canonical.com/~ubuntu-archive/transitions/html/python3.5-6.html [10:12] https://git.gnome.org/browse/pygobject/commit/?id=d005df9645fd5fb2f19bd09384355f45591f1e58 [10:18] Laney: awesome [10:29] mwhudson: feel free to upload that if you want [10:29] I'll probs put the new version in exp at some point and sync it [10:30] Laney: i've just shoved it into my ppa for now, too late in the day for me to be putting things in the archive :-) [10:30] okey pokey [10:46] fossfreedom: hello! [10:47] fossfreedom: could you fix up the bug description of LP: #1661159? I wanted to review the SRU but this one bug isn't ready formally-wise [10:47] Launchpad bug 1661159 in budgie-desktop (Ubuntu) "Budgie Menu Jumps Around In Latest Daily Build" [Undecided,Fix released] https://launchpad.net/bugs/1661159 [10:47] Ah [10:47] I see what just happened there [10:48] fossfreedom: so I see you did one 'master-bug' for all the changes that are included in the SRU, right? [10:54] fossfreedom: I generally prefer if each bugfix has a separate bug with the impact, test case and regression potential fields [10:55] fossfreedom: but seeing that his one bug is rather well documented and issues are rather related, I'll review it as is [10:55] fossfreedom: I'll have to re-upload it before release with a modified changelog since we don't want this additional bug to be 'marked' [10:57] fossfreedom: but for the future SRUs - please include one bug per fix, each one mentioned in the changelog and each one with the SRU template prepared, ok? === sil2100_ is now known as sil2100 [13:13] rbalint: nacc: infinity: So do I need to dig in to your conversation about container fstabs yesterday, or have you resolved it? [13:19] Odd_Bloke: the plan seems to be generating non-broken fstab for lxc images [13:32] hello ubuntu === darkxst_ is now known as darkxst [14:14] Odd_Bloke: i would read it (or the bug) for context === maclin1 is now known as maclin === maclin1 is now known as maclin [16:02] infinity, slangasek: meeting? [16:34] pitti: no snap install cockpit? :) [16:35] infinity: if i understood your convo with pitti / your feedback yesterday, it's not so simple as having an empty fstab on lxd images, right? [16:51] tjaalton: do you know why https://launchpadlibrarian.net/186043623/mesa_10.3.0-0ubuntu1_10.3.0-0ubuntu2.diff.gz wasn't pushed into Debian? [16:52] jbicha: no idea, but the dependency should be more strict now? [16:54] tjaalton: it's still just a recommends in Debian so a dh_auto_test that works in Ubuntu needs to explicitly Build-Depend on libgl1-mesa-dri for the test to work in Debian [16:56] maybe ask on #debian-x [16:56] I don't know why it's just a recommends [16:57] probably could be fixed there too [19:30] nacc: Empty fstab for lxc/lxd is fine because / is mounted externally. [19:30] nacc: But it's not so simple as removing fstab from *all* cloud images, because ones that need to remount-rw on boot won't because systemd hates your freedom. [19:49] infinity: ok, thanks === JanC is now known as Guest59098 === JanC_ is now known as JanC [23:35] cyphermox: it would appear open-iscsi has grown a b-d/dep on libisns-dev/libisns0 (both in universe). Would you recommend trying to undo that dependency (unclear as it's a feature and i'd probably have to undo some documentation changes) or file a MIR? [23:41] given that open-iscsi and open-isns seem to be basically co-maintained, it seems like a MIR makes sense [23:54] nacc: +1 on MIR [23:54] cyphermox: ack, thanks, will file it tmrw [23:55] for that kind of stuff, I'd normally mostly do just a quick look if something can be ripped out, unless it's something very very ugly we'd really prefer not to have in main [23:55] nacc: ack. I'll review the MIR as soon as I see it ;) [23:55] cyphermox: yep, makes sense. Thanks! [23:55] nacc: fwiw, I trust your judgement, do not feel like you must run everything by me for open-iscsi :) [23:56] cyphermox: sure, i was just checking on your opinion for this case :) [23:57] yup [23:57] cyphermox: arguably generic from open-iscsi, but since you had touched it recently :) [23:58] really just a drive-by that went wrong [23:58] heh [23:58] :) [23:58] yeah, that was the longest merge i've had to do in some time :) [23:58] ah?