[00:58] <dannf> hallyn: hm... i probably did something wrong
=== chaos7theory is now known as darth_chaos7
=== darth_chaos7 is now known as chaos7theory
[02:15] <infinity> ypwong: *poke*
=== Tm_Tr is now known as Guest46635
[04:27] <sarnold> pitti: hey, about this new cloudy autopkgtest stuff, the "simple" way to run a specific package's tests looks pretty easy for the security team to use; but the proposed-migration stuff recently caught an apparmor packaging bug, and I'm curious if there's an easy way that we can use britney with local packages of some sort
[04:27] <sarnold> pitti: .. whether that's copying them out of a private ppa, or normal ppa, or a directory with packages, or something similar
[04:28] <sarnold> pitti: I know you're oing to be working on it in the next couple of weeks, and I thought it'd be nice to ask for a potentially different usecase than you might have thoght of so far :)
[04:28] <sarnold> pitti: thanks :)
[05:02] <pitti> Good morning
[05:03] <pitti> sarnold: my idea was to add extra arguments to the AMQP requests, like "enable this PPA for this test run"
[05:04] <pitti> sarnold: so, I don't plan to set up a gazillion britney instances for PPAs centrally (maybe we can provide that as a service for PPAs some day)
[05:04] <pitti> sarnold: but at least it gives you the machinery to run tests for yourself (even automatically, as sending AMQP requests is trivial to script from any language)
[05:35] <pitti> Laney: FYI, simple but effective: https://git.launchpad.net/~ubuntu-release/+git/autopkgtest-cloud/commit/?id=96c375841da
[05:35] <pitti> Laney: with that you can just run "killall worker" on the worker controller, and they will all restart cleanly after finishing their current test
[05:36] <pitti> Laney: i. e. to roll out new code or config
[05:36] <pitti> (I'll also add this to the documentation, but FYI)
[06:56] <pitti> Riddell: hi!
[06:56] <pitti> Riddell: do you know what to do with the armhf symbol mismatch on https://launchpad.net/ubuntu/+source/kjs/5.12.0-0ubuntu2 ? (it's blocking quite a few more things)
[07:06] <infinity> pitti: Just a bug in the symbols file.
[07:06] <infinity> pitti: He tried to fix it in the last upload, but ended up with a duplicate line.
[07:06] <infinity> Though, why the symbol was dropped on armhf in the first place is a curious question.
[07:07] <pitti> + (arch=!armhf)_ZTVN3KJS7JSValueE@Base 5.12.0
[07:07] <pitti>   _ZTVN3KJS7JSValueE@Base 4.96.0
[07:07] <pitti> ah, I see
[07:07] <pitti> ack, will fix
[07:09] <pitti> Riddell, infinity: fixed, thanks for pointin gout
[07:11] <infinity> pitti: Not that I agree with the fix, mind you, but it would have happened unnoticed if Riddell hadn't fat-fingered the change, and I think my carefactor about ABI breaks on 32-bit ARM on random KDE libraries is low.
[07:12] <infinity> pitti: Oh, and happily, it doesn't matter, since the ABI broke anyway for the C++ transition.
[07:12] <infinity> pitti: So, I guess it doesn't matter.
[07:12] <infinity> I said that twice.
[07:12] <infinity> I need to sleep.
[07:13] <pitti> infinity: and that *does* matter :)
[07:13] <dholbach> good morning
[07:25] <infinity> pitti: Hahaha.
[07:26] <infinity> pitti: Fix one, blow up the next library. ;)
[07:26] <pitti> infinity: yeah, currently at it :/
[07:26] <pitti> fortunately there's "only" two symbols files
[07:26] <infinity> pitti: Based on the symbols missing from the second library, it looks like it's linked to the first, and exporting its symbols.  Ick.
[07:27] <pitti> hate hate hate C++
[07:27] <infinity> Also, I shouldn't be able to read mangled symbols.
[07:27] <infinity> I hate myself a little bit for that.
[07:27] <pitti> all this just can't be right -- rebuilding unchanged source with a new compiler breaks ABI, WTF
[07:27] <pitti> </rant> sorry -- but really
[07:28] <infinity> pitti: Part of that is that we suck at filtering only-sorta-public symbols.  Which is kinda C++'s fault, and kinda our tooling.
[07:28] <pitti> well, but it also breaks symbols from the actual API
[07:28] <infinity> pitti: If you take away templates that change on rebuild, but don't "really" break ABI, it's less scary.
[07:28] <infinity> pitti: But, of course, there are also real ABI breaks to contend with, which muddies the waters.
[07:29] <infinity> So, whee.
[07:29] <infinity> pitti: I'm no great defender of C++.  Gimme C any day.
[07:30] <infinity> pitti: In this case, though, I suspect the armhf dropped symbols have nothing at all to do with the C++ transition, and we're just super lucky it's happening at the same time. :P
[07:30] <infinity> So we can pretend not to care.
[07:52] <LocutusOfBorg1> Laney, wilco!
[07:52] <LocutusOfBorg1> :)
[08:07] <flexiondotorg> pitti, I'm running 15.10 and see you've been updating policykit recently.
[08:07] <flexiondotorg> pitti, I think I may have encountered a regression in pkexec.
[08:08] <flexiondotorg> pitti, But I'd like to just double check here because it maybe the behaviour change is intended.
[08:09] <flexiondotorg> pitti, I have a python application that runs another small helper python script using pkexec.
[08:09] <flexiondotorg> pitti, Where that once worked, now I get the following output:
[08:10] <flexiondotorg> The value for the SHELL variable was not found the /etc/shells file
[08:10] <flexiondotorg> This incident has been reported.
[08:16] <flexiondotorg> pitti, Ignore the above. The issue is with fish shell which doesn't update /etc/shells.
[08:21] <LocutusOfBorg1> Laney, question: how do I generate an symbols file?
[08:22]  * LocutusOfBorg1 found https://wiki.debian.org/UsingSymbolsFiles
[08:23] <Laney> LocutusOfBorg1: Running off now, but the first commands there look good and then the c++ bit a little way further down
[08:23]  * Laney waves
[08:23] <LocutusOfBorg1> I read that symbols file for c++ projects were mostly useless.... but adding one anyway
[08:24] <Laney> Depends how good the upstream is at controlling what they export
[08:24] <Laney> really ttyl :)
[08:25] <LocutusOfBorg1> bye! :D
[08:25] <pitti> flexiondotorg: yes, pk didn't change behaviour in ages really, except for a security fix which isn't related to what you describe
[08:26] <doko> Laney, pitti: please could one of you do no-change uploads for openexr and libvigraimpex (after the next publisher run). I'll be on the train soonish
[08:26] <doko> I mean, for the rdeps
[08:26] <pitti> doko: yep, will do
[08:26] <flexiondotorg> pitti, Thanks for replying. I confirm it is not a policykit regression.
[08:27] <pitti> doko: added to the pad; I started transitions of exiv2 and libxapian, wading through the build failures now
[08:32] <pitti> anyone C++ savvy: how can a no-change rebuild against a new lib ABI succeed but change exported symbols? https://launchpadlibrarian.net/213741568/buildlog_ubuntu-wily-amd64.libkexiv2_4%3A15.04.2-0ubuntu2_BUILDING.txt.gz
[08:33] <pitti> do C++ libs do such massive leaking of private symbols, or how is that being handled?
[08:33] <pitti> doko: ^ (perhaps you know)
[08:33] <hyperair> there's -fvisibility
[08:33] <hyperair> but a lot of libs don't use it
[08:33] <hyperair> and there are still a lot of leaked std:: symbols that i typically ignore using (optional)
[08:33] <pitti> but this isn't "standard" symbols
[08:33] <pitti> +#MISSING: 4:15.04.2-0ubuntu2# _ZN11KExiv2Iface11SubjectDataD1Ev@Base 4:4.10.3
[08:34] <pitti> that's clearly from KExiv
[08:34] <hyperair> hang on lemme pipe that through c++filt
[08:34] <hyperair> - KExiv2Iface::KExiv2::Private::detectEncodingAndDecode(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const@Base 4:4.9.80
[08:34] <hyperair> std::string has changed type
[08:34] <hyperair> + KExiv2Iface::KExiv2::Private::detectEncodingAndDecode(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const@Base 4:15.04.2-0ubuntu2
[08:35] <hyperair> which means that all functions which have std::string in their argument list will change signature
[08:35] <pitti> hyperair: ah, so that means we need to rename libkexiv2-11 to libkexiv2-11v5 and do another transition?
[08:35] <hyperair> which consequently changes their mangled symbol
[08:35] <hyperair> yes
[08:35] <pitti> this is just plain crazy
[08:35] <hyperair> yeah well, it doesn't happen often.
[08:35] <hyperair> it's probably because of the std change
[08:36] <hyperair> there were a couple of struct size changes between c++98 and c++11
[08:36] <pitti> hyperair: ack, doing lib transition then, thanks
[08:36] <hyperair> np
[08:44] <mwhudson> so given that docker has a static binary, do we have any clever way of knowing which libs are built into it?
[08:44] <mwhudson> so we can do a rebuild when any of those libs are updated?
[08:44] <pitti> mwhudson: looking at it's Build-Depends:?
[08:47] <cjwatson> mwhudson: Built-Using would be the right tool for the job, even though it won't be a complete answer as yet (because nothing's set up to specifically scan it)
[08:48] <cjwatson> mwhudson: I thought dh-golang had something to emit that?
[08:48] <mwhudson> oh right
[08:48] <mwhudson> yeah, it does
[08:48] <mwhudson> docker doesn't use it though :-)
[08:51] <mwhudson> Our goal is to release the final version of Go 1.5 on August 20, 2015.
[08:51] <mwhudson> mm that date looks familiar :-)
[09:03] <pitti> Laney, infinity: how can http://people.canonical.com/~ubuntu-archive/transitions/html/exiv2-g++5.html be fixed to check for libexiv2-14?
[09:06]  * pitti NBSes it from wily-proposed (no further rdepends), maybe that'll help
[09:25] <mwhudson> today's basket of ugh: https://bugs.launchpad.net/ubuntu/+source/libguestfs/+bug/1481994
[09:25] <ubottu> Launchpad bug 1481994 in libguestfs (Ubuntu) "ftbfs in wily" [Undecided,New]
[09:26] <mwhudson> contrary to the bug title, i think ocaml-gettext was broken by the update to gcc 5
[09:53] <pitti> cjwatson: do you still know where the transition tracker lives?
[09:54] <pitti> apparently not on snakefruit, and lillypilly lost the ~ubuntu-archive role account
[09:59] <cjwatson> pitti: it's on snakefruit
[09:59] <cjwatson> pitti: start from ~ubuntu-archive/bin/update-transitions
[09:59] <cjwatson> (called from archive-reports)
[09:59] <pitti> cjwatson: ah, thanks
[10:00] <cjwatson> it's just cunningly hidden in an schroot
[10:00] <pitti> cjwatson: I'd like to see whether I can convince it to fix http://people.canonical.com/~ubuntu-archive/transitions/html/exiv2-g++5.html
[10:04] <cjwatson> pitti: the configs are in lp:~ubuntu-transition-trackers/ubuntu-transition-tracker/configs/
[10:04] <pitti> cjwatson: thanks! updating that
[10:05] <cjwatson> pitti: actual code, I think it just uses the ben package from trusty
[10:05] <cjwatson> and there's a 'go' script buried in the schroot
=== utlemming is now known as utlemming_away
[10:26] <smb> Where would be the best channel trying to get hints about why i386 desktop isos fail to start a proper live session when running in a KVM VM. The obvious part is because compiz does not start, I just completely fail to find any log that would explain why that is. Maybe #ubuntu-desktop?
[10:27] <seb128> smb, is that wily?
[10:28] <smb> seb128, also, but basically all since and including Trusty
[10:28] <seb128> weird
[10:28] <seb128> it's rather an issue with the vm graphic drivers than with the iso then I guess
[10:29] <smb> Yeah, it is something with KVM/Qemu because Xen (while using the exactly same graphics emulation) does work (except Vivid which seems to be specially broken)
[10:30] <seb128> I doubt -desktop can help you
[10:30] <seb128> it's not an issue with the desktop in the image
[10:30] <seb128> but rather with the vm
[10:31] <smb> Right, I am mainly interested on whether there is any way to extract reasons on why compiz does not start. The X.org.logs of both Xen working and KVM not working seem to be the same and neither has any hard errors in them
[10:32] <seb128> on < vivid look into .cache/upstart/gnome-session-Unity.log
[10:32] <seb128> or >= vivid sudo journalctl
[10:33] <seb128> like the 3d rendering or software emulation not working
[10:42] <smb> seb128, I got the wily iso booted on Xen and KVM right now. So journalctl shows some warning level and above, but nothing that strikes as errors related to X up to a point where there seem follow up errors because of that (X resources unavailable). The X.org.log seems ok enough. At least the sw renderer seems to come up and visually you see background and the two icons (install and examples) rendered. Just nothing e
[10:42] <smb> lse (which I would say is because of compiz not running)
[10:42] <smb> There just seems to be no reason given anywhere why it did not get started (or failed to start)
[10:50] <seb128> smb, go to a vt and start DISPLAY=:0 compiz --replace and see what it goes?
[10:55] <smb> seb128, Interesting. Hm, so it starts and keeps running, but still no unity. Certainly because startup is screwed. Is there a similar magic for the unity part?
[10:55] <seb128> smb, unity is a plugin, you can try to run "unity" from the vt
[11:02] <smb> seb128, Ah thanks. That at least sheds a bit of light... Though cryptic. So I was guessing that "DISPLAY=:0 unity --replace" might be what I should try. Which seems to be okayish up to the point where LLVM tells me: "ERROR: Do not know how to split the result of this operator!"
[11:05] <seb128> smb, that's like your issue
[11:06] <seb128> smb, seems like bug #1360241 but that got fixed
[11:06] <ubottu> bug 1360241 in llvm-toolchain-3.5 (Ubuntu) "[Regression] "LLVM ERROR: Do not know how to split the result of this operator!" in executing Ubuntu UI Toolkit tests on x86" [Undecided,Confirmed] https://launchpad.net/bugs/1360241
[11:06] <smb> seb128, Yeah, if only I would know how to parse this error message. :) But ok, at least something I can look for
[11:06] <seb128> https://llvm.org/bugs/show_bug.cgi?id=21641
[11:06] <ubottu> llvm.org bug 21641 in LLVM assembly language parser "LLVM ERROR: Do not know how to split the result of this operator!" [Normal,New]
[11:10] <smb> Hmmm, ok, so maybe there is a subtle difference in the cpu flags between KVM and Xen which sound like the only reasonable explanation to this. So llvm potentially runs different optimizations...
[11:10] <smb> seb128, Thanks, I think that got me somewhere
[11:10] <seb128> smb, yw!
[12:36] <smb> Yay! It _is_ the cpu type that llvmpipe(i386) does not like
=== rickspencer3_ is now known as rickspencer3
[13:09] <davmor2> smb: I hit the same issue there is a bug in lp for it. I386 hates llvmpipe on the kvm cpu, I used -cpu host to get around it and then is works a charm
[13:11] <smb> davmor2, Yeah if I knew about that one before... :-P It also works with -cpu core2duo. So with some other data gathered it may be either the model/stepping info or maybe one of PAT or VME that make i386 llvmpipe to go on strike
[13:12] <davmor2> smb: https://bugs.launchpad.net/bugs/1481294
[13:12] <ubottu> Launchpad bug 1481294 in qemu (Ubuntu) "14.04.3: in kvm install full disk from the i386 install when you go to login it returns you to the login page" [Undecided,New]
[13:13] <smb> davmor2, ah thanks. There is also the more generic bug 1448985 which I was looking at
[13:13] <ubottu> bug 1448985 in qemu (Ubuntu) "Ubuntu 14.04 LTS, 14.10, 15.04, 15.10 guests do not boot to Unity from QEMU-KVM Ubuntu 14.04 LTS, 14.10, 15.04 hosts" [High,Confirmed] https://launchpad.net/bugs/1448985
[13:14] <davmor2> smb: nice
[13:15] <smb> Now who do we talk to about go... err llvmpipe
=== Luke_ is now known as Luke
[13:41] <Odd_Bloke> What installs the symlinks in /etc/systemd/system/multi-user.target.wants/?
[13:42] <Odd_Bloke> Or, to ask my actual question, how can I get a service to start on boot when it's installed?
[13:42] <pitti> Odd_Bloke: dh_installinit, or if there's no corresponding init script to the .service, dh_install_{enable,start}
[13:42] <pitti> (see their manpages)
[13:42] <pitti> Odd_Bloke: sorry, dh_systemd_{enable,start}
[13:43] <pitti> Odd_Bloke: dh_systemd_enable will call systemctl enable, which creates that .wants/ symlink
[13:43] <pitti> Odd_Bloke: and d_s_start will start it immediately after package install
[13:44] <Odd_Bloke> pitti: Excellent, thanks!
[13:50] <Odd_Bloke> pitti: dh_systemd_enable isn't run by default?  So to enable all installed init things I need just 'override_dh_systemd_enable:\n dh_systemd_enable' in debian/rules?
[13:51] <pitti> Odd_Bloke: then you don't need to override it at all :) (if you don't want to supply options)
[13:51] <pitti> Odd_Bloke: usually, if you have a debian/foo.init and debian/foo.service, it'll just work
[13:52] <Odd_Bloke> Ah, I don't have a foo.init.
[13:52] <pitti> Odd_Bloke: but you need a dh-systemd build dep and "--with systemd", perhaps that's missing?
[13:52] <pitti> Odd_Bloke: .init isn't strictly required, it is just necessary if you want sysvinit scripts to be able to depend on your service
[13:52] <Odd_Bloke> Aha, no dh-systemd build dep.
=== utlemming_away is now known as utlemming
[14:56] <pitti> cjwatson: did you happen to run across a case where builds/tests were randomly SIGTERMed? https://launchpad.net/ubuntu/+source/notmuch/0.20.2-1build1
[14:56] <pitti> cjwatson: I can't reproduce this in a local sbuild, but it seems repeatable on the LP build
[14:57] <cjwatson> pitti: I'm only aware of LP buildds doing that in the case of idle-for-too-long, which doesn't seem to be true here.
[14:57] <pitti> cjwatson: does that use alarm() or so? (the test might set that), or does it time it out from "outside"?
[14:57] <cjwatson> pitti: This test suite has its own timeout, though; could it be that?
[14:58] <cjwatson> pitti: It does use alarm(), but several layers of process out from anything the test suite should care about directly
[14:58] <pitti> cjwatson: ah, looks like the previous few builds all FTBFSed too
[14:58] <pitti> so this is not a recent thing, sorry for the noise
[14:59] <pitti> last built in trusty
[14:59] <cjwatson> pitti: Also, it would say "Build killed with signal <something> after <something> minutes of inactivity" if it were sbuild
[14:59] <cjwatson> pitti: np
[14:59] <cjwatson> pitti: Maybe your machine is just faster than the buildds ...
[15:00] <cjwatson> Though the buildds aren't exactly slow.
[15:00] <pitti> they must have a helluva precisely calibrated timeout :)
[15:00] <cjwatson> The build log says the test suite has a two-minute timeout
[15:01] <cjwatson> Maybe genuinely stalling for some reason, anyway
[15:01] <pitti> right, /me stops worrying
[15:09] <pitti> Riddell: wrt. https://launchpadlibrarian.net/213757621/buildlog_ubuntu-wily-amd64.k3d_0.8.0.3-7build3_BUILDING.txt.gz it seems test.hpp is gone from libboost1.58-dev; do you happen to know its replacement?
[15:10] <pitti> this thing has rather little google juice, except https://svn.boost.org/trac/boost/ticket/10965 which doesn't really give a solution
[15:10] <pitti> "For future reference, this stuff is in libs/math/include_private now. "
[15:10] <pitti> but I don't see where that would be
[15:12] <Riddell> pitti: I've no idea I'm afraid, it's a gnomey application ask a gnomey person
[15:13] <pitti> Riddell: ah, thanks; just thought you might have stumbled over this before
[15:15] <pitti> slangasek: OOI, as you mentioned in the meeting: is there a particular reason why the transitions tracker is like 6 hours behind? is that looking at a lagging mirror instead of ftpmaster perhaps?
[15:20] <cjwatson> pitti: it's not?
[15:21] <cjwatson> I mean, where are you seeing six hours?  http://people.canonical.com/~ubuntu-archive/transitions/ghc.html is a bit under an hour back, and the state it's referring to is reasonably recent
[15:21] <cjwatson> Definitely well under six hours since I've done a couple of layers of that transition today
[15:21] <pitti> cjwatson: e. g. https://launchpad.net/ubuntu/+source/libkexiv2/4:15.04.2-0ubuntu4 built 5 hours ago, but http://people.canonical.com/~ubuntu-archive/transitions/html/exiv2-g++5.html has all Xes
[15:21] <pitti> https://launchpad.net/ubuntu/+source/strigi/0.7.8-1ubuntu5 even built 9 h ago
[15:21] <cjwatson> That must be something else
[15:21] <cjwatson> Not just staleness
[15:23] <pitti> https://launchpad.net/ubuntu/+source/openimageio/1.5.17~dfsg0-1ubuntu2/+build/7766665 built 4 hours ago
[15:23] <cjwatson> I'm not sure what; strigi should be unknown there, I'd have thought
[15:23] <pitti> so yeah, bit weird
[15:24] <cjwatson> The Xes don't mean "unbuilt", in any case
[15:24] <slangasek> pitti: the tracker gets the answer wrong when the binary package names have changed.
[15:24] <slangasek> (see discussion on #ubuntu-release yesterday w/ Laney)
[15:24] <cjwatson> Ah right, it probably doesn't do a proper merge
[15:24] <pitti> slangasek: ah! yeah, the bits that are stale look library-ish
[15:25] <slangasek> it apparently goes "oh, this is the most recent version of this binary package from that source, and it has a wrong dependency, therefore the source package is 'bad'" and never looks at the fact that there's a newer source, with binaries built, none of which depend on the bad package name
[15:25] <slangasek> and it's ben so I'm not going to try to debug it
[15:25] <cjwatson> It would be simpler to do a merge out of band with the same logic we use in proposed-migration
[15:25] <pitti> ack, thanks for the heads-up
[15:26] <cjwatson> That is, discard would-be-NBS binaries from the old source if there's evidence of a newer build for that arch
[15:26] <cjwatson> But you don't have to make the tracker green, anyway, it's just a convenience
[15:57]  * pitti waves
[16:12] <slangasek> cjwatson: not making the tracker green makes it very hard to use the tracker to coordinate work
[16:13] <slangasek> so maybe I'll try to look at what p-m is doing
[16:14] <cjwatson> slangasek: agreed
[16:15] <cjwatson> "partial_upgrade" is probably the horrifying keyword to search for
[16:15] <slangasek> ok, thanks :)
=== utlemming is now known as utlemming_away
=== utlemming_away is now known as utlemming
[18:11] <sarnold> pitti: that's awesome news, re ampq tooling; thanks. (something we could run locally would also work, but canonical has more computers than I do :)
[18:14] <infinity> sarnold: And whose fault is that?  Buy more computers!
[18:15] <sarnold> infinity: sarnistack is gonna be awesome!
[20:51] <slangasek> cjwatson: so I'm failing to find anything in proposed-migration matching partial_upgrade
[20:54] <slangasek> cjwatson: is it 'partial_unstable'?
[20:54] <cjwatson> slangasek: oh yes that
[20:54] <cjwatson> brain failure, sorry
[20:54] <cjwatson> the massive bodge I added for Ubuntu's suite layout, anyway :P
[20:54] <slangasek> tdaitx: ^^ ok, this is what we're looking for, in lp:~ubuntu-release/britney/britney2-ubuntu
[20:54] <slangasek> right :)
[20:55] <tdaitx> slangasek, thanks =)
[20:55] <slangasek> I assume this will mostly be illustrative of the concept rather than providing any code we can cut'n'paste ;)
[20:55] <sl1rpy> okay, i was talkiing to someone in the main #ubuntu channel and supposedly paid apps show up in ubuntu 14.04 but i havent seen them show up in 15.04
[20:55] <tdaitx> that works fine
[20:55] <sl1rpy> i thought i saw them in 14.10 just fine
[20:56] <slangasek> sl1rpy: not really the channel for this fwiw, but I believe that apps show up as available for each given Ubuntu release only after they've been tested for compatibility with it and marked as available?
[20:57] <sl1rpy> ah.. because of newer libraries
[20:57] <sl1rpy> makes sense now
[20:58] <cjwatson> slangasek,tdaitx: right - the basic idea is just to try to work out whether binaries have been superseded by a newer build for the same arch even if the actual binary in question has gone away in the newer version, but this is complicated by things like binary versions not necessarily matching source versions, binaries changing from arch-dependent to arch-independent between versions, and other such things
[20:59] <cjwatson> slangasek,tdaitx: I'm pretty sure proposed-migration gets it right now, but it took me several goes!  indeed you probably won't be able to cut-and-paste actual code, but it might be a good idea to make sure you have every step of the algorithm ...
[21:01] <infinity> Is this an attempt to teach ben about partial suites and disappearing binaries?
[21:02] <infinity> If so, wow.
[21:02] <infinity> tdaitx: I don't know what you said in your interview, but I'm pretty sure you offended slangasek.
[21:02] <slangasek> <snort>
=== beisner is now known as beisner-afk
=== beisner-afk is now known as beisner
[21:23] <tdaitx> infinity, lol
[21:24] <tdaitx> infinity, it is probably because I only mentioned IDL and php _after_ being hired =P
[22:03] <cjwatson> infinity: It only needs to go in the wrapper, which is a lot less scary :-)
[22:03] <cjwatson> Though also, I think, not in revision control anywhere
[22:04] <cjwatson> http://paste.ubuntu.com/12016775/
[22:53] <smoser> hey...
[22:53] <smoser> i'm wanting to put mdadm into the cloud image
[22:53] <smoser> but am not overly thrilled about pulling in
[22:53] <smoser>  Recommends: default-mta
[22:53] <smoser> anyone have thoughts on that?
[22:54] <infinity> smoser: It likes to mail people when your raid is degraded.  It's a fairly valid thing, I'd say.
[22:55] <infinity> smoser: One could take the opposite stance that anything without a hard dep on an MTA shouldn't have a recommends either, because admins know if they do or don't want one and are aware of the consequences.  But are they? :P
[22:56] <smoser> i agree that it has good reason to use an mta
[22:57] <smoser> but if i apt-get install... its unlikely that i'm going to configure my mta
[22:57] <smoser> and if i expect you to later on decide to configure your mta in order to be told of failing disks, then you would probably realize you didnt have one when you went to configure it.
[22:57] <smoser> probably would :)
[22:58] <smoser> does that seem sane ? ie, we're Recommending you install an mta, but really we're Recommending that you install and configure your mta.
[22:59] <infinity> smoser: I wouldn't object strenuously to dropping the recommends to a suggests, though it might be nice to convince the Debian maintainer(s) of that too, so we're not carrying a (nearly) pointless delta.
[22:59] <smoser> i guess though if you already had one installed and then you install mdadm, the world is a happy place.
[23:00] <smoser> ok. i think i'llf ile ubuntu and debian bugs and then maybe pick up a delta.
[23:00] <smoser> thanks infinity
[23:10] <ScottK> smoser: on a normal installation postfix will pop up via debconf and ask to be configured.
[23:11] <infinity> ScottK: Yeah, but not if preinstalled in a cloud image.
[23:12] <ScottK> Right, but I think that makes is a personal problem for cloudy things.
[23:12] <infinity> ScottK: So, then he's entering "do I force this as a first-boot-config thing on users, leave it broken until they run dpkg-reconfigure, or not install at all".
[23:12] <ScottK> On regular systems it works exactly as one would hope.
[23:12] <ScottK> Sure, but I'm arguing don't screw up a working thing because cloud.
[23:13] <infinity> ScottK: I'm pretty fence-sitty wishy-washy about anything that "recommends" an MTA, though.
[23:13] <infinity> ScottK: Hard dependency, sure, go for it, you need /usr/sbin/sendmail, have at 'er, and I get to keep the broken bits when I configure it wrong.
[23:13] <infinity> ScottK: But for optional functionality, I'm less convinced that it should ever be the default to install an MTA (at least in Ubuntu, where we tried to hard to get it out of the standard install in the first place).
[23:14] <infinity> s/tried to/tried so/
[23:14] <infinity> In Debian, it was more traditional to always have an MTA, so the recommends tended to be no-ops.
[23:14] <ScottK> Is mdadm in the default install?
[23:14] <infinity> No, but he's wanting to put it in the default cloud install.
[23:15] <infinity> It also ends up in the "default" server install iff you install to raid.
[23:15] <infinity> Not even sure what happens there, now that I think about it.
[23:15] <infinity> d-i might install it without recommends.
[23:15] <infinity> Or you might get a broken MTA.
[23:15] <infinity> Or you might be forced to configure an MTA during install.
[23:15] <infinity> I don't test that path often enough, clearly.
[23:16] <ScottK> Also, postfix isn't a particularly heavy thing to install.
[23:17] <infinity> ScottK: I'm sure mjt will have opinions.  He tends to have those.
[23:17] <ScottK> So it'd probably be better, at least for now, to leave it be and smoser can preseed a no-op configuration if he doesn't want people to have to configure during install.
[23:17] <infinity> ScottK: Most MTAs aren't heavy, but misconfigured MTAs are crap, and even after all the handholding exim and postfix gave people, they're still super good at doing it wrong.
[23:18] <infinity> ScottK: Honestly, though, I think the recommends fails the test for what makes a recommends not a suggests.
[23:18] <smoser> ScottK, i dont care so much about the configuration
[23:18] <smoser> as the install will occur in the cloud image build process.
[23:18] <ScottK> I see.
[23:18] <smoser> i'd rather not have the mta installed. as it carries with it some megabytes i think are most likely not needed.
[23:18] <ScottK> If not configured, postfix is safe.  Won't cause any problems.
[23:18] <smoser> other than the megabytes
[23:19] <infinity> Which matters when you're spamming images at N compute nodes, yes.
[23:19] <ScottK> Installed-Size: 3568 seems like not much, but meh.
[23:20] <infinity> smoser: Another option is to not add it to your usual packageset/seed/whatever, but to install it in a chroot hook with --no-install-recommends.
[23:20] <infinity> ScottK: It all adds up.
[23:20] <infinity> (But size is a stupid argument for avoiding a dep, the right argument is "is the dep level correct?")
[23:20] <smoser> infinity, right. that could definitely be done, but that breaks "recommends by default". which we've not done up until this point
[23:20] <infinity> If there's a significant reduction in functionality without an MTA, it's a recommends.
[23:20] <smoser> (admittedly we're side-stepping that :)
[23:21] <ScottK> I think that degradation notifications are pretty essential for mdadm.
[23:21] <infinity> mdadm doesn't have a significant loss in functionality without an MTA, it just loses the spam feature.
[23:21] <ScottK> The only way I think you don't want the mail is if you have nagios or something else letting you know.
[23:22] <ScottK> I don't recall.  Does our mdadm continue through the boot process or not when degraded?
[23:22] <ScottK> It's been yes or no at different time.
[23:23] <ScottK> If the answer's no, then not knowing about the degradation would be bad.
[23:23] <infinity> We used to boot degraded by default.
[23:23] <infinity> We bloody well better still.
[23:23] <smoser> so per apt , in cloud-image with recommends :
[23:23] <smoser>  4,904 kB of additional disk space will be used.
[23:23] <infinity> Cause it's a nightmare when not.
[23:23] <smoser> without:
[23:23] <smoser>  1,191 kB of additional disk space will be used.
[23:24] <smoser> so that is 3.7M that it costs me in space, which is admittedly not a lot, but i'm trying to make images smaller as a general goal.
[23:24] <infinity> smoser: And then shrink by zlib compression rate or whatever, cause unpacked rootfs size doesn't matter, it's size of the image you shove across the wire (AMIs, glance images, etc)
[23:24] <infinity> smoser: Which are all compressed formats, I assume.
[23:25] <smoser> well, yes. the size of the compressed transferrable image matters. but so does the size of the space taken up.
[23:25] <smoser> when booted.
[23:25] <infinity> smoser: Not nearly as much, though.
[23:25] <infinity> Anyhow, like I said, size is the wrong argument.
[23:25] <smoser> i dont know.
[23:25] <infinity> If it's a legit recommends, don't cut corners because cloud is special.
[23:26] <infinity> If it's not legit, downgrade to suggests.
[23:26] <infinity> Argue until conclusion reached.
[23:27] <infinity> smoser: Are cloud instances backed by multiple disks a really common use-case anyway?  Seems kinda entirely against the point of how cloud things are meant to work.
[23:28] <infinity> "It's ephemeral, but I want RAID for redundancy" is just weird.  And "It's ephemeral, but I want RAID0 for speed" ignores the fact that you usually have zero control over your backing devices, and would have no way of knowing if you just slowed it all down by striping across two unknowns.
[23:29] <smoser> people use raid on ec2 for performance
[23:30] <infinity> Those people are weird.  But okay.
[23:30] <smoser> the other motivating factor ..
[23:30] <smoser> is that cloud images become maas images
[23:30] <smoser> and maas images want to use raid (for hardware)
[23:30] <smoser> and i want cloud images and maas images *more* the same
[23:31] <infinity> And curtin can't "apt-get install mdadm" if it installed to raid?
[23:31] <infinity> *cough*d-i*cough*
[23:32] <infinity> Anyhow, I can argue both sides of this argument until I'm blue in the face.
[23:33] <infinity> But you have to evaluate this on the merit of the dep, not your specific goal.
[23:34] <ScottK> infinity: http://web.archive.org/web/20130313083303/http://netsplit.com/2012/10/30/goodbye-ubuntu was what had me wondering about what we did on degraded raid.
[23:34] <ScottK> (yes, I did remember a three year old blog post)
[23:37] <infinity> ScottK: Yes, I too remember that post.  I also remember the complete lack of bug reports or reference to what actually went wrong.
[23:37] <infinity> ScottK: "It broke because my magic wasn't there."
[23:37] <ScottK> You don't generally get those in the "I give up" blog post.
[23:39] <infinity> ScottK: Yeah, but it also makes the rant entirely useless as a data point except "Scott hates us", which we already knew by that point. :P
[23:40] <ScottK> It was mostly the mention of the didn't boot degraded event.
[23:40] <infinity> ScottK: Yeah, but even that was wishy-washy enough to not know what actually happened, or what it was telling him.
[23:40] <ScottK> True.
[23:41] <infinity> ScottK: Anyhow, I remember having long arguments with people that booting degraded was the only sane thing on headless servers.  And I think that's the current state of things.  But maybe I should test that. :P
[23:41] <ScottK> May be.
[23:42] <infinity> But what I really need is someone to sell me pie.
[23:42] <infinity> I failed to breakfast correctly, and lunched even more poorly, and now all I want is pie.  I think something broke me today.
[23:43] <smoser> i do like pie
[23:44] <infinity> smoser: An interesting ubuntu-specific compromise to the mdadm/mta argument might be to drop it to a suggests *and* make the cronjob spit out an angry update-motd snippet.
[23:45] <infinity> smoser: That's slightly less visible than an angry email, but way more visible than a missed email in a blackhole of an unconfigured MTA.
[23:45] <infinity> ScottK: ^-- thoughts?
[23:45] <ScottK> Since we already have a diff, that might be OK.
[23:45] <infinity> smoser: I think if my motd told me with intense anger on every login that my raid array was FUBAR, I might notice.