=== JanC is now known as Guest79577
=== JanC_ is now known as JanC
[01:27] <mwhudson> are there any archive admins about? maybe wgrant?
[01:27] <wgrant> mwhudson: Hi
[01:28] <mwhudson> wgrant: there is a ridiculous circular dependency mess with some golang packages in zesty-proposed
[01:28] <mwhudson> wgrant: i have a plan, but it requires deleting two packages from -proposed
[01:28] <wgrant> mwhudson: I can do it as long as it requires no manual britney fiddling.
[01:28] <mwhudson> (my plan is fairly ridiculous too but i've tested it locally as much as i can)
[01:29] <mwhudson> wgrant: just the package deletions is all i need
[01:29] <mwhudson> wgrant: golang-goolge-x-oauth2 and golang-google-grpc
[01:29] <wgrant> Can you explain the problem and your crazy plan?
[01:30] <wgrant> mwhudson: Neither of those packages exist, even with the typo fixded.
[01:30] <mwhudson> wgrant: they are source packages
[01:30] <wgrant> Oh the second one does if I don't typo it.
[01:30] <wgrant> What's the proper name of the first one?
[01:30] <mwhudson> and it's golang-golang-x-oauth2 sorry
[01:31] <wgrant> Aha
[01:31] <mwhudson> g-g-x-oauth2 is not migrating because it depends on a newer version of golang-google-cloud-compute-metadata-dev
[01:31] <wgrant> golang-google-grpc hasn't built
[01:31] <cyphermox> why remove though, can't you upload/copy/whatever what's missing?
[01:32] <mwhudson> which is in depwait because it depends on a newer golang-google-api-dev
[01:32] <mwhudson> which ftbfs because it tries to install g-g-x-oauth2-dev which is uninstallable in -proposed
[01:32] <mwhudson> cyphermox: because i want to build some packages against the g-g-x-oauth2-dev in the relase pocket
[01:33] <mwhudson> my plan is this: remove the two mentioned packages
[01:33] <cyphermox> yeah I see
[01:33] <cyphermox> you want to bootstrap things
[01:33] <mwhudson> upload a patched version of golang-google-grpc with a lower version than debian that will build against g-g-x-oauth2-dev in the relase pocket
[01:34] <mwhudson> upload a no-change rebuild of golang-goole-genproto
[01:34] <mwhudson> retry the builds of golang-google-api
[01:34] <mwhudson> sync  g-g-x-oauth2-dev from debian which should now build and migrate
[01:34] <mwhudson> sync golang-google-grpc from debian, ditto
[01:34] <cyphermox> correct me if I'm wrong but even if you remove I think LP will still have seen the upload.
[01:35] <wgrant> The plan will work, assuming that you know the correct sequence of builds.
[01:35] <wgrant> Removing them even temporarily is not a problem.
[01:35] <cyphermox> ok
[01:36] <mwhudson> wgrant: i've tried it locally with a schroot that has had some packages hacked out of the _Packages file
[01:37] <mwhudson> heh doing this with the archive publishing delays is going to require more than average levels of concentration
[01:37] <wgrant> One other possibility is to stage this in a PPA, but there aren't too many levels here.
[01:37] <wgrant> Why does golang-google-genproto need a rebuild?
[01:39] <wgrant> mwhudson: For the last two steps, can we just resurrect the existing golang-golang-x-oauth2 and golang-google-grpc that we're about to delete, the former of which has already built and the latter should now be buildable, or do we need new versions from Debian for some reason?
[01:39] <mwhudson> wgrant: er yeah resurrection would be fine
[01:40] <mwhudson> wgrant: i was assuming the versions currently in debian are the same as in z-p but i guess that's not necessarily the case
[01:40] <mwhudson> <wgrant> Why does golang-google-genproto need a rebuild?
[01:40] <mwhudson> because everything is terrible
[01:40] <mwhudson> as far as i can tell
[01:41] <wgrant> I can go with that, though I wouldn't say no to more details.
[01:41] <mwhudson> it contains files generated with an old version of the protobuf compiler, which now don't work when building with the version of golang-google-grpc in the archive
[01:41] <wgrant> Oh that is terrible.
[01:41] <mwhudson> (i think even the version in release, although i haven't checked that)
[01:41] <mwhudson> yeah
[01:43] <mwhudson> wgrant: so you're ok to do the deletion?
[01:43] <wgrant> mwhudson: Alright, sounds sane to me.
[01:43] <mwhudson> thanks
[01:43] <wgrant> Should I proceed?
[01:43] <mwhudson> wgrant: please do
[01:46] <wgrant> mwhudson: Done, and the publisher is just finishing up its previous run
[01:46] <mwhudson> wgrant: thanks
[01:49] <elfgoh> Quick check, for deb packages, eg for those with weekly or daily builds, is there a trail/log of the build so that it is possible for one to reproduce the build?
[01:50] <sarnold> there's a lot of questions in that one sentence :)
[01:50] <elfgoh> lol sorry
[01:50] <sarnold> elfgoh: debian has a reproducible builds project https://wiki.debian.org/ReproducibleBuilds
[01:50] <sarnold> they're working on reducing sources of unneeded churn from build to build
[01:50] <elfgoh> Ok thanks. What about for images?
[01:51] <sarnold> afaik no debian or ubuntu packages are just blindly rebuilt every week or something; people decide when to push new packages to the archives.. but PPAs have some 'recipes' that can do builds on some set of schedules or checkins or something, I've not investigated those
[01:52] <wgrant> mwhudson: Publisher done.
[01:52] <mwhudson> wgrant: thanks, that was quick
[01:52] <sarnold> for ubuntu, there's extensive logging of builds,consider e.g. https://launchpad.net/ubuntu/+source/bash/4.4-2ubuntu1 -- there's a few links under Builds to information on each of the builds on the different architectures
[01:52] <wgrant> mwhudson: No changes in zesty proper, so no big suites to republish.
[01:53] <wgrant> mwhudson: If you're lucky, that will hold for this whole process and we'll be done within an hour!
[01:55] <elfgoh> Ok. So assuming that I wish to do a reproducible build for debian manually, where do I look to see which source went to building a package?
[01:55] <wgrant> elfgoh: If it was built on Launchpad, you can find the log on Launchpad which contains a (not easily machine readable) list of all the dependency versions that were used for the build.
[01:56] <wgrant> We don't currently do reproducible builds in the sense of that Debian wiki page, though, so the results are not going to be byte-for-byte identical.
[01:56] <elfgoh> wgrant: I see. So the checksums could possibly differ?
[01:57] <wgrant> elfgoh: They will, yes.
[01:57] <wgrant> The goal of the reproducible builds project is to eliminate that, but it's not there yet.
[01:58] <elfgoh> Enlighten me please. Assuming the same build tools, what are the differences that could cause the resulting package checksums to differ?
[01:58] <wgrant> elfgoh: Timestamps, race conditions in parallel build processes, that sort of thing.
[01:58] <sarnold> \date{} tags in latex docs or similar in nroff for manpages..
[01:59] <wgrant> IIRC the Debian wiki page lists common sources of non-determinism
[01:59] <sarnold> random uuids in build blobs..
[01:59] <elfgoh> wgrant: thanks I will check that out
[01:59] <wgrant> elfgoh: What is your goal?
[02:00] <mwhudson> wgrant: as a core dev, can i use copy-package to copy into the primary archive?
[02:00] <mwhudson> (mostly just curious here)
[02:01] <wgrant> mwhudson: You can, but doing that with binaries can be difficult to get right.
[02:01] <mwhudson> yeah, i definitely don't want to do that :)
[02:01] <wgrant> (self-service Debian syncs are just a sourceful copyPackage nowadays)
[02:01] <mwhudson> i guess syncpackage boils down to copy-package underneath?
[02:01] <mwhudson> right
[02:03] <elfgoh> wgrant: my goal is to verify/audit the build process of a debian snapshot image for the beaglebone black
[02:03] <mwhudson> ok golang-google-grpc-dev built
[02:03] <mwhudson> pls be slow britney
[02:03] <wgrant> It's not published yet
[02:03] <wgrant> mwhudson: Why do you want it to be slow?
[02:04] <mwhudson> wgrant: so that zesty release stays unmodified
[02:04] <elfgoh> wgrant: so am trying to find out existing practices in other projects, and also get familiar with the terminology so that I can communicate clearly to the Beaglebone communituy
[02:04] <mwhudson> and the publisher is fast
[02:04] <wgrant> mwhudson: Ah right, heh.
[02:04] <wgrant> mwhudson: It just published, anyway.
[02:06] <mwhudson> wgrant: hm, rmadison isn't showing it yet
[02:06] <wgrant> mwhudson: That'll take some time to update, probably.
[02:06] <mwhudson> and i want to wait for that before i rebuild, right?
[02:06] <wgrant> No
[02:06] <wgrant> Buildds use ftpmaster.internal, so as soon as the publisher is done the changes are visible.
[02:07] <wgrant> 2017-03-17 01:41:53 DEBUG   publish-ftpmaster ran in 222.350393s (excl. load & lock)
[02:07] <wgrant> 2017-03-17 01:46:46 DEBUG   publish-ftpmaster ran in 215.29642s (excl. load & lock)
[02:07] <wgrant> 2017-03-17 01:51:45 DEBUG   publish-ftpmaster ran in 215.015479s (excl. load & lock)
[02:07] <wgrant> 2017-03-17 01:56:51 DEBUG   publish-ftpmaster ran in 220.509879s (excl. load & lock)
[02:07] <wgrant> 2017-03-17 02:02:33 DEBUG   publish-ftpmaster ran in 262.711479s (excl. load & lock)
[02:07] <wgrant> last few runs
[02:07] <wgrant> If the Published timestamp on the binary pub is before the most recent of those, it's visible to buildds.
[02:07] <wgrant> https://launchpad.net/ubuntu/zesty/amd64/golang-google-grpc-dev
[02:08] <wgrant> Published 02:03:15
[02:08] <wgrant> Ah, the publisher hadn't finished germinating, so it didn't show up as done in the log
[02:08] <wgrant> 2017-03-17 02:07:01 DEBUG   publish-ftpmaster ran in 229.814887s (excl. load & lock)
[02:09] <wgrant> mwhudson: So upload genproto so we can beat britney :)
[02:10] <mwhudson> wgrant: just doing so
[02:12] <wgrant> britney is, sadly, victorious.
[02:12] <wgrant> Still, should only take about 20 minutes.
[02:17] <mwhudson> cool
[02:41] <wgrant> mwhudson: Publisher finishing up with genproto. Retrying g-g-api next?
[02:41] <wgrant> Publisher done.
[02:42] <mwhudson> yeah
[02:42]  * mwhudson retries
[02:43] <wgrant> Might just make it in before the next publisher starts.
[02:45] <wgrant> Success.
[02:45] <wgrant> mwhudson: Does the order of oauth2 resurrection vs grpc retry matter?
[02:46] <mwhudson> yeah, need oauth2 published to build grpc i think
[02:46] <wgrant> Should I resurrect oauth2 before the publisher starts?
[02:46] <mwhudson> um i guess
[02:47] <mwhudson> worst that happens would be a build failure i guess
[02:47] <mwhudson> same for oauth2 vs grpc come to that
[02:47] <mwhudson> wgrant: afaict it would be fine to resurrect oauth2 and grpc now
[02:48] <wgrant> mwhudson: Yeah, just grpc doesn't save us any time, since it has no binaries and is the final piece anyway.
[02:48] <mwhudson> wgrant: oauth2 might ftbfs or depwait but in any case i think i need to bounce on retry for a whole bunch of stuff after this is done anway
[02:48] <wgrant> mwhudson: oauth2 has already built, remember.
[02:48] <lfaraone> I've had a merge proposal waiting for review into initramfs-tools since October 2016 that will resolve bug #798414. Are merge proposals no longer used, or is there some other way I can ensure this gets attention? (Fixing the underlying issue that results in users getting full `/boot` is, amusingly, out of scope for that bug.)
[02:48] <ubottu> bug 798414 in initramfs-tools (Ubuntu) "update-initramfs should produce a more helpful error when there isn't enough free space" [Medium,In progress] https://launchpad.net/bugs/798414
[02:48] <wgrant> The old binaries are resurrected and are currently publishing.
[02:49] <mwhudson> oh right
[02:49] <mwhudson> binaryful resurrection, didn't think about that
[02:49] <mwhudson> ok
[02:49] <lfaraone> ( sorry, MP link: https://code.launchpad.net/~lfaraone/ubuntu/+source/initramfs-tools/+git/initramfs-tools/+merge/309191 )
[02:49] <wgrant> mwhudson: It's not possible to rebuild the same source into new binaries, so we'd need either a no-change rebuild or binaryful resurrection.
[02:49] <mwhudson> wgrant: ah ok
[02:50] <mwhudson> wgrant: are you ok to sync grpc after the next publisher run? i need to disappear for a bit
[02:50] <mwhudson> not a problem if not, i can do it myself later
[02:50] <wgrant> mwhudson: Sync from Debian, or resurrect and retry?
[02:50]  * wgrant checks for version differences.
[02:50] <mwhudson> wgrant: i don't think there would be a difference
[02:50] <wgrant> mwhudson: They are in fact the same version.
[02:50] <mwhudson> but i guess resurrection would be more appropriate
[02:50] <wgrant> I'll resurrect and retry.
[02:51] <mwhudson> wgrant: yeah, debian is in freeze so not much happening there
[02:51] <mwhudson> (i know people _can_ upload to unstable but they're not doing much)
[02:51] <mwhudson> wgrant: thanks for your help!
[02:51]  * mwhudson runs away
[02:51] <wgrant> mwhudson: np
[03:03] <wgrant> mwhudson: Your plan has failed. There's a very tight loop between golang-golang-x-oauth2 and golang-google-cloud
[03:03] <mwhudson> wgrant: argh wtf
[03:03] <wgrant> One wonders why an oauth library depends on a cloud compute client library.
[03:04] <wgrant> But it's not possible to resolve without some manual relaxation one at least one side.
[03:04] <mwhudson> wgrant: why is g-g-x-oauth2-dev uninstallable now?
[03:04] <mwhudson> (am on 3g now)
[03:04] <wgrant> mwhudson: Because it needs the new golang-google-cloud-compute-metadata-dev
[03:05] <wgrant> golang-golang-x-oauth2 (0.0~git20161103.0.36bc617-1) unstable; urgency=medium
[03:05] <mwhudson> oh wait, i think i forgot some steps :(
[03:05] <wgrant>   * Depend on latest golang-google-cloud-compute-metadata-dev.
[03:05] <mwhudson> a i think if you delete oauth2 from proposed again, golang-google-cloud will build
[03:06] <wgrant> It shouldn't
[03:06] <wgrant> golang-google-cloud needs a pretty new one
[03:06] <mwhudson> oh ffs
[03:06] <mwhudson> i'll need to look at this on monday
[03:06] <wgrant>                golang-golang-x-oauth2-google-dev (>= 0.0~git20161103.0.36bc617-3~),
[03:07] <wgrant>          golang-google-cloud-compute-metadata-dev (>= 0.0~git20160615-5~),
[03:07] <mwhudson> how the heck did this build on debian
[03:07] <wgrant> So we might have to bootstrap golang-golang-x-oauth2 against an older golang-google-cloud, which is probably best done in a PPA
[03:07] <wgrant> (a PPA configured not to see -proposed)
[03:07] <wgrant> This is a pretty ridiculous looo
[03:07] <wgrant> p
[03:08] <mwhudson> oh right
[03:08] <wgrant> But indeed the dep is real.
[03:08] <mwhudson> it really is
[03:09] <wgrant>   * Depend on latest version of x/oauth2/google to avoid more circular dep
[03:09]  * mwhudson puts laptop away again
[03:09] <wgrant>     problems.
[03:09] <wgrant> ... I see
[03:10] <wgrant> Redefining the term "avoid"
[03:13] <wgrant> mwhudson: I think we need exactly golang-google-cloud 0.0~git20160615-5, which should build against the release golang-golang-x-oauth2. That golang-google-cloud will enable the -proposed golang-golang-x-oauth2 to be installed, allowing the -proposed golang-google-cloud to build.
[03:21] <wgrant> Oh great, and that golang-google-cloud won't build against the new golang-google-grpc.
[06:52] <pitti> nacc: I don't remember the details any more, but in Debian/Ubuntu at least we still have a patch to not enable auditing
[06:52] <pitti> it's still horribly noisy
[06:53] <pitti> infinity: or perhaps your ~/.vimrc has "set mouse="? (I did that too after I saw the newly enabled madness)
[06:55] <infinity> pitti: Nope.
[07:23] <mwhudson> wgrant: aaargh
[07:23] <mwhudson> wgrant: i'll look again on monday
[07:23] <wgrant> mwhudson: No you won't.
[07:23] <wgrant> mwhudson: It should migrate next britney run.
[07:24] <mwhudson> wgrant: oh you fixed it?
[07:24] <wgrant> mwhudson: Yeah, broke the loop in a PPA
[07:24] <mwhudson> ah ok
[07:27] <mwhudson> lots of build retrying on monday then
[07:29] <mwhudson> wgrant: thanks again
[07:29] <mwhudson> you're even worse than me for getting stuck on problems :)
[07:29] <wgrant> mwhudson: np
=== marcusto_ is now known as marcustomlinson
[12:57] <smoser> infinity, around ?
[12:57] <smoser> bug 1661691 . it wasnt clear to me, where you suggesting we pick up delta to disable mouse ?
[12:57] <ubottu> bug 1661691 in vim (Ubuntu Zesty) "TERM=xterm enables mouse mode in vi, breaks pasting with middle mouse" [High,In progress] https://launchpad.net/bugs/1661691
[13:00] <smoser> commented in bug.
[13:00] <infinity> smoser: Fix already uploaded.
[13:01] <smoser> you think that is the right decision? we will now differ from debian and from upstream because you and I were bothered by it.
[13:01] <infinity> smoser: Frankly, I think upstream is wrong.  I'll push this back to Debian.
[13:01] <smoser> if you push it back to debian, then i'm not so bothered. but i really dont think its worth ubuntu delta.
[13:01] <infinity> smoser: Despite what some people think, it's the job of distros to improve on upstream, not just package the upstream gospel.
[13:01] <infinity> (We carry other deltas to vim, it's not the end of the world even if we do differ)
[13:01] <smoser> infinity, once you learn about 'shift' i suspect the end result is actually better.
[13:02] <infinity> Yeah, I'm not inclined to agree it's better.  But maybe I'm old?
[13:02] <smoser> all delta is pain. most painful is behavior delta that is exposed to users.
[13:02] <smoser> you are old for sure.
[13:02]  * smoser is in the same boaat
[13:03] <smoser> so, i'm fine with whatever, but ubuntu delta that changes behavior from debian, that we can never back out because we don't want to cause pain for a user is permanent pain.
[13:03] <infinity> Plus, the "learn about shit" thing isn't exactly discoverable, so I'm not sure "users just need to learn it's broken" is valid.
[13:04] <infinity> It's my permanent pain, not yours. :P
[13:04] <smoser> i agree its not discoverable.
[13:04] <infinity> s/shit/shift/, though appropriate typo.
[13:04] <smoser> :)
[13:04] <smoser> if the error message said "did you mean shift+middle-mouse?" then it'd be fine.
[13:04] <smoser> i'll open an upstream bug suggesting that.
[13:05] <infinity> Well, "fine".
[13:05] <infinity> I don't think that's fine either.
[13:05] <smoser> well, i'd have probably never opened the bug and just accepted the change.
[13:05] <infinity> Having exactly one application that doesn't paste on middle-click is gratuitously broken.
[13:05] <smoser> that would have meant that christian would not have dug on it
[13:05] <smoser> which would mean it probably wouldnt be fixed or changed.
[13:05] <smoser> infinity, that is a good point.
[13:06] <smoser> shell paste work, vi paste fail. i'll take it.
[13:06] <smoser> thanks.
[13:06] <infinity> If upstream makes middle click actually DTRT, I can probably accept that the rest of "mouse mode" is better for people who aren't me.
[13:07] <infinity> (Though, I find placing a cursor in a terminal with a mouse to be the height of wrongness, I'm sure that's just me being a fuddy and/or duddy)
[13:08] <infinity> smoser: Also note that it *is* just broken in chroots.  In my base system, if I move .vimrc out of the way, it works correctly without the shift.
[13:09] <smoser> ?
[13:09] <infinity> So, yeah.  Removing it seems the correct thing for now, and I'll reevaluate.
[13:09] <smoser> its not "just in chroots"
[13:09] <infinity> Yeah, it is.
[13:09] <smoser> its anywhere where you have a new user.
[13:09] <infinity> No.
[13:09] <smoser> it reproduces in lxc and in vms
[13:09] <infinity> I literally just moved my .vimrc out of the way.
[13:09] <smoser> and i suspect install from scratch
[13:09] <infinity> And middle-click works.
[13:09] <smoser> i literally launched a new ubuntu vm with no user-data and ssh'd in and it fails
[13:10] <infinity> Okay, chroots and ssh?  Anything without X forwarding, probably.
[13:10] <infinity> So, even worse. :P
[13:11] <infinity> But locally, when in "mouse mode" (ie: cursor placement with mouse, etc), middle-click doesn't need the shift to paste.
[13:11] <smoser> no
[13:11] <smoser> just tried ssh -X.
[13:11] <smoser> fails there.
[13:11] <smoser> (fails == uses mouse mode)
[13:11] <infinity> "use mouse mode" isn't the failure mode, it's "needs shift to paste" that is.
[13:12] <infinity> Like i said, locally without a vimrc, it uses mouse mode.  But paste works.
[13:13] <infinity> It might not be X forwarding, it might be some local mouse library magic, I dunno.  My point was that the local and chroot(/ssh) behaviour is different.  Which is wrong.
[13:13] <smoser> well, ssh -X  without a .vimrc uses mouse mode and paste fails with the error message.
[13:13] <infinity> It has nothing to do with fresh user versus not, that just papers over it in the cases where it's extra broken.
[13:13] <infinity> A fresh local user behaves differently from a fresh chroot/remote user.
[13:14] <smoser> i can verify as you said that locally paste does work.
[13:14] <smoser> without .vimrc
[13:14] <smoser> but ssh -X to remote system it does not work.
[13:14] <smoser> so i'm not sure what the difference is there.
[13:15] <smoser> anyway, enough time spent for now.
[13:15] <infinity> Yeah, "anything without X forwarding, probably", the key word was "probably".  I'm not digging into the code to find out what the actual mechanism that's failing is. :P
=== _salem is now known as salem_
[13:47] <doko> infinity: is there a real chance for the glibc update at the weekend? asking because else I would start the test rebuilds today
[13:52] <infinity> cjwatson: I'm going to assume, because it makes sense that it should be possible, that one can create a copy archive of a copy archive? :)
[13:52] <infinity> cjwatson: (Or whatever one calls doko's rebuild archive things)
[13:53] <infinity> doko: Assuming Colin's answer to the above is what I think it should be, I'd say start a rebuild now, because I'll want to do another (main-only, probably) with the new glibc if it's going to make it so we can compare results.  Comparing to a few months ago doesn't really tell me if glibc broke things.
[13:55] <doko> ok
[14:04] <cjwatson> infinity: I've never tried it, but from the code I believe that it is possible.
[15:17] <nacc> pitti: hrm, then why does the service try to start in the container?
[15:19] <nacc> pitti: i'll try and communicate what i foudn in the bug, hopefully you can reply there
[15:21] <pitti> nacc: oh, I missed your question; I just responded to the vim mouse one
[15:22] <pitti> nacc: sure, if you want to have b.service start and stop with a.service, use BindsTo (see systemd.unit(5))
[15:22] <nacc> pitti: it's ok
[15:22] <nacc> pitti: ah ok thanks!
[15:22] <nacc> pitti: i'll see if that works :)
[15:22] <nacc> pitti: i also foudn fedora's open-iscsi.service equiv. is a lot cleaner than ours/Debian's -- so maybe will go down that path
[15:30] <jbicha> LP: #1673817 looks bad, I wonder if anyone else experienced it
[15:30] <ubottu> Launchpad bug 1673817 in unattended-upgrades (Ubuntu) "update-secure-boot-policy behaving badly with unattended-upgrades" [Undecided,New] https://launchpad.net/bugs/1673817
[15:31] <nacc> pitti: hrm, BindsTo still doesn't work exactly as I am looking
[15:31] <infinity> cyphermox: ^-- You behave badly with noninteractive debconf frontends.  Infinite loop on your password prompt instead of just defaulting to not changing the policy.
[15:32] <infinity> cyphermox: Though, this is also only triggered because of the other bug (incorrectly detecting that he's already in insecure mode), I bet.
[15:32] <nacc> pitti: in this case, we have {iscsid,open-iscsi}.service -- iscsid is a necessary service for open-iscsi.service to start. If you try to start open-iscsi.service w/o iscsid.service running successfully, it will fail
[15:32] <cyphermox> infinity: err, I don't know what the password prompt is really infinite, I had tested that a lot
[15:32] <nacc> pitti: so the use of ExecStartPre check for iscsid.service running in open-iscsi.service unfortunately, leaves open-iscsi in a failed state
[15:33] <infinity> cyphermox: Sure looks infinite in his bug report.
[15:33] <infinity> """
[15:33] <infinity> This message was repeated a very large number of times (but I only included it once in the attachment:
[15:33] <infinity> "Invalid password
[15:33] <infinity> The Secure Boot key you've entered is not valid. The password used must be
[15:33] <infinity> between 8 and 16 characters."
[15:33] <infinity> """
[15:33] <cyphermox> oh, unattended, right
[15:33] <cyphermox> heh
[15:34] <infinity> Which looks like exactly what would happen if you assume you have a frontend when you don't and ask for input you'll never get.
[15:34] <pitti> nacc: so you could say open-iscsi.service Requires=iscsid.service, why wouldn't that work?
[15:34] <pitti> nacc: oh, and After= of course too
[15:34] <nacc> pitti: because then open-iscsi.service will restart when iscsid.service restarts and it will logout of all iscsi disks and log back into them, which might drop your root disk :)
[15:34]  * infinity naps now.
[15:34] <cyphermox> infinity: yes
[15:35] <nacc> pitti: this is what fedora does: http://paste.ubuntu.com/24195791/ (in the unit)
[15:35] <pitti> well, that's not starting when you don't need it, not dependencies or ordering
[15:35] <nacc> pitti: which i think is a more accurate description -- are thereare iscsi definitions to login too? and can we use sessions?
[15:35] <nacc> pitti: i think open-iscsi.service is just written poorly tbh :)
[15:36] <pitti> sorry, what? login? sessions?
[15:36] <nacc> iscsi :)
[15:37] <nacc> pitti: http://paste.ubuntu.com/24195808/
[15:37] <nacc> pitti: that's the current open-iscsi.service (with the BindsTo change)
[15:39] <nacc> pitti: i think the distinction to be made here is that open-iscsi not starting because iscsid.service didn't start is not a failure in open-iscsi.service (it's a failure in iscsid.service)
[15:41] <nacc> pitti: if it would help, i can more clearly restate the issue -- or via e-mail or so
[15:42] <pitti> yeah, might be better; I'm quite distracted right now
[15:44] <nacc> pitti: totally fine, thanks for your time! i'll update the bug and then e-mail you directly as well
[15:44] <pitti> nacc: just sub me to the bug
[15:44] <pitti> same email folder, and everything in one place then :)
[15:44] <nacc> pitti: ack, will do
[15:46] <nacc> smoser: why does the non-empty fstab by default work in KVM? ah .. there is a disk with that label, but not in lxd
[15:47] <cyphermox> infinity: this is craptastic, there is no way this can work unattended (you do need to enter a password to do changes), and not doing it means you might have a broken system. Fortunately most likely one that boots, but still.
[15:49] <jbicha> cyphermox: is it VirtualBox that triggered the shim prompt?
[15:50] <cyphermox> probably, yes
[15:50] <jbicha> because we can blacklist individual packages in unattended-upgrades as a workaround…
[15:50] <cyphermox> no, that won't really help you
[15:50] <jbicha> also, I get that prompt every time I update VirtualBox; is there a way that it can know that I've already disabled Secure Boot
[15:50] <cyphermox> the "right" fix is to skip doing the work on unattended in this case, but it comes with risks
[15:51] <cyphermox> jbicha: yes, working on that.
[15:51] <cyphermox> it should already detect it properly but there are other broken things
[16:04] <slangasek> cyphermox: I remember we did discuss the noninteractive frontend case when this was implemented, and ISTR there were TODOs; do you recall what the plan was?
[16:05] <cyphermox> slangasek: I don't remember the noninteractive part, except that "it needs to work" was implied, and clearly I screwed up
[16:06] <cyphermox> but when you think of it hard, non-interactively it just *can't* work. it needs to be set aside for applying Mok changes later, interactively, or simply skipped.
[16:06] <cyphermox> OTOH, this will be a moot point once we really do self-signing.
[16:07] <slangasek> cyphermox: "it can't work" - the *package* needs to work
[16:08] <cyphermox> well, the package needs to work -- I'm saying you can't do the changes for Mok non-interactively.
[16:08] <slangasek> yes
[16:09] <slangasek> cyphermox: my logs say there was a db_input without || true, which should fail if we're noninteractive
[16:09] <slangasek> maybe that didn't stick?
[16:09] <cyphermox> all the db_inputs are followed by trues.
[16:09] <cyphermox> (at least AFAICS here)
[16:10] <slangasek> this was in our discussion dated 2016-07-07
[16:12] <slangasek> cyphermox: anyway, a full fix might want to be detecting that the question was not shown and gracefully resetting some state and exiting 0 with a message, instead of exploding the script
[16:12] <cyphermox> I think the issue is probably that we should reset not only db_fset shim/${action}_secureboot seen false but also shim/disable_secureboot value.
[16:12] <cyphermox> yes
[16:13] <cyphermox> I'll fix it in a bit
[16:15] <slangasek> I don't see that db_fset shim/disable_secureboot false is going to matter
[16:15] <slangasek> or do you mean setting the value rather than the flag?
[16:15] <slangasek> (in that case, also no, because when the question *is* displayed it should default to 'true')
[16:22] <nacc> smoser: interesting
[16:22] <smoser> ?
[16:22] <nacc> smoser: http://paste.ubuntu.com/24195977/
[16:22] <nacc> smoser: as to why lvm2-lvmetad failed to start a boot
[16:23] <slangasek> cyphermox: I think the most robust is to handle this at line 83 when checking the secureboot_key values: if [ -z "$key" ] && [ -z "$again" ] && ! db_fget shim/${action}_secureboot seen && ! db_fget shim/secureboot_key seen ; then exit 0 # non-interactive, skipping; fi
[16:25] <nacc> smoser: i think i have 'fixes' (will put in the bug and ask for some general review) for iscsid
[16:25] <nacc> smoser: also i do think it makes sense in the lxd cloud-images to not put anyting in fstab (or maybe comment it out?)
[16:26] <nacc> smoser: interestingly, as well, lvm2-lvmetad.socket fails to start in privileged containers too
[16:37] <slangasek> cyphermox: followed up on bug
[16:38] <slangasek> cyphermox: wondering if it 'exit 1' is better since we didn't do what was asked and it could leave the system unbootable
[17:04] <chiluk> slangasek: if your new guy needs something to do https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1626166 has been neglected..
[17:04] <ubottu> Launchpad bug 1626166 in lvm2 (Ubuntu Xenial) "lvm2 not starting lvm2-lvmetad on package install" [Undecided,Triaged]
[17:04] <chiluk> slangasek: afaik it's a systemd init scripts dependency issue.
[17:04] <chiluk> slangasek: but I haven't looked too far into it other than confirming it.
[17:10] <rbasak> chrisccoulson: seen bug 1671273?
[17:10] <ubottu> bug 1671273 in firefox (Ubuntu) " PulseAudio requirement breaks Firefox on ALSA-only systems" [High,Confirmed] https://launchpad.net/bugs/1671273
[21:41] <bdmurray> slangasek: Do you recall the plan for aptdaemon and bug 1623856? I thought barry said something about it in his remove aptdaemon email.
[21:41] <ubottu> bug 1623856 in aptdaemon (Ubuntu) "Scrolled Windows in update-manager are too small to read" [Low,In progress] https://launchpad.net/bugs/1623856
[21:42] <bdmurray> slangasek: I've confirmed both changes work and improved the description / test case a bit.
[21:42] <barry> bdmurray: aptdaemon's autopkgtests won't not fail
[21:42] <barry> so it can't clear -proposed
[21:42] <bdmurray> barry: so we need to waive it through?
[21:43] <barry> bdmurray: either that or let it languish ;)
[21:43] <bdmurray> well I think we should at least fix this bug
[22:02] <drab> hi, not sure where else to ask this, but how am I supposed to get a terminal during a ubiquity install?
[22:02] <drab> it fails and I can't figure out why
[22:02] <drab> if I go back to tty1 I just fine a "a start job is running for Ubuntu Live CD Installer"...
[22:02] <drab> and I can't get a shell
[22:03] <drab> so there's no way for me to look at logs or anything really
[22:03] <drab> I'm looking at https://wiki.ubuntu.com/DebuggingUbiquity
[22:04] <drab> I've even tried to start the session with debug-ubiquity, but I still can't get any shell of sort
[22:05] <drab> cjwatson: hi, you around by any chance? I think your name is listed on some of those pages for the ubiquity installer, would love some input
[22:05] <Unit193> While cjwatson pretty much knows everything, cyphermox is in charge of Ubiquity these days.
[22:06] <drab> Unit193: ok, thanks
[22:06] <drab> cyphermox: ^^ any input would be greatly appreciated
[22:06] <drab> this is Lubuntu xenial install btw
[22:08] <drab> I'm trying to do some automated installation with preseeding and I'm having 2 problems: 1) partman doesn't want to just wipe my disk and insists on asking me what to do about it 2) the hostname is not picked up by dhcp and it's set to whatever is in the preseed (this works with the ubuntu-server installed btw, same kernel options etc)
[22:09] <drab> actually, about 1), to be more precise, I get a "no root filesystem defined" error can't install at all
[22:09] <drab> and this happens because the disk already has some stuff on it, but the d-i options should work to the extent of just wiping everything and continuing
[22:09] <nacc> drab: both 1) and 2) work with the serrver iso?
[22:10] <drab> 2) works. 1) still seems to fail with raid1 if other disks in the machine (ie 3rd or 4th) had previously raid on it
[22:10] <drab> I'm retesting everything from fresh stuff to make sure I have correct error reports
[22:11] <drab> and I just repro'ed on a clean desktop the ubiquity issue
[22:11] <drab> with a disk that used to have windows on it
[22:11] <drab> (well it still has, installation aborted so nothing got written to it)
[22:13] <slangasek> bdmurray: the plan> certainly, any autopkgtest failures that aren't regressions should get ignored
[23:00] <drab> so I figured out the problem with getting a shell...
[23:00] <drab> it's a lubuntu bug
[23:01] <drab> lxterminal to be precise, manifesting in the installer :(
=== salem_ is now known as _salem