=== salem_ is now known as _salem
=== yuning-afk is now known as yuning
[05:36] <cpaelzer> good morning
[07:03] <pitti> infinity: right, I remember again -- we made the libpam-systemd a recommends instead of a depends to keep out dbus etc. from being quasi-essential
[07:03] <pitti> infinity: but now that the entire init dropped out of essential, that's actually okay and desirable
[07:04] <pitti> Good morning
[07:04] <infinity> pitti: I made all the changes, FYI.  I'm going to look at fallout for "weird" images (people who don't ship minimal/standard, because reasons) when I wake up and fix any oddities.
[07:09] <pitti> cyphermox: this morning when I tried to boot my laptop, EFI refused to boot because it could not verify the signature; I disabled secureboot for now, but I suppose that Should Not Happen™; how can I debug this?
[07:09] <pitti> cyphermox: (yakkety du jour)
[07:28] <pitti> mdeslaur, jdstrand: IIRC you started working on loading apparmor profiles in systemd directly, like it does with SELinux, to get rid of the apparmor rcS init.d script and the associated race conditions, right?
[07:29] <pitti> mdeslaur, jdstrand: I was curious what the status of that was, as Debian is trying to get rid of rcS init.d scripts (they tend to cause problems)
[07:33] <RAOF> Hm. *Some* update appears to have broken the Mir build. With weird template linker errors!
[07:43] <pitti> urgh, what happened to prodstack swift
[08:02] <Laney> mapreri: was away for a few days; will look soon
[09:04] <six86> Hello. I can't manage to create a bootable stick with my preseeded *.iso file... It works fine in a VM and Also creating a bootable stick from the orginal ubuntu image works fine
[09:37] <pitti> tjaalton: please see my followup/question in bug 1577735
[09:37] <ubottu> bug 1577735 in libdrm (Ubuntu Xenial) "Add missing SKL/BXT PCI-ID's" [Medium,Fix committed] https://launchpad.net/bugs/1577735
[09:48] <rbasak> pitti: I see systemd 230 is in Yakkety. What are the plans for KillUserProcesses? Does the server team need to consider our view on the screen/tmux use case? That is, will there be a behaviour change in Yakkety?
[09:48] <pitti> rbasak: the change is already reverted in the packaging git, so 230-2 will be back to the 229 behaviour
[09:50] <rbasak> pitti: ah, thanks.
[09:51] <infinity> pitti: Can we get that out sooner rather than later, to avoid the impending whine-fest (and people like me who've been sprinkling config snippets around already...)
[09:52] <pitti> infinity: yeah, can do; it'll be stuck in -proposed for a while though, as autopkgtesting is currently blocked on swift being down
[09:52] <pitti> but people could get it from -proposed then
[09:52] <infinity> pitti: Whee.  But yeah, better than nothing.
[09:53] <infinity> pitti: Is there ongoing upstream discussion about the madness, or are downstreams just expected to fork that bit forever?
[09:53] <pitti> infinity: there are upstream discussions, yes
[09:54] <pitti> e. g. upstream bugs for screen/tmux
[09:54] <pitti> but until that has settled down, we'll just revert to the old behaviour
[09:54] <pitti> infinity: it's just a ./configure option, not that much of a fork
[09:54] <pitti> and given how much opposition it met, I wouldn't be surprised if the default flips back in 231 upstream too
[09:54] <infinity> pitti: So, in the new world order, how does a user intentionally detach a process so it doesn't get whacked?
[09:55] <lifeless> infinity: there's a systemd thing you can call
[09:55] <infinity> Ick.
[09:55] <pitti> infinity: that's still being discussed actually; IMHO it'd be cleanest to start a PAM session, or use systemd-run to start a new scope (like a "mini" session)
[09:55] <rbasak> You have to enable lingering first AIUI? Or is that not necessary?
[09:55] <pitti> but I haven't seen a really satisfying answer to that
[09:55] <pitti> yes, but lingering is global
[09:56] <pitti> if you enable it, all other leftover processes from your session will survive too
[09:56] <rbasak> I see. So one or the other will suffice?
[09:56] <pitti> this is still a problem at the conceptual level, before we even can discuss technical solutions
[09:56] <infinity> pitti: None of that would satisfy the simple use case of "./long-job > log 2>&1 &" oh crap, need to logout "disown && logout".
[09:56] <infinity> pitti: But I guess we'll see where it goes.
[09:57] <infinity> Breaking UNIX, one use-case at a time.
[09:57] <pitti> we either accept tons of leftover processes, or change the ones that are deliberately long running
[09:57] <pitti> infinity: e. g. I wouldn't expect ./long-job & to survive on logout
[09:57] <pitti> that'd go straight against my idea of logging in and out
[09:57] <rbasak> Or we fix the bugs so processes exit when they should?
[09:57] <pitti> screen and tmux I can understand
[09:58] <pitti> but, as said, we first need to define what we actually want before discussing implementation
[09:58] <infinity> pitti: I suppose one could write a souped-up disown that moves the process out of the cgroup instead of just unparenting it?
[09:58] <pitti> and everyone seems to want something different
[09:58] <pitti> infinity: yes, that's more or less what systemd-run or a new PAM session would do
[09:58] <infinity> pitti: Well, but post-run is the key.
[09:59] <infinity> pitti: Having to think of this in advance is a massive behavioural change for old farts. :P
[10:00] <pitti> this is a prime example for https://xkcd.com/1172/
[10:00] <infinity> I disagree entirely.
[10:00] <pitti> I think it's a bug and counter-intuitive that session processes survive logout, you consider it a feature, one of us will always be unhappy :)
[10:00] <rbasak> pitti: do you consider an ssh disconnect a logout?
[10:00] <infinity> rbasak: Yes.
[10:01] <infinity> Anything that will result in killing your shell (or base process) is a logout.
[10:01] <pitti> rbasak: I'd say yes
[10:01] <infinity> disown exists specifically to unparent processes from the controlling shell, so the HUP sent on disconnect isn't propagated.
[10:01] <infinity> It's a feature, not a misfeature.  It's not spacebar heating. :P
[10:02] <pitti> yes, I can close the terminal and the process goes on
[10:02] <infinity> And HUP has a very specific meaning, and has done for decades.  Again, I don't think it's sane to say "actually, that should have been KILL all along".
[10:03] <pitti> anyway, 230-2 building, and I'll upload it to sid then; should get autosynced to y in half a day or so
[10:03] <infinity> As in, some things intentionally deamonize on HUP, so they don't get rudely interrupted by a remote disconnect.
[10:04] <infinity> In fact, even apt does that. :P
[10:04] <infinity> (To avoid half-done dpkg runs)
[10:06] <infinity> pitti: Anyhow.  I agree that making tmux/screen spawn new login sessions would be a workaround for the problem, but I disagree that remapping HUP to KILL for disconnects is in any way POSIX/UNIX friendly. :P
[10:06] <infinity> And, honestly, it'll just lead me to set my shell to /usr/bin/tmux
[10:07] <infinity> Which then gives me the same behaviour I had before, and renders the new world order a no-op.
[10:07] <pitti> infinity: I don't actually expect it to become a new world order anytime soon
[10:08] <pitti> this was an idea, it failed, it gets reverted, maybe the next concept and iteration works better
[10:13] <tjaalton> pitti: adding a handful of missing pci-ids so that compiz works properly shouldn't break anything
[10:14] <pitti> tjaalton: maybe, but it still needs to be confirmed that the package upgrades and runs correctly, and that X still works with the -proposed package
[10:14] <pitti> tjaalton: we've had SRUs of binutils and gcc, for example
[10:14] <tjaalton> pitti: well I copied a comment from the private bug
[10:16] <pitti> tjaalton: that comment makes little sense
[10:16] <tjaalton> huh?
[10:16] <pitti> tjaalton: 2.4.67 *is* the version in t/x-proposed
[10:16] <pitti> if it's only fixed by .68, then that needs to be SRUed as well, that's only in y
[10:16] <tjaalton> well yes the version in the comment is wrong
[10:16] <pitti> and it also doesn't say whether that's t or x
[10:16] <tjaalton> no, it just needs the pci-id's that the rest of the stack already has...
[10:16] <tjaalton> (kernel, mesa)
[10:17] <tjaalton> sigh
[10:17] <tjaalton> if you insist, I'll ask chih to comment himself
[10:18] <pitti> well, I insist on someone testing the actual package from -proposed and confirming the version and that it still works
[10:18] <tjaalton> pitti: and the only diff between t/x is the version number
[10:19] <pitti> tjaalton: doesn't matter -- we are looking for regressions here; confirming that it fixes the bug is nice, but not actually the first priority
[10:19] <pitti> but if the xenial-proposed one misbuilt because of our gcc or binutils SRU, we want to know this
[10:19] <pitti> just trusting "the diff is simple" isn't sufficient, and has led to catastrophes more than once
[10:20] <tjaalton> have you even looked at the diff?
[10:20] <pitti> the diff is *completely* irrelevant
[10:20] <tjaalton> it's completely relevant
[10:20] <tjaalton> this is not gcc
[10:20] <tjaalton> or binutils
[10:20] <pitti> (well, it's not in geneal, but the diff doesn't change the fact that we need to test teh proposed package)
[10:20] <tjaalton> and it was tested, I don't have the hw for that
[10:21] <pitti> testing for regressions on any intel hardware is fine
[10:21] <pitti> it's more important that it doesn't regress on existing systems than that it actually fixes the bug
[10:21] <pitti> we can always do a followup SRU if we missed a PCI ID, but we don't want to leave existing systems with a broken X
[10:22] <pitti> sorry, but just saying "it'll work without testing" for a compiled library is not acceptable
[10:31] <Saviq> xnox, hey, could you help with bug #1585517 please - between vivid and xenial we can no longer cross-build unity8 again - I've tried :any, :native for the two B-Ds, but I suppose that's wrong (and it didn't work anyway...)
[10:31] <ubottu> bug 1585517 in python-setuptools (Ubuntu) "Can't install for cross-building" [Undecided,New] https://launchpad.net/bugs/1585517
[10:50] <mapreri> Laney: ok, don't worry :)  Thanks for prodding the thing!
[10:50]  * mapreri now waits for the mirror to updates
[10:50] <mapreri> -s
[11:03] <mdeslaur> pitti: jdstrand can confirm, but I don't believe we ever started that work, as the init script worked ok and we got busy  doing other stuff
[11:04] <pitti> mdeslaur: thanks, what I thought; the usual fate of makeshift solutions which work well enough :)
[11:04] <pitti> *cough* ddeb-retriever *cough*
[11:04] <mdeslaur> heh, yeah :)
[11:18] <Mirv> I think qtchooser  qt4-x11 qtbase-opensource-src could migrate to release pocket, together, but some hinting would be definitely needed still.
[11:19] <Mirv> there are also "Test in progress" ones that seem to be ghosts - kactivities under qt4-x11, ktnef under qtbase-opensource-src (others are always failed ones)
[11:22] <Mirv> some KDE update remaining autopkgtest breakage is there, but they don't completely go away too soon.
[11:45] <xnox> Saviq, commented.
[11:45] <Saviq> xnox, thanks
[11:45] <xnox> but it's been a while since i did multi-arch fixes
[11:45] <mdeslaur> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Xenial (16.04) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur
[11:45] <xnox> so maybe barry and/or slangasek would be best to doublecheck the assertions I stated on bug #1585517
[11:45] <ubottu> bug 1585517 in python-setuptools (Ubuntu Xenial) "Can't install for cross-building" [Undecided,New] https://launchpad.net/bugs/1585517
=== hikiko is now known as hikiko|ln
=== JanC is now known as Guest93383
=== JanC_ is now known as JanC
=== _salem is now known as salem_
=== hikiko|ln is now known as hikiko
[13:05] <smoser> pitti, "cloud-init hash seed issue" ? you mean bug 1584147 right ?
[13:05] <ubottu> bug 1584147 in cloud-images "cloud-init hangs on boot as Python waits for sufficient randomness to start" [High,Confirmed] https://launchpad.net/bugs/1584147
[13:53] <tyhicks> pitti (FYI mdeslaur & jdstrand): the hard work is done - the parser code that handled policy loads has been moved into libapparmor with a nice simple interface for systemd to use
[13:53] <tyhicks> pitti: what we didn't get to are the systemd changes to use libapparmor
[13:53] <mdeslaur> tyhicks: oh, cool
[13:54] <mdeslaur> that should be reasonable trivial
[13:54] <mdeslaur> reasonably
[13:54] <pitti> smoser: right, that; that causes looong boot times (and adt-run timeouts; I could bump them, but it's still a nuisance)
[13:57] <smoser> pitti, o'
[13:57] <smoser> i'm open to suggestions
[13:58] <pitti> tyhicks: ah, thanks; that sounds a lot better indeed
[13:58]  * pitti still in meeting, sorry for lag
[14:10] <pitti> yay, swift is back, re-enabling the autopkgtest minions
=== davidcalle is now known as davidcalle_x86_6
=== davidcalle_x86_6 is now known as davidcalle
[14:49] <infinity> pitti: Is this a misconfiguration in scalingstack, by not providing virtio_rng to the guests?
[14:50] <pitti> infinity: could very well be, yes; the RNG takes aaages to initialize
[14:50] <infinity> pitti: (Not that I'm agreeing with the new python behaviour, it seems a bit daft, but not starting instances with zero entropy certainly wouldn't hurt)
[14:50] <pitti> *nod*
[14:52] <infinity> pitti: Well, s/a bit daft/completely daft/ really.  Given the irresponsible people tend to fork hundreds of python scripts as if it were as cheap as POSIX shell, sucking your RNG dry when you might not even end up using it seems batty.
[14:53] <pitti> infinity: I also don't quite see why one needs cryptographically secure hash randomization
[14:53] <infinity> s/Given the/Given that/
[14:53] <pitti> in most programming languages hashes have a reproducible order
[14:54] <pitti> I did read the upstream report about the resource exploits with CGI arguments, but this appears to be a bit silly
[14:54] <infinity> pitti: There's certainly that argument too, yes.  Though, I can certainly firmly place myself on both sides of that fence.  But I'd prefer, as a programmer and sysadmin, to make that decision per call, not have it made for me.
[14:54] <pitti> if your CGI program allows me to specify a thousand GET arguments, then making that more efficient rather than just preventing so many args in the first place isn't a good fix
[14:55] <infinity> pitti: I have zero hope of influencing python upstream, however, but nudging IS/LP to see if you can get some virtual rng might at least get you past the hump.
[14:56] <infinity> I do wish we lived in a world where reliable randomness was a thing all computers had in abundance.  Can't quite sort out how we've failed so miserably to do that by now.
[14:57] <mdeslaur> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Xenial (16.04) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[14:57] <pitti> infinity: at first the upstream bug report sounded like a wontfix, but I think they were pondering adding a NOBLOCK flag to the getrandom call
[14:58] <infinity> pitti: Yeah, I read the whole thread.  Still seems a bit up in the air, and the behaviour still seems incorrect (to me), even with the NOBLOCK, but meh.
[14:58] <infinity> If I want cryptographically awesome randomness, I should ask for it, I think assuming it (and, indeed, draining my RNG to seed it on every python call) is silly.
[14:58] <infinity> But, whatever.  One more reason for me to not be a Python fan.  As if I didn't have enough of those.
[14:59] <pitti> I actually am, all the more reason to fend off insanity :)
[15:00] <infinity> I suppose it could be worse, they could make /usr/bin/python3 dial-up Amazon and order a hardware fuzz dongle, and block until you plug it in.
[15:00] <pitti> "throw a dice 200.000 times and type in the results"
[15:00] <infinity> "No cheating, we've turned on your webcam to make sure."
[15:04] <infinity> Hey neat, I just tore open my stomach.
[15:04] <infinity> For some value of "neat".
[15:04] <infinity> Also, ow.
[15:05] <infinity> (afk)
[15:17] <cjwatson> eek?
[15:25] <mdeslaur> infinity: are you ok?
[15:27] <rbasak> "reliable randomness was a thing all computers had in abundance."
[15:27] <rbasak> That exists. It's called flaky hardware :-P
=== ssweeny is now known as ssweeny-lunch
=== ssweeny-lunch is now known as ssweeny
[21:22] <smoser> anyone else seeing ubuntu connection failures ?
[21:22] <dobey> everyone is yes
[21:22] <smoser> k
[21:22] <smoser> thanks
[21:23]  * smoser out
=== salem_ is now known as _salem
[22:14] <jbicha> why is https://launchpad.net/debian/+source/vlc missing the stretch branch (2.2.2-6 or the current 2.2.3-2) ?
[22:38] <nacc> jbicha: https://launchpad.net/debian/+source/vlc/+publishinghistory
[22:38] <nacc> jbicha: i'm guessing that pacakge isn't actually using lp for development, so it might be that someone just hasn't made a tracking branch appropriately
[22:38] <nacc> jbicha: i'm not sure how those work in lp.net/debian, maybe ask on #launchpad
[22:41] <jbicha> I believe it has the result that Ubuntu isn't auto-syncing vlc from Debian
[22:43] <cjwatson> nacc: no that's not a "using LP for development" thing
[22:43] <cjwatson> will check after call
[22:44] <nacc> cjwatson: oh ok
[22:44] <cjwatson> but stretch also isn't pertinent to auto-sync
[22:44] <nacc> jbicha: yakkety is synced?
[22:44] <cjwatson> sid is
[22:44] <nacc> well, with a rebuild
[22:44] <nacc> 2.2.2-6 from unstable, it seesm
[22:44] <cjwatson> https://launchpad.net/debian/+source/vlc/+publishinghistory has it as deleted for some reason
[22:45] <nacc> weird, and without an attribution as to who did it?
[22:45] <cjwatson> it's entirely automatic
[22:45] <cjwatson> checking logs
[22:46] <nacc> ok, i thought even then it said by the bot or something
[22:48] <cjwatson> nacc: not for /debian, that's more like reflecting external status than a deletion as such
[22:49] <cjwatson> it could be deleted by ~janitor I guess but it wouldn't add any useful information
[22:49] <cjwatson> jbicha: so in this case the problem is apparently that the dpkg-dev we're using can't unpack sid's vlc
[22:49] <nacc> cjwatson: ok, i must be misremembering
[22:50] <cjwatson> dpkg-source: error: unrecognized file for a v2.0 source package: vlc_2.2.3.orig.tar.xz.asc
[22:50] <cjwatson> damnit
[22:51] <cjwatson> https://lists.debian.org/debian-dpkg/2016/05/msg00041.html and thread
[22:51] <jbicha> I hit that with bzr earlier today, bug 1587659
[22:51] <ubottu> bug 1587659 in bzr-builddeb (Ubuntu) "bzr-bd chokes if tarball .asc in directory" [Undecided,New] https://launchpad.net/bugs/1587659
[22:52] <cjwatson> separate issue
[22:52] <jbicha> right
[22:52] <cjwatson> I'm pretty cross at the excessively rapid introduction of this feature
[22:53] <cjwatson> jbicha: can you file a bug against Launchpad itself about this?  we're clearly forced to do something
[22:53] <jbicha> yes
[22:54] <cjwatson> it'll probably also require some other changes to LP beyond the dpkg backport
[22:54] <cjwatson> SourcePackageFileType for starters
[22:55] <cjwatson> in fact we might need those first, would need to check
[22:57] <cjwatson> ... yup, that sure looks like it'd be an IntegrityError or similar if we try to insert it without knowing its file type
[22:59] <jbicha> filed bug 1587667
[22:59] <ubottu> bug 1587667 in Launchpad itself "Import from Debian fails for source packages with included tarball .asc" [Undecided,New] https://launchpad.net/bugs/1587667
[23:01] <cjwatson> thanks.  will try to get to it ASAP