=== bluesabre_ is now known as bluesabre
=== led_ir23 is now known as led_ir22
=== kitterma is now known as ScottK
=== BrAsS_mOnKeY is now known as g2
=== fossfreedom_ is now known as fossfreedom
[07:33] <kklimonda> are there any examples of using debian/[package].install.in and generating it on a fly?
[07:33] <kklimonda> I've found only virtualbox so far
[07:50] <LocutusOfBorg> kklimonda, there are many
[07:50] <LocutusOfBorg> what is the question?
[07:54] <kklimonda> LocutusOfBorg: I'm thinking on how to generate .install files from .install.in during build using snippet from https://wiki.debian.org/Multiarch/Implementation (multiarch is not related, but the way install files is generated seems pretty clean). I've assumed that some target (binary, binary-arch?) will have an implicit dependency on debian/*install files and call target that builds them automatically but that does not seem to be
[07:54] <kklimonda> the case.
[07:54] <LocutusOfBorg> look at llvm-toolchain-5.0
[07:55] <cpaelzer> hmm, did anybody get a new bug number our of submit@bugs.debian.org yet?
[07:56] <cpaelzer> I mean this morning like the last 3 hours or so
[07:59] <cjwatson> kklimonda: Nowadays it's usually easier to use dh-exec, FWIW
[08:01] <LocutusOfBorg> cjwatson, he is talking about something different that multiarch implementation, not sure if dh-exec does the job
[08:01] <cjwatson> LocutusOfBorg: Sure.  But it's worth looking at.
[08:01] <LocutusOfBorg> meh, it is already mentioned in that wiki, I presume he read it all already :)
[08:14] <kklimonda> cjwatson: dh-exec requires debhelper > 9, and should work with trusty, right?
[08:15] <tjaalton> doko: err, you removed dogtag & freeipa from release?
[08:17] <tjaalton> actually, that's fine
[08:17] <tjaalton> one less release to worry about
[08:18] <tjaalton> it's not clear the port to tomcat8.5 is done before 18.04 is out
[08:21] <cjwatson> kklimonda: haven't checked recently, but I'd expect so
[08:22] <LocutusOfBorg> kklimonda, it should be
[10:35] <LocutusOfBorg> does anybody have an answer for this systemd issue?
[10:35] <LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/virtualbox-hwe/+bug/1708315
[10:35] <ubottu> Launchpad bug 1708315 in virtualbox-hwe (Ubuntu) "package virtualbox-guest-utils-hwe 5.0.40-dfsg-0ubuntu1.16.04.1~16.04.3 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,Incomplete]
[10:35] <LocutusOfBorg> Setting up virtualbox-guest-utils-hwe (5.0.40-dfsg-0ubuntu1.16.04.1~16.04.3) ...
[10:35] <LocutusOfBorg> insserv: script virtualbox-guest-utils-hwe: service vboxguest already provided!
[10:35] <LocutusOfBorg> damn they conflict each others
=== jdstrand_ is now known as jdstrand
[13:24] <juliank> rbalint: What's that "apt_1.2.25-rbalint2" I just read about? There is no apt 1.2.25 yet. It will come in about 2 weeks, though, I'd say (not only the u-u fix, but also the "my boot is so slow" and "downloads don't work directly after resume" one). I guess I should push out a new apt 1.5~rc4 now with the final fix for the latter two, though
[13:25] <juliank> My goal was to have the final apt 1.5 for the final beta, and then do 1.4.8 and 1.2.25 releases based on that
[13:27] <juliank> But we could also do an earlier run with just the unattended-upgrade fix if needed
[13:28] <juliank> All I wanted to say is: Don't play with upstream version numbers :D
[13:48] <rbalint> juliank: it is in my ppa we used for testing fixes for LP: #1690980
[13:48] <ubottu> Launchpad bug 1690980 in OEM Priority Project "unattended-upgrades does not block shutdown of system, as it is designed to" [Critical,Triaged] https://launchpad.net/bugs/1690980
[13:49] <juliank> rbalint: I don't see it in your scratch PPAs, but it really should be 1.2.24<something>, not 1.2.25<something>
[13:51] <juliank> increasing upstream version numbers is reserved to upstream :D
[13:51] <juliank> Otherwise it gets confusing ;)
[13:53] <rbalint> juliank: the actual version was 1.2.25~rbalint2 to ensure upgrade, but yes, i should have used 1.2.24<sg>
[13:55] <juliank> There's some other great fixes in 1.5, like the one for bug 1701852, but I think we probably won't see this in xenial, it might be too invasive
[13:55] <ubottu> bug 1701852 in apt (Ubuntu) "(xenial+) apt-cache fails to run if a single sources.list.d entry is not readable" [Low,Fix released] https://launchpad.net/bugs/1701852
[13:57] <juliank> rbalint: In practice it's sort of OK as long as it's lower than ~rc (which land in the apt PPA occasionally)
[13:58] <juliank> in case you want to test that :D
[14:01] <juliank> rbalint: SRUs are currently mostly blocked because 1.4.6~17.04.1 is waiting in zesty-proposed waiting to be released. 1.4.7 is already released in stretch, and should probably be sinked, but we could also just pick the u-u fix on top of that and release that as 1.4.8 (and 1.2.25).
[14:01] <juliank> See bug 1702326
[14:01] <ubottu> bug 1702326 in apt (Ubuntu Zesty) "New microrelease 1.4.7 for zesty" [Medium,Triaged] https://launchpad.net/bugs/1702326
[14:02] <juliank> I guess it mostly depends on how fast we want to push out the apt-daily timer changes
[14:04] <juliank> xnox: Did you hear anything about the boot speed situation relaxing in artful now? For most boots (where we don't need to "catch up") it already should have, but with the next apt upload, all boots should be fixed.
[14:04] <juliank> You mentioned reports about slow boots yesterday or the day before, but since there are no bugs about that in LP, I figured it's probably something internal
[14:05] <xnox> juliank, there are bugs about it.
[14:05] <xnox> juliank, they are all filed against src:systemd
[14:05] <juliank> xnox: oh
[14:05] <xnox> juliank, however i will not look into that this week =/ due to other things
[14:06] <juliank> Oh well, I'm building 1.5~rc4 now, it should sync later today
[14:06] <juliank> At least I will, if I find my smart card
[14:07] <juliank> and if I can get gpg to work again
[14:08] <juliank> It's like a wild loop of killing scdaemon and running gpg --card-status until it works
[14:08] <Unit193> Check out in the car.
[14:09] <juliank> so, the, like, 20th try seems to have worked :)
[15:48] <rbalint> juliank: looking at apt 1.4.6~17.04.1's changelog i don't see an SRU LP bug where you could provide the verification feedbeck thus it may be stuck in https://wiki.ubuntu.com/StableReleaseUpdates#Procedure step 6.
[15:49] <juliank> rbalint: I know there's no overall bug, but we have lots of tiny ones, and most of the changelog entries are actually just fixes up for one of them.
[15:50] <juliank> rbalint: It was stuck until shortly because one bug was not verified, and yesterday sbuild needed to go in first to fix an autopkgtest regression.
[15:50] <rbalint> juliank: ok, it was not clear why apt was stuck in -proposed
[15:51] <juliank> And I think it's getting a bit close to weekend now to release an apt SRU of this impact
[15:52] <juliank> So I was thinking I'd push hard again on Monday
[15:52] <juliank> or rather s/push hard/ask/
[15:53] <juliank> rbalint: The weird part is that the same changes are already in xenial-updates
[15:53] <juliank> Because xenial is more important :D
[15:54] <rbalint> juliank: maybe getting SRU Team's agreement in advance to release on Monday could work, too
[15:56] <juliank> I mean, it's all verified, (almost?) all of it is in xenial, and I'm here to answer any remaining questions from 10:00 to 22:00 UTC every day
[15:56] <juliank> slangasek did the sbuild stuff yesterday at least
[15:58] <juliank> See, I'm not entirely sure about close-to-weekend SRUs. IIRC, something was up with Thursday.
[15:58] <juliank> There's no written policy on days where no updates are released AFAIK
[15:59] <juliank> or maybe it was just security updates?
[15:59] <slangasek> the policy is that we don't release SRUs on Friday unless the person releasing is willing to come in on a Saturday
[15:59] <slangasek> apt+unattended-upgrades can now be released
[16:00] <juliank> yay!
[16:00] <slangasek> (done)
[16:00] <juliank> slangasek: thanks
[16:00] <nacc> i thought that used to be on the SRU page itself, but I can't find it anymore
[16:02] <rbalint> slangasek: thanks!
[16:03] <rbalint> juliank, slangasek: the next round can be the stability fixes for u-u with apt's cooperation
[16:04] <juliank> rbalint: I'd put them on top of the https://tracker.debian.org/news/856567 release, does that sound fair?
[16:05] <juliank> It should have been in proposed a month ago basically
[16:06] <rbalint> juliank: thanks, this is perfect
[16:06] <nacc> is there a programmatic way to ask dpkg-buildpackage what files it will create, if successful (or have it clearly output what files it did create)?
[16:07] <juliank> Should we pull in this too? https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=11417c1058e1b8441ee8f30f948e854b7a6ce89e - That's the entry to more changes affecting apt-daily ordering, it already solves most problems with stalled boots by just moving the dependencies from the timer to the service (which might not start during boot, hence not pull in the network-online.target which causes weird behaviour in rc.local)
[16:08] <juliank> And probably bug 1613184
[16:08] <ubottu> bug 1613184 in apt (Ubuntu) "method mirror broken at 1.3" [Medium,Fix released] https://launchpad.net/bugs/1613184
[16:08] <juliank> mirror just segfaults...
[16:08] <juliank> Let me go cherry-picking
[16:10] <juliank> I don't have a LP bug for the ordering though, but I'm not sure what you'd want to verify there
[16:12] <juliank> Oh I guess we should pull in bug 1697120 too
[16:12] <ubottu> bug 1697120 in apt (Ubuntu) "artful's apt-file and aptitude complains about Ubuntu sources.list" [Medium,Fix released] https://launchpad.net/bugs/1697120
[16:12] <juliank> It simply wraps the warning in a		if (T->find("legacy") == std::string::npos)
[16:17] <juliank> So far against 1.4.7: https://anonscm.debian.org/cgit/apt/apt.git/diff/?h=1.4.y&id=1.4.y&id2=1.4.7
[16:19] <nacc> cjwatson: I was re-reviewing LP: #1687059, I believe you originally pointed this out to rbasak and myself. But then I'm reading `man dpkg-buildpackage` (http://paste.ubuntu.com/25528503/) and I'm wondering if a) we don't need actuall need the b-d for clean? or b) if `man dpkg-buildpackage` is wrong?
[16:19] <ubottu> Launchpad bug 1687059 in usd-importer ""git ubuntu build-source" does not run debian/clean" [High,Triaged] https://launchpad.net/bugs/1687059
[16:19] <nacc> slangasek: --^ you might also have an opinion/relevant knowledge
[16:21] <cjwatson> nacc: I'm not sure where that assertion comes from.  At a minimum, the clean target nearly always requires debhelper, which (regardless of one's opinion on whether it should be) is not build-essential, and it often also requires other build-dependencies for extra helpers.
[16:22] <juliank> I guess we let xnox and slangasek decide whether to pull in the move of Wants,After=network-online.target from apt-daily.timer to apt-daily.service. As I wrote, this should solve a lot of the slow boot problems because network-online is not pulled in anymore unless we skipped an apt update while the machine was offline. Then we can let the more improved variant test in artful for some time.
[16:22] <nacc> cjwatson: yeah that's what I figured too, based upon what I've seen
[16:22] <nacc> cjwatson: thanks for the input!
[16:23] <cjwatson> nacc: I think this is a slightly mangled version of the assertion that if you have a tree that hasn't been built then you can use dpkg-source to construct a source package *without* calling the clean target.  (There exist packages that use the clean target to generate files that have to be in the source package, but that wouldn't be a problem if the importer has taken a source package as its ...
[16:23] <cjwatson> ... input.)
[16:23] <nacc> cjwatson: right, I could see that
[16:24] <cjwatson> Robie's suggestion there seems reasonable to me.
[16:24] <nacc> cjwatson: yep, i think that's what we're going to end up doing (it's nice to have anyways)
[16:27] <nacc> cjwatson: smoser has already heckled us for trying to do buildd locally basically :)
[16:28] <cjwatson> I mean, I agree that it's awkward that clean is the way it is ...
[16:40] <juliank> I'm just writing a bug to track the network-online move
=== JanC is now known as Guest39146
=== JanC_ is now known as JanC
[16:43] <slangasek> juliank: oh, untangling apt-daily from boot in the common case sounds like a valuable improvement
[16:44] <juliank> slangasek: Added https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1716973 for that
[16:44] <ubottu> Launchpad bug 1716973 in apt (Ubuntu Zesty) "Don't pull in network-online.target in apt-daily.timer" [High,Triaged]
[16:44] <slangasek> cool
[16:45] <juliank> We can then take the more complete fix, which also makes stuff more reliable at resume, in a month
[16:45] <rbalint> slangasek: we had a few discussions with mvo regarding unattended-upgrades. how would you feel about full backports of 0.96ubuntu1 to older releases instead of cherry-picking most of the fixes?
[16:46] <rbalint> slangasek: this seems to me safer and easier to maintain in the long run
[16:47] <powersj> cyphermox: looks like your fix went in, ISOs are green again, many thanks!
[16:47] <jbicha> why is network-online required for getty and gdm?
[16:50] <juliank> jbicha: It's not, rc-local.service is
[16:50] <jbicha> what is rc-local and why does that need network-online?
[16:50] <juliank> jbicha: But on debian & ubuntu, we have an override at the moment where rc-local.service specifies After=network-online.target
[16:50] <slangasek> rbalint: I would have to look at specifics to give a definitive answer, but in principle I'm not opposed
[16:51] <jbicha> (boot took several minutes yesterday when I didn't have a good network connection)
[16:51] <juliank> jbicha: See https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1451797 for the discussion. pitti and mbiebl reached consensus to remove that with a warning in NEWS in #debian-system yesterday.
[16:51] <ubottu> Launchpad bug 1451797 in systemd (Ubuntu) "rc.local should require network-online.target" [Low,Fix released]
[16:51] <slangasek> rc-local is a legacy interface that lets users run miscellaneous code at end-of-boot.
[16:51] <juliank> indeed.
[16:52] <juliank> And if /etc/rc.local is present, the service is enabled and will be ordered after network-online.target if something else pulls it in.
[16:52] <slangasek> if we stopped shipping /etc/rc.local by default, or made it non-executable by default, there would be no penalty
[16:52] <slangasek> ConditionFileIsExecutable=/etc/rc.local
[16:52] <juliank> Which unfortunately I did in apt's timer.
[16:52]  * juliank does not have /etc/rc.local
[16:52] <juliank> Same applies if you have a legacy init script using $network
[16:53] <slangasek> maybe we no longer create rc.local and this only affects users who upgraded
[16:53] <juliank> it might, who knows...
[16:53] <juliank> On Debian, initscripts seems to create the file in postinst
[16:54] <juliank> if that's not installed anymore, than there should be no file
[16:54] <slangasek> yeah, I only have it on Ubuntu systems where initscripts is or has been installed
[16:54] <jbicha> I believe I am using a fairly clean artful install from 2 weeks ago
[16:54] <slangasek> we should consider cleaning that up on upgrade
[16:54] <jbicha> initscripts is not installed here
[16:55] <slangasek> jbicha: but if your system was a previous release and then upgraded, you did have initscripts installed before.
[16:55] <slangasek> and /etc/rc.local is not (can't reasonably have been) a conffile
[16:56] <jbicha> I don't have an /etc/rc.local ?
[16:57] <juliank> slangasek: I'm afraid there is no way to clean this up? But when the rc-local drop-in unit is gone, this won't happen anymore anyway
[16:57] <slangasek> jbicha: then rc-local.service shouldn't have slowed down your getty, because ConditionFileIsExecutable=/etc/rc.local
[16:57] <slangasek> juliank: sure there is a way; we have ubuntu-release-upgrader for quirks
[16:58] <juliank> slangasek: Yeah, well, but you have to check that it was not modified, whatever that means
[16:59] <juliank> "Oh, I commented out my rc.local for the upgrade, but now it's gone"
[16:59] <juliank> "there was important stuff in there"
[16:59] <slangasek> checksum tools are great ;)
[17:01] <slangasek> but also, I see rc-local to be 'After=network.target', which is NOT network-online
[17:01] <slangasek> oh you said there was an override
[17:01] <slangasek> ignore me
[17:06] <slangasek> juliank: LP: #1716979
[17:06] <ubottu> Launchpad bug 1716979 in ubuntu-release-upgrader (Ubuntu) "clean up unmodified /etc/rc.local on upgrade" [Undecided,New] https://launchpad.net/bugs/1716979
[17:07] <juliank> yay
[17:08] <slangasek> and I've subscribed xnox because I know his weakness for fixing such things
[17:08] <slangasek> ;)
[17:08] <juliank> lol
[17:10] <xnox> slangasek, t...
[17:10] <xnox> slangasek, true
[17:13] <slangasek> :D
[17:27] <slangasek> xnox: what's the systemd task on that bug?  are you thinking to have systemd remove /etc/rc.local instead of u-r-u?
[17:28] <juliank> https://paste.ubuntu.com/25528880/
[17:28] <juliank> ^ apt 1.4.7 to 1.4.8
[17:28] <juliank> I'll now ask the RT over in Debian what they think
[17:29] <juliank> It will hit zesty either way tomorrow :D
[17:30] <xnox> slangasek, yes
[17:30] <slangasek> xnox: ok; it should certainly be an either-or, so let's close the other task
[17:31] <slangasek> (done)
[17:31] <juliank> I guess something should remove initscripts too, or is that already handled?
[17:31] <slangasek> nothing conflicts with it, but it may get autoremoved by u-r-u
[17:34] <juliank> If someone wants to track the Debian 1.4.8 stretch update, here's the bug: https://bugs.debian.org/875695
[17:34] <ubottu> Debian bug 875695 in release.debian.org "stretch-pu: package apt/1.4.8" [Normal,Open]
[17:44] <juliank> slangasek: Hmm, does something break if changes has Distribution: zesty-updates? Apparently syncpackage --no-lp needs that, otherwise it packs all changes against the original 1.4?
[17:45] <juliank> Although, I can just edit that
[17:45] <cjwatson> It's either mapped to zesty-proposed or rejected, I forget which
[17:46] <cjwatson> I'd probably edit it
[17:47] <juliank> Yeah, I also had to edit Changed-By and the changelog anyway, it was picking up 1.4.6 again because well, we uploaded it as 1.4.6~17.04.1
[17:48] <juliank> And Changed-By was root, because apparently my schroot is messed up
=== JanC_ is now known as JanC
=== leitao_ is now known as leitao
=== nacc_ is now known as nacc
[20:45] <bmw> rbasak: what's the status of getting the Certbot packages for Xenial into the proposed repo?
[20:46] <slangasek> bmw: AIUI https://bugs.launchpad.net/ubuntu/xenial/+source/python-letsencrypt/+bug/1640978 shows they're all in -proposed and waiting for testing feedback
[20:46] <ubottu> Launchpad bug 1640978 in python-certbot-nginx (Ubuntu Zesty) "[SRU] Backport letsencrypt 0.14.2" [Undecided,Fix committed]
[20:46] <nacc> bmw: yeah, i think it's all pending on testing and baking long enough
[20:46] <nacc> bmw: note rbasak is out all this week and some of next
[20:59] <bmw> at least when using apt, I don't see any certbot or letsencrypt packages in the proposed repository
[20:59] <bmw> I see python-acme, but not the main client and the Apache and Nginx packages
[20:59] <nacc> !info python-certbot xenial-proposed
[20:59] <ubottu> Package python-certbot does not exist in xenial-proposed
[21:00] <nacc> bmw: hrm, rmadison says they are there
[21:00] <nacc> oh wait
[21:00] <nacc> only the source
[21:00] <bmw> rbasak told me a couple weeks ago there a build failure for the old letsencrypt packages that he was going to look into
[21:01] <bmw> that's probably what's going on
[21:01] <nacc> ah they are still waitinng to be accepted
[21:01] <nacc> https://launchpad.net/ubuntu/xenial/+queue
[21:01] <nacc> slangasek: --^ i see a message from you that they were accepted though
[21:05] <slangasek> ah, are the binaries still in NEW?
[21:05] <slangasek> only for python-certbot
[21:05] <slangasek> accepted
[21:06] <nacc> slangasek: yeah, thankns
[21:07] <Unit193> Oh, my backport of 0.11.1 is pretty old.
[22:01] <cyphermox> powersj: thanks for the feedback