[01:25] <nacc> slangasek: is powerpc only deleted from the ISOs? will it stay in the archive for 17.04? but not maintained?
[01:25] <nacc> slangasek: trying to advise someone in #ubuntu+1 on it
[02:18] <slangasek> nacc: it's to be removed from the archive for 17.04, but this hasn't happenedy et
[07:16] <Mirv> mitya57: those are just great, thanks.
[07:17] <Mirv> mitya57: 5.6.1 amd64 build though failed in some mimetype test failure, could be flaky so retrying
[09:51] <mitya57> Mirv, looks like retrying did not help
[09:52] <mitya57> It seems to wget a file from cgit.freedesktop.org (how is that even possible during build??), maybe that changed and it broke the tests?
[09:54] <mitya57> I will land the Xenial one for the time being, it is more important than Yakkety.
[10:20] <Mirv> mitya57: nothing brewing, and no the only git branches available are zesty, xenial+overlay (and zesty+1 eventually)
[10:21] <Mirv> mitya57: probably it changed, and yes I thought network connection wasn't possible anyway but I also remember some recent discussion about that
[10:22] <Mirv> I agree xenial is more important
[10:23] <cjwatson> network connection remains impossible in anything other than snap builds
[10:23] <cjwatson> I suspect your wget is illusory in some way :)
[10:35] <mitya57> cjwatson, OK, that's what I thought :)
=== alan_g is now known as alan_g|afk
=== alan_g|afk is now known as alan_g
[12:20] <ginggs> mitya57: do you have any idea about the recent sphinx test failures? http://autopkgtest.ubuntu.com/packages/s/sphinx/zesty/amd64 the tests run fine locally
[12:34] <Laney> ginggs: it reproduces for me (autopkgtest --shell-fail -U --apt-pocket=proposed=src:texlive-base sphinx  -- lxd autopkgtest/ubuntu/zesty/amd64)
[12:36] <Laney> does look tex related too
[12:47] <ginggs> Laney: ok thanks for checking, i installed the new texlive-base packages and ran debian/tests/python-sphinx and debian/tests/python3-sphinx
[12:48] <ginggs> Laney: does it fail for you with texlive-base 2016.20170123-3 in zesty?
[12:50] <Laney> ginggs: I gave you the command so that you could try it yourself :P
[12:50] <Laney> but ok... let me see
[12:57] <mitya57> ginggs, Laney: I don’t know anything about this yet. Is the error “Command \strong already defined.”, or do I read the log incorrectly?
[13:02] <Laney> mitya57: yeah I think so
[13:02] <mitya57> I will try to look later then.
[13:10] <Laney> ginggs: python-sphinx        PASS
[13:10] <Laney> python3-sphinx       PASS
[13:10] <Laney> sphinx-doc           PASS
[13:20] <ginggs> Laney: thanks
[14:04] <xnox> juliank, hey about bug https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1672710
[14:05] <ubottu> Launchpad bug 1672710 in apt (Ubuntu) "apt fails to verify keys when Dir has space, and set via cmdline" [High,Confirmed]
[14:05] <xnox> it's actually triggered by python-apt, as used by apport, and can be seen in the autopkgtests.
[14:05] <xnox> what apport does is use python-apt's apt.Cache with rootdir and this bug ends up being triggered.
[14:05] <juliank> How awful, but yes, I can believe that.
[14:05] <xnox> how does python-apt pass rootdir to apt?
[14:06] <juliank> It directly sets the setting in the configuration object.
[14:06] <juliank> The broken part is dumping that into a file for apt-key
[14:06] <xnox> well, and apt-key calls apt-config which fails to load, what was dumped....
[14:07] <xnox> maybe apt-config can ignore garbage at the end of file, if it found the key we want?
[14:07] <juliank> Actually, I'm not sure why this affects python-apt usage at all, unless there is a quote in the rootdir name itself.
[14:07] <juliank> or you are parsing commandline with python-apt and there are spaces there.
[14:07] <xnox> or for apt-key can we dump just a subset of keys? It really only wants just a few keys.
[14:08] <xnox> in the ADT test the rootdir is something like this:
[14:08] <xnox> /tmp/tmpepmqlz89/cache/Foonux 1.2/apt/
[14:09] <xnox> let me try to extract the generated apt_config as passed to apt-key whilst these tests are executed.
[14:11] <xnox> the call that fails for us is update() call on the apt_cache object
[14:11] <xnox> rootdir = os.path.abspath(aptroot)
[14:11] <xnox> self._sandbox_apt_cache = apt.Cache(rootdir=rootdir)
[14:11] <xnox> self._sandbox_apt_cache.update(fetchProgress)
[14:11] <xnox> and we bomb out there.
[14:13] <juliank> Still, unless some part is parsing a commandline with spaces in options, or sets another option with quotes in it, that should not fail.
[14:14] <xnox> ack.
[14:14] <xnox> can i somehow dump apt.Cache object config?
[14:14] <xnox> to see at point of failure what is wrong?
[14:15] <juliank> xnox: You can print apt_pkg.config.dump()
[14:17] <juliank> xnox: Since when does this problem occur? I have not seen it, and we have the code to pass config files to apt-key since 1.3 (in yakkety)
[14:18] <xnox> since yakkety =)
[14:18] <xnox> but apport adt tests have been failing for other reasons too, hence this issue was masked.
[14:18]  * xnox has fixed most things now; but this one test case is still failing.
[14:22] <juliank> xnox: And I basically added the whole thing to fix apport test failures in https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1607283
[14:22] <ubottu> Launchpad bug 1607283 in apt (Ubuntu) "1.3~pre2ubuntu2 regression: trusted.gpg.d not read any more from apt root" [Medium,Fix released]
[14:23] <xnox> yeah.
[14:23] <xnox> i will come back to this after the next phone call.
[14:23] <juliank> It's in the IRC log from Jul 28
[14:52] <nacc_> slangasek: ack, thanks
=== nacc_ is now known as nacc
[15:11] <happyaron> stgraber: do you think running `modprobe zfs` in d/tests/excersie is a sufficient fix for bug #1672749 ?
[15:11] <ubottu> bug 1672749 in lxd (Ubuntu) "Please don't assume zfs module is always loaded" [Undecided,New] https://launchpad.net/bugs/1672749
[16:51] <slangasek> mdeslaur, infinity, kees, stgraber: TB meeting in 9 min
[16:51] <mdeslaur> ack
[16:53] <slangasek> I'm considering going forward just always following https://wiki.ubuntu.com/TechnicalBoardAgenda for who's the chair, so that if the previous chair doesn't update it, I'm never chairing ;)
[17:00] <mdeslaur> oh whoops
[17:33] <robru> Laney: https://code.launchpad.net/~robru/britney/+git/britney2-ubuntu/+merge/319726 please review this quick 3 line diff, thanks
[17:57] <Laney> robru: want to add some tests? https://paste.debian.net/919899/ as a starting point, maybe
[17:59] <robru> Laney: could do
[18:05] <robru> Laney: ok, expanded and updated, please merge
[18:05] <Laney> okey smokes, lemme look
[18:17] <Laney> robru: done, thanks!
[18:17] <robru> Laney: thank you!
[18:36] <cjwatson> powersj: FYI I'm probably going to include a cherry-picked fix for https://bugs.launchpad.net/debian/+source/openssh/+bug/1670745 in my next Debian upload at which point zesty can be fixed by a sync - just waiting for Debian release team approval since it interacts with the stretch freeze
[18:36] <ubottu> Launchpad bug 1670745 in openssh (Ubuntu) "ssh-keyscan : bad host signature when using port option" [High,In progress]
[18:37] <powersj> cjwatson: awesome, thanks for the heads up
[18:41] <cjwatson> (you're more than welcome to deal with SRUs though ;-) )
[18:42] <powersj> :)
=== ssweeny_ is now known as ssweeny
[20:45] <arari> Hi all, any developer from http://packages.ubuntu.com/source/trusty/mountall available for a question ?
[20:46] <nacc> arari: better to just ask the question
[20:48] <arari> gettting hit by this: The disk drive for /mydisk is not ready yet or not present however without pressing anything the disk is mounted ok... got one VM with that problem and one without... same ubuntu version, same packages, same fstab and same crypttab... killing my head on this one
[20:53] <nacc> arari: is the fs at /mydisk remote?
[20:53] <arari> nacc: no
[20:53] <arari> its an LVM over LUKS over LVM
[20:54] <nacc> arari: when it fails, do you see anything in syslog indicating what fails?
[20:55] <arari> nacc: no
[20:56] <nacc> arari: and you say that if you do nothing when it says it's not ready ... meaning it has dropped you to a shell?
[20:56] <arari> nacc: no, the boot proceeds as normal and the disk is there after login
[20:56] <nacc> arari: so ... what's the error?
[20:56] <nacc> arari: just that you get that message?
[20:58] <arari> nacc: i had two machines (on client sides) that experienced that in the past two weeks, one of them became unbootable since that problem was showing on / the second one you had to press S to skip the /mydata and then mount it manually afterwards
[20:58] <arari> nacc: so even though this one is booting... i imagine the other two were somehow related
[20:58] <arari> hence need to fix this before delivering this new VM
[21:00] <nacc> arari: is it failing to get the encryption passphrase or something?
[21:01] <arari> dont think so, i just think that it is doing stuff before it should because the (mydata) running... message shows up a bit after that error message... so for me... it looks like it is tryign fstab stuff before completing the crypttab stuff
[21:01] <arari> nacc: that above
[21:03] <arari> as if it was somehow "forked" on the background the "crypttab" stuff and didnt finish before the "fstab" stuff is applied
[21:03] <nacc> arari: related maybe to LP: #1092853 ?
[21:03] <ubottu> Launchpad bug 1092853 in mountall (Ubuntu) "mountall fails to handle "noearly" crypt disk correctly and displays error" [Undecided,Confirmed] https://launchpad.net/bugs/1092853
[21:04] <nacc> arari: given LVM, noearly seems rather important (based upon crypttab)
[21:04] <nacc> *`man crypttab`
[21:04] <arari> nacc: i tried with and without noearly... but i dont see the errors as described on that bug
[21:04] <nacc> arari: ok
[21:05] <nacc> arari: and i assume you rebuild the initramfs after changing fstab?
[21:05] <nacc> or crypttab, i think
[21:06] <arari> no :S
[21:07] <nacc> arari: then i don't think any changes you make have any affect to the problem you are seeing (which i think is still initramfs time)
[21:08] <arari> nacc: will try to update... "update-initramfs -u" right?
[21:09] <nacc> arari: yes, after making any configuration changes
[21:09] <arari> but as mentioned, i have one (multiple) VM with exactly the same setup and working fine, whilst others not
[21:09] <nacc> arari: could be timing related -- i genuinely don't know :/
[21:18] <arari> nacc: https://ibb.co/jUga0a
[21:24] <nacc> arari: right, so it's started quite early but not read until later -- is it multipathd?
[21:24] <arari> nacc: no idea what that is, gonna google
[21:25] <nacc> arari: it's ok, you probably aren't using it then, i was just trying to figure out why /data showed up then
[21:25] <nacc> arari: this is with 'noearly'? or iwthout
[21:25] <nacc> *without
[21:25] <nacc> arari: and is this 14.04 or 16.04?
[21:25] <arari> 14.04
[21:27] <nacc> arari: ok -- yeah, i know a lot less about this, and it seems like there have been (at least lately) fewer bugs with the ordering in 16.04 -- but i'm not a subject-matter-expert
[21:29] <arari> nacc: that is without noearly...  with noearly it shows like this https://ibb.co/kHOoLa
[21:30] <arari> as can be seen it is "ignored" but still all this happens after the error
[21:33] <nacc> arari: iiuc, then, as long asyou interact in some way with that message, it works?
[21:34] <arari> nacc: i dont even need to interact... everything works ok , i dont need to press anything or do anything
[21:35] <nacc> arari: so the only issue is the one time it happend to / ?
[21:35] <arari> and once it happend to /data but that time it also required me to press S
[21:35] <arari> to skip
[21:35] <arari> didnt continue as normal
[21:37] <nacc> arari: i genuinly don't know
[21:37] <nacc> arari: it seems very likely to be something with crypt and the tming with upstart
[21:37] <arari> nacc: i appreciate the help, i feel at a loss here also... leaning towards some sort of race condition
[21:38] <nacc> arari: you could file a bug, but if it's not easily reproducible...
[21:39] <arari> yeah well i find alot of them but all seem to be related to swap and /tmp and people seem to provide workarounds or reinstall rather than fix the actual problem
[21:39] <cjwatson> to some extent I think that's just the result of it having been superseded by a totally different technology stack in later releases
[21:40]  * nacc agrees with cjwatson
[21:40] <nacc> and there's not much investment on 'fixing' upstart issues at this point
[21:40] <arari> yeah i can imagine but 14.04 is still a LTS
[21:40] <cjwatson> I'm not disagreeing, just talking practical effects
[21:41] <cjwatson> (this is no longer my area so I get to be disinterested peanut gallery ;-) )
[21:41] <nacc> arari: completely empathize -- but also am very aware that what little i do know about init systems is systemd-ish now
[21:41] <nacc> arari: and what little i did at some point know about upstart has been pushed off the LRU
[21:42] <cjwatson> if it *can* be reproduced in a VM even if only sometimes, then the way to give a bug report the best chance would be to include directions on building a VM from scratch that demonstrates the bug
[21:43] <cjwatson> just on general principles
[21:45] <nacc> yep
[21:45] <arari> yeah i would like to provide some VMS unfortunately they have too much sensitive data :(
[21:48] <sarnold> it doesn't have to be provided
[21:49] <sarnold> it's in fact better if it isn't; instuctions like "start from cloud image yyyymmdd; install foo, bar, baz; set blort to reticulate splines; reboot. notice that the waves are harmonic rather than anharmonic."
[21:50] <nacc> yeah, it's more about reproducibility, arari
[21:50] <nacc> arari: LP: #610869 has some interesting backstory too
[21:50] <ubottu> Launchpad bug 610869 in mountall (Ubuntu) "mountall ignores nofail mount option" [Medium,Triaged] https://launchpad.net/bugs/610869
[21:53] <nacc> juliank: fyi, https://code.launchpad.net/~nacc/extract-changelogs/changelog-components/+merge/319761 -- but i'm a bit worried about the case I mentioned in the last comment to deal with B-C for a newer apt (yet to be changed of course)
[21:53] <nacc> bdmurray: thanks for the quick response on that!
=== JanC_ is now known as JanC
[21:57] <juliank> nacc: I guess explaining what you mean with B-C wouldn't hurt. AFAICT, you chose to symlink the files itself, instead of just merging the {main,...} directories?
[21:58] <nacc> juliank: oh i see what you mean, i could just make main --> ../ ?
[21:58] <nacc> duh :)
[21:58] <juliank> Yeah
[21:58] <nacc> yes that would seem way better than what i suggested :)
[21:58] <juliank> just have to do an initial "manual" merge of the existing trees
[21:58] <nacc> right
[21:59] <nacc> bdmurray: that's why i didn't want a merge immediately ;)
[22:00] <nacc> bdmurray: i'll rework my changes -- and i guess maybe we'd have a tool in the repository do the initial flattening? (merging pool/$component/* down into pool/* and then symlinking pool/$component -> pool for B-C)
[22:00] <juliank> I imagine you can also use mod_rewrite in the apache server if you want to go crazy
[22:01] <juliank> I played a lot with that today
[22:01] <nacc> juliank: yeah i imagine so, but i'm not sure where the apache configuration itself lives
[22:01] <nacc> i can ask about that too, though, that's a goodp oint
[22:05] <juliank> I imagine the rewrite rules to be ugly, though
[22:07] <juliank> RewriteCond %{REQUEST_URI} ^/universe/(.*)$
[22:07] <juliank> RewriteRule (.*) /main/%1 [R=301,L]
[22:07] <juliank> Something like that but just with more paths adjusted
[22:07] <juliank> and a RewriteCond ../main/%1 -f
[22:07] <juliank> or something
[22:09]  * juliank thinks mod_rewrite is a bit helpful, but would like something more powerful
[22:10] <juliank> My task today was to normalize multiple slashes to single slashes, as otherwise, relative looksup in my html failed.
[22:10] <juliank> That works now, but it redirects one /+ at the time
[22:30] <nacc> juliank: fun! :)
[23:43] <stgraber> happyaron: we will modify LXD proper to fix that in our next release (next week or so). Now for Ubuntu itself, I consider your change to be a regression which will affect everyone who uses scripts to setup zpools or other tooling which does the same.
[23:44] <stgraber> happyaron: I've added a priority high, regression task against zfs-linux. My preference here would be to have "zpool" automatically load the kernel module if not present. If that's not possible, I'd recommend we revert this change since it's post feature freeze and consider doing it again very early next cycle.
[23:49] <nacc> bdmurray: given it's a one-time operation, are you ok with there being an additional script that just flattens the existing c.u.c/pool and leaves behind symlinks so everything will look similar? I guess the risk there is that pool/main will contain src packages that are not in main (and same for other components)
[23:50] <nacc> i don't know if anyone depends on the URI telling you the component
[23:51] <sarnold> that's a heck of a lot of symlinks
[23:52] <sarnold> 512B each? 4KB each?
[23:53] <nacc> sarnold: it will be ~4 symlinks
[23:53] <nacc> sarnold: i may have described it poorly above
[23:53] <sarnold> ah :D
[23:53] <nacc> but the idea is pool/main/ -> ../; pool/universe -> ../
[23:53] <nacc> same for multiverse, partner
[23:54] <nacc> then you can find a given changelog via either pool/component/src/src_version/changelog or pool/src/src_version/changelog and we'd change apt to use the latter to fix the bug :)
[23:55] <sarnold> nacc: how about packages that move from main to universe or the other way around? are those happy?
[23:56] <nacc> sarnold: so what i'd expect is w/o any changes
[23:56] <nacc> you'd see
[23:56] <nacc> pool/main/src/src_oldversion/changelog
[23:56] <nacc> and
[23:57] <nacc> pool/main/src/src_newversion/changelog
[23:57] <nacc> bah
[23:57] <nacc> pool/universe/src/src_newversion/changelog
[23:57] <nacc> for a main -> universe transition
[23:57] <nacc> with the change, we'd only extract pool/src/src_oldversion/changelog and pool/src/src_newversion/changelog
[23:57] <nacc> *but* there'd be a symlink from pool/main to pool/
[23:58] <nacc> the confusing bit is you'd also see (potentially) pool/main/src/src_newversion/changelog and pool/universe/src/src_oldversion/changelog
[23:58] <nacc> that's the part I can't decide if it would break something