[02:51] <k_sze> Does Ubuntu 18.04 server edition suffer from the same problem? https://news.ycombinator.com/item?id=20463251
[02:53] <k_sze> I *think* I noticed my Linode instance taking much longer to accept SSH connections after reboot, after upgrading to 18.04, though I'm not sure if that's the cause.
[06:17] <lordievader> Good morning
[07:49] <cpaelzer> good morning lordievader
[13:10] <jamespage> coreycb: swift in eoan-proposed is a bit foobar - the python3-swift has python2.7 module installed
[13:10] <coreycb> jamespage: hrm, ok i'll take a look. should we give a ping to the release team on the RM bugs?
[13:11] <jamespage> yah probably as that's blocking migrations - doko might help us there
[13:16] <coreycb> jamespage: ok
[13:16] <jamespage> coreycb: pinged him in -devel with three bug reports
[13:17] <coreycb> jamespage: thanks, i'll send any others
[14:01] <coreycb> jamespage: i'm not sure why python3-swift is pulling in python - https://paste.ubuntu.com/p/sB2GJtW7kk/
[14:12] <smoser> rbasak: have a minute?
[14:14] <rbasak> smoser: o/
[14:14] <smoser> when we rebase logical delta in git-ubuntu...
[14:14] <smoser> that is actually *not* a rebase, right? but a merge
[14:15] <smoser> right? no history is lost
[14:15] <rbasak> smoser: it's a rebase
[14:16] <rbasak> I think. If I understand you, etc.
[14:16] <rbasak> We did experiment with different commit graphs to represent that.
[14:16] <smoser> hm.
[14:16] <rbasak> But the plan going forward is that we'll just take your rebase commit exactly as-is, with nothing else in the DAG.
[14:16] <rbasak> (no tie to previous)
[14:17] <smoser> ok.
[14:17] <smoser> but the history would still be available because the tag
[14:17] <rbasak> Right
[14:17] <rbasak> However git-ubuntu doesn't care about what you provide as long as it matches.
[14:17] <smoser> of the previous release head *that* logical delta there.
[14:17] <rbasak> If you have fun with the DAG, git-ubuntu won't care.
[14:17] <smoser> so the ubuntu/devel git history is always debian/<something> + new changes
[14:17] <smoser> is that right?
[14:18] <smoser> (where new changes >= 0)
[14:18] <rbasak> As long as some assumptions are correct.
[14:18] <rbasak> We trust the uploader's debian/changelog
[14:18] <rbasak> So it's possible to create disconnected ubuntu/devel git history I think.
[14:18] <rbasak> Let me share my draft spec with you.
[14:22] <rbasak> I suspect the precise answer to your question can be determined from my draft spec, but it might not be trivial to correctly answer in case of the edge cases.
[14:22] <smoser> :)
[14:23] <rbasak> smoser: note that the current implementation doesn't exactly match the spec. Changes are in progress still.
[14:24] <ahasenack> what's DAG?
[14:26] <lordcirth> ahasenack, directed acyclic graph
[14:27] <lordcirth> the data structure that git (and anything else that uses hashed objects to refer to other hashed objects) uses
[14:29] <ahasenack> heavy
[14:29] <ahasenack> thanks
[14:34] <rbasak> ahasenack: specifically, here, I meant the graph of commits, and the upload-tag-supplier's choice of what parents the upload tagged commit has, recursively.
[19:31] <nacc> bryce: hiya!
[19:31] <nacc> bryce: we'll need to be a bit async, but i'm happy to chat a bit while i'm in meetings
[19:32] <bryce> nacc, sure that's fine with me
[19:37] <nacc> bryce: so you're looking at 7.2 -> 7.3, right?
[19:38] <ahasenack> you are happy to chat *while* in meetings? :)
[19:38] <nacc> bryce: so basically, in your ppa, you'd upload a new php-defaults that points to php7.3 rather than 7.2
[19:38] <nacc> ahasenack: i'm a manager now, let's leave it at that :)
[19:38] <bryce> nacc, right
[19:38] <ahasenack> haha
[19:38] <nacc> bryce: and then you'd need to see what will fail it's autopkgtests once you do that
[19:38] <nacc> ideally it won't be too much
[19:39] <nacc> but you'll probably need to bootstrap things like phpunit (without tests)
[19:39] <bryce> nacc, what I'm seeing is that 7.3 is indeed present but it's also detecting 7.2 is available, so attempts to compile against both, and fails when it finds the latter
[19:39] <nacc> bryce: do you have a log / exmaple?
[19:39] <bryce> yeah
[19:39] <bryce> https://launchpadlibrarian.net/433527551/buildlog_ubuntu-eoan-amd64.php-igbinary_3.0.0-1build1_BUILDING.txt.gz
[19:39] <bryce> nacc, also summarized my analysis in the email I sent, maybe a bit tldr
[19:40] <nacc> ack, reading
[19:43] <nacc> bryce: ok, have you reproduced this locally on your machine?
[19:43] <bryce> I've found in building locally in a container, if I force uninstall php7.2-common (and php7.2) the build proceeds fine.  Just wondering if there's a trick to doing the same within a PPA.  But if this doesn't sound at all familiar, perhaps there's something new going on.
[19:43] <nacc> right, so you need to figure out *why* php7.2-common is being pulled in
[19:43] <nacc> php7.3-common shoudl be sufficient
[19:43] <nacc> but you might be missing some other dependency link
[19:45] <bryce> I suspect it's pulling it in via the build-depends for the package in question.  Wondering if maybe phpdefaults needs a conflicts against 7.2 or something?
[19:46] <nacc> let me look at the pkgsrc
[19:46] <nacc> sorry, it's going to take me a second to context switch myself in
[19:46] <bryce> a bunch of packages have this same issue, and same workaround, that haven't had significant packaging changes in quite some time, so guessing it's not just needing the package control tinkered with
[19:47] <bryce> nacc, no prob, really I just wanted to see if this was a known problem for you, but sounds like it's not.  I can dig more on my own.
[19:47] <nacc> you might need to rebuild php-apcu first
[19:47] <nacc> https://launchpad.net/ubuntu/eoan/amd64/php-apcu/5.1.17+4.0.11-1
[19:47] <nacc> it provides php7.2-apcu only currently
[19:47] <bryce> mm, yeah I can try that
[19:47] <nacc> so basically now that you have that rebuilt php-defaults, you have to rebuild a bunch of thigns
[19:48] <nacc> so that they all refer to 7.3 only
[19:48] <nacc> and some thigs will need backports
[19:48] <nacc> although ideally a lot less than in the past, since debian has already transitioned
[19:48] <nacc> oh there's another thing you can reverse-depend check on
[19:48] <nacc> phpapi-20170718
[19:48] <nacc> that's the 7.2 API version
[19:49] <nacc> you don't want anything to reverse-depend on that
[19:49] <bryce> ok
[19:49] <nacc> you should be able to see what string you want for that instead with 7.3
[19:49] <nacc> https://people.canonical.com/~ubuntu-archive/transitions/html/html/php7.3.html
[19:49] <nacc> i assume you know about that?
[19:49] <nacc> that's the pile of things taht will need rebuilds, etc.
[19:50] <nacc> there will be more, because you'll get dep8 failures
[19:50] <bryce> yep, that's the link I've been working from
[19:50] <nacc> but you basically have to boostrap the core first to get to 7.3 (even if it's in universe for now) then transition the whole rest of the stack
[19:50] <nacc> symfony is usually the worst
[19:50] <nacc> but i can help you deal with that eventually
[19:50] <nacc> i can also help sponsor uploads as needed
[19:51] <bryce> nacc, I did notice though that for the 5->7.0 transition you had a much longer package list - 400-some.  But most of those no longer exist, so was curious about the story there
[19:52] <bryce> I've managed to successfully build the majority of what's on php7.3.html, only about half a dozen failures
[19:52] <nacc> bryce: right that was much more painful :)
[19:52] <nacc> bryce: we were ahead of debian (they supported both, not just 7.0) and we had to remove some/many
[19:53] <nacc> bryce: that's great (half dozen is way more tractable)
[19:53] <nacc> bryce: so yeah, i'm guessing if you rebuild & bump php-apcu, php-igbinary will work
[19:53] <nacc> i would go ahead and just do all of those in that same PPA
[19:53] <bryce> ok great
[19:54] <nacc> if tests fail, you can upload once with tests disabled, so it builds, then upload again with tests enabled
[19:54] <bryce> yeah I think I've lucked out between you and debian things are reasonably clean for my first go :-)
[19:54] <nacc> it chews versions, but it also is a way to bootstrap without root archive access
[20:00] <bryce> nacc, thanks, this gives me some directions to chase, I'll touch base next week or so if I have any other questions, thanks again!
[20:07] <nacc> bryce: definitely, i'll be around; i'll try to respond within 24 hours
[23:59] <foo> Is it possible to allow 1 user to restart a systemd server? I normally use sudo ... but I only want them to restart a service (after some files change)... I don't think a server can automatically restart when files echange
[23:59] <foo> hmm