[05:13] <pitti> Good morning
[05:14] <pitti> Riddell: we also want to move to systemd on upgrades, yes; I'm uploading the bits now
[05:15] <pitti> Riddell: stdout for user session programs usually goes to ~/.xsession-errors, unless there's a session upstart job; they they go to ~/.cache/upstart/
[05:15] <pitti> mardy: no, usually mocks should be in the tests that use them; python-dbusmock has a few for common services, which avoids having to copy them between several packages
[05:16] <pitti> Saviq: https://wiki.ubuntu.com/Touch/Testing#Running_tests_with_autopkgtest is the TL;DR documentation with pointers to details
[05:17] <pitti> jamespage: the "TemplatePluginNotRegistered"? some python update got in the way?
[05:18] <pitti> jamespage: there are still some problems with mongodb and some others; I did a first mongodb fix yesterday, but I'll keep poking too
[05:22]  * pitti unleashes the madness in bug 1427654
[07:06] <pitti> jamespage: mongodb fix uploaded; I'm looking into the openvswitch failure, I know what the reason is
[07:11] <pitti> jamespage: that's due to bug 1429734 FYI
[07:45] <dholbach> good morning
[07:56] <pitti> jamespage: I filed bug 1429739 for neutron, do you have an idea about that exception?
[07:58] <pitti> jamespage: ah, happens under upstart too, bug updated
[08:30]  * pitti looks at mysql-5.6 now
[08:43] <rbasak> pitti: o/
[08:43] <pitti> hey rbasak, how are you?
[08:43] <rbasak> I'm just back from a week away, catching up now.
[08:43] <pitti> rbasak: ah, did you have a good time off?
[08:43] <rbasak> Yes thank you
[08:49] <pitti> infinity, Laney: can we please add a force-badtest on current upstart? I just filed bug 1429756, and I'm not lucky enough to hit a time when it manages to succeed on both arches
[08:50] <pitti> rbasak: oh, you have commit on debian's mysql-5.6? I'm currently building a fix for enabling the systemd unit, so that mysql starts on install and its test will succeed again
[08:52] <rbasak> pitti: yes, though I thought systemd support was added to mysql-5.6, although I didn't work on that directly. Does it not work?
[08:52] <pitti> rbasak: nope, little detail is missing :)
[08:52] <rbasak> :-/
[08:52] <pitti> rbasak: http://paste.ubuntu.com/10567186/
[08:52] <rbasak> Sorry. Happy to take your patches in Debian :)
[08:52] <pitti> rbasak: without that, the dh_systemd_enable part never gets run
[08:52] <pitti> so the unit is disabled, and thus never starts
[08:52] <rbasak> Ah, OK.
[08:53] <rbasak> pitti: want me to push that to Debian VCS now?
[08:54] <pitti> rbasak: it's certainly correct, but I'm not 100% sure yet whether it's sufficient, or something else needs updating too
[08:54] <rbasak> OK, I'll hold on then.
[08:54] <pitti> rbasak: once my sbuild finishes and I ran the autopkgtest locally, I'll give you the go
[08:55] <pitti> rbasak: btw, it still hasn't promoted from -proposed, it makes some percona-*.5.5 stuff uninstallable
[08:55] <rbasak> Yeah, I need to fix the percona-galera-3 FTBFS
[08:55] <pitti> rbasak: anyway, you'll stumble over this during your mail catch-up for sure :)
[08:55] <rbasak> :)
[08:55]  * pitti doesn't envy yo
[08:55] <pitti> u
[08:56] <rbasak> I'm sure your inbox is far worse after a week off :)
[08:57] <pitti> rbasak: I'm going to find out soon; I'll have 1.5 weeks of holiday from next week on :)
[08:59] <rbasak> So 50% worse, + the 50% pitti extra workload premium? :-P
[08:59] <pitti> rbasak: *shrug* I just switched the init system; what can *possibly* go wrong!
[09:00] <rbasak> Ah. Now I understand the carefully timed planning going on there :-P
[09:01] <ogra_> pitti, well ...
[09:01] <ogra_> The following packages have unmet dependencies:
[09:01] <ogra_>  systemd-sysv : Conflicts: upstart but 1.13.2-0ubuntu9 is to be installed
[09:01] <ogra_> E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution).
[09:02] <pitti> ogra_: ah, mind running that with -o debug::PkgProblemResolver=true ?
[09:02] <LocutusOfBorg1> hi folks!
[09:02] <pitti> ogra_: I suppose that's apt-get dist-upgrade?
[09:02] <ogra_> pitti, if i only knew how to do that on the livefs builder :)
[09:02] <ogra_> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu
[09:02] <ogra_> thats an image build
[09:02] <pitti> ah
[09:03] <ogra_> https://launchpadlibrarian.net/199721670/buildlog_ubuntu_vivid_amd64_ubuntu_BUILDING.txt.gz
[09:03] <pitti> ogra_: that's ubuntu or touch?
[09:03] <ogra_> last build log
[09:03] <ogra_> no, desktop
[09:03] <ogra_> the normal iso
[09:03] <davmor2> pitti: dun broked it!
[09:03] <davmor2> pitti: now I know you heart is in QA :)
[09:03] <pitti> ogra_: the init-system-helpers package migrated much later, could it be that it didn't yet see that one?
[09:04] <ogra_> when ?
[09:04] <pitti> no, that's ok
[09:04] <ogra_> this build is from 1h ago
[09:04] <pitti> I: Retrieving init 1.22ubuntu4
[09:05] <cjwatson> it's a priority mismatch
[09:05]  * ogra_ remembers he read somethin about changing the order of deps 
[09:05] <ogra_> yeah
[09:05] <cjwatson> http://people.canonical.com/~ubuntu-archive/priority-mismatches.html
[09:05] <ogra_> was about to say that :)
[09:05] <cjwatson> causes upstart to be in debootstrap's result
[09:05] <pitti> wow, that exploded
[09:06] <cjwatson> plymouth dropped to standard, was that intentional?
[09:06] <pitti> I also don't quite understand all the initramfs, iproute2 etc. changes
[09:07] <cjwatson> upstart probably has a transitive dependency on initramfs-tools
[09:07] <cjwatson> and it certainly depends on ifupdown
[09:07] <cjwatson> but those are also explicitly seeded in minimal, hence priority important
[09:08] <cjwatson> anyway, the required -> important changes are probably just fine; plymouth is the only questionable thing there IMO
[09:09] <ogra_> they phone wouldnt mind for it to be in standard :)
[09:09]  * ogra_ could drop a bunch of hacks 
[09:09] <cjwatson> I guess
[09:09] <pitti> plymouth is in ubuntu-standard, that sounds ok?
[09:09] <ogra_> buut i highly doubt it is intentional
[09:10] <cjwatson> I guess it makes sense actually, yeah
[09:10] <pitti> i. e. before upstart had a transitional dependency to plymouth?
[09:10] <ogra_> mountall ...
[09:10] <cjwatson> so yeah, go ahead and process that bunch and then the livefs build should be happy again
[09:10] <pitti> ack
[09:10] <ogra_> it needs it for fsck communication with the user
[09:11] <Laney> pitti: upstart force> I guess---could you strongarm jodh or someone into looking? :-)
[09:11] <ogra_> systemd doesnt do that ?
[09:11] <pitti> ogra_: it does, but only if plymouth is installed
[09:11] <ogra_> ah, cool
[09:11] <pitti> otherwise it just gives you the feedback on the text terminal
[09:11] <pitti> (for servers mostly)
[09:11] <ogra_> thats quite an innovatiion
[09:12] <pitti> ogra_: text terminals? yeah, awesome new stuff, try them!
[09:12] <pitti> :-P
[09:12] <ogra_> text terminals without having to use a plymouth text theme to interact with them :P
[09:12] <pitti> rbasak: all good, can you please commit that fix?
[09:12] <pitti> rbasak: shall I upload it now, or do you have something else queued for mysql-5.6?
[09:13] <ogra_> (and not needing plymouth (and this nvidia and ati drivers in the initrd) even on non-plymounth systems
[09:13] <ogra_> s/this/thus/
[09:13] <ogra_> (or fonts)
[09:13] <ogra_> it will massively shrink our initrd ;)
[09:14]  * pitti hears a faint sense of approval from ogra_
[09:14]  * ogra_ nods wildly
[09:17] <ricotz> pitti, hello :), did you got reports yet, that some post-installation-trigger causes plymouth boot/shutdown screen to show up (while running systemd)?
[09:18] <pitti> ricotz: debian bug 779606, I think
[09:18] <pitti> ricotz: but please file an Ubuntu one if you are unsure
[09:18] <pitti> ricotz: but post-isntall triggers shouldn't daemon-reexec, just daemon-reload
[09:21] <ricotz> pitti, i see, will try to reproduce and narrow it down, but it happens when installing updates of some specific packages, iirc it didnt happen with 218
[09:23] <pitti> ricotz: I think I see this in a VM on daemon-reload; I don't see it on my laptop
[09:25] <pitti> rbasak: I uploaded the fixed -5.6 now
[09:32] <pitti> dholbach: hallo, wie gehts?
[09:33] <pitti> dholbach: there are some broken links on http://packaging.ubuntu.com/html/auto-pkg-test.html , where can this be fixed again?
[09:34] <pitti> jodh: good morning
[09:34] <pitti> jodh: your mk-sbuild trouble are the same as the above live build failure; should be resolved with next publisher run
[09:35] <zyga> pitti: hey, what can I do to synchronize pyotherside to vivid?
[09:36] <ogra_> use requestsync i guess
[09:36] <ogra_> (sp ?)
[09:36] <zyga> thanks. I'll read about that
[09:36] <pitti> zyga: I can do it; ok to remove ubuntu changes? (I remember our conversation from two weeks ago, but cross-checking)
[09:37] <zyga> pitti: yes
[09:37] <zyga> pitti: exactly as we discussed before
[09:37] <pitti> zyga: what's your LP ID?
[09:37] <zyga> pitti: quick question: on the debian package index I see pyotherside 1.4 in experimental with (rc-buggy) next to it, what does that mean?
[09:37] <zyga> pitti: zkrynicki
[09:38] <pitti> zyga: hm, I don't know; https://tracker.debian.org/pkg/pyotherside has no bugs at all
[09:38] <pitti> zyga: where do you see this?
[09:38] <pitti> zyga: (synced)
[09:39] <zyga> pitti: https://packages.debian.org/search?keywords=pyotherside&searchon=names&suite=all&section=all
[09:39] <zyga> pitti: in experimental
[09:39] <zyga> pitti: (thanks!)
[09:39] <pitti> zyga: hm, no idea about that
[09:44] <dholbach> pitti, lp:ubuntu-packaging-guide - or just let me know which ones to fix
[09:45] <pitti> dholbach: README.package-tests (and similar) in git were renamed/reformatted to *.rst a while ago
[09:45] <pitti> and in /usr/share/doc/ too
[09:49] <dholbach> pitti, ok
[10:15] <pitti> jodh, ogra_: http://people.canonical.com/~ubuntu-archive/priority-mismatches.html is once again empty, image/schroot build should work again
[10:20] <pitti> dholbach: danke! https://code.launchpad.net/~dholbach/ubuntu-packaging-guide/autopkgtest.fix/+merge/252257
[10:20]  * dholbach hugs pitti
[10:24]  * pitti hugs dholback
[10:25] <Laney> is that "dholbach back"? :)
[10:29] <pitti> Laney: yeah, SCNR :)
[10:32] <dholbach> :)
[10:41] <rbasak> pitti: thanks. Pushed to Debian VCS.
[10:41] <pitti> rbasak: cheers
[10:41] <pitti> rbasak: I'm looking at apache2 now, specifically the ssl-passphrase test
[10:41] <pitti> Mar 09 11:40:47 autopkgtest apache2[4384]: No way to ask user for passphrase
[10:41] <pitti> rbasak: is that supposed to ask on the console?
[10:41] <rbasak> pitti: I've seen some fixes for that in Debian
[10:41] <pitti> i. e. an interactive init.d script?
[10:42] <rbasak> pitti: the Ubuntu delta added plymouth prompting
[10:42] <pitti> I can teach the unit to grab the TTY, but that's a bit "eww"
[10:42] <pitti> I mean interactively prompting during boot, not the tty thing
[10:42] <pitti> doesn't that kind of break on remote servers?
[10:43] <rbasak> It does, but I think it's fair to assume that if the sysadmin sets an SSL cert that requires a passphrase, he expects to be prompted.
[10:43] <pitti> ok
[10:43] <rbasak> Alternatively he can use a cert without a passphrase, and he won't be prompted :)
[10:43] <jpds> Shouldn't it just do what luks does?
[10:43] <rbasak> jpds: what do you mean exactly?
[10:44] <rbasak> My home server uses https://github.com/basak/netkeyscript to unlock LUKS :)
[10:44] <pitti> rbasak: but there's no plymouth while the autokpgtest runs
[10:44] <rbasak> jpds: do you mean prompt via plymouth, or something else?
[10:44] <jpds> rbasak: Yes.
[10:44] <pitti> so it could at most be on the console
[10:44] <rbasak> pitti: in that case I think it should fall back to tty?
[10:44] <pitti> and the test uses an expect script
[10:45] <rbasak> pitti: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773405 seems relevant here
[10:47] <rbasak> pitti: looks like a merge for Debian may be appropriate - I only see bugfixes
[10:47] <pitti> rbasak: yes, I'll check the diff and what they did here
[10:49] <pitti> ah, they added exec /bin/systemd-ask-password, which we don't have
[10:49] <jpds> rbasak: netkeyscript> Scary.
[10:49] <rbasak> jpds: I use a crossover cable
[10:50] <rbasak> Then replug it back onto the LAN.
[10:50] <pitti> rbasak: they also slightly changed the prompt string, hmm
[10:50] <rbasak> Easier than carting a keyboard and monitor to the server
[10:50] <rbasak> pitti: maybe the prompt string didn't work with a \n in it?
[10:51] <pitti> rbasak: well, I'm happy to do the merge and test it both ways; changes in -9 look fine
[10:53] <pitti> rbasak: newline works fine, I suppose they just liked their's better; our autopkgtest specifically tests Debian and Ubuntu strings)
[10:54] <rbasak> pitti: if you don't mind, please go right ahead. I'm going to be a while before I'm caught up :-/
[10:54] <pitti> rbasak: no, that's fine; thanks for the heads-up
[10:54] <pitti> rbasak: I meant, yes, I'll merge
[10:54] <rbasak> ack, thanks
[11:24] <smb> pitti, Hi, just a quick question: is it expected that doing a dist-upgrade on a server based install does _not_ try to remove upstart?
[11:24] <pitti> smb: no, not expected, they should be transitioned too
[11:25] <pitti> smb: do you have ubuntu-standard installed?
[11:25] <smb> pitti, No, those have server^ as a base
[11:25] <pitti> smb: ah, and we don't upgrade tasks on servers
[11:29] <smb> Hm, ok... should probably check whether installing form a server cd would pull in ubuntu-base, too nowadays. (these are kind of special installs going from a debootstrap into a bootable state)
[11:30] <pitti> smb: there's no ubuntu-base, we have ubuntu-minimal (which depends on "init"), ubuntu-standard (which depends on systemd-sysv), and then things like ubuntu-desktop
[11:30] <pitti> smb: would you mind filing a bug about the server upgrade? we need to figure out how to do that then, we need some kind of "server" (meta?)package to pull in systemd-sysvinit then
[11:30] <smb> pitti, I actually tried to type ubuntu-standard... damn fingers
[11:31] <smb> pitti, Yeah, will do after checking a "proper" cd install
[11:36] <Tribaal> guys, so I don't know if that's expected, but LXC seems to break since the switch to systemd
[11:36] <pitti> Tribaal: not expected; I've used it for months under systemd, can you please file a bug with details?
[11:36] <infinity> pitti: We can work around that in do-release-upgrade, but there's nothing we can do for bare debootstrap+(some packages) installs short of making systemd-sysv essential, which we opted not to do.
[11:37] <Tribaal> pitti: so, maybe I'm doing something wrong then
[11:39] <infinity> pitti: (This is why the buildd chroots still have upstart in them until I forcefully rebuild/upgrade them too)
[11:40] <Tribaal> pitti: so, I killed a vivid container and restarted it and everything seems fine again... scratch that.
[11:41] <smb> infinity, Ok, so that means if a real server cd install does change correctly, what I see with the special install is no bug but rather expected
[11:44] <smb> gah, why on earth is grub trying to install into the lvm partition after being told to use the mbr...
[11:51] <pitti> rbasak: ok, apache2's tests now run fine; expect doesn't work with systemd-ask-passphrase, so I added another little responder to that
[11:52] <rbasak> Thanks!
[11:55] <doko> rbasak, you added a block-proposed on a juju-core issue. any reason for that?
[11:58] <cjwatson> doko: The text of the bug seems to explain it quite adequately
[12:00] <doko> cjwatson, sorry, a SRU request to block an update to an existing version? what do I misunderstand?
[12:00] <cjwatson> doko: Well, it's not just an SRU request is it n ow
[12:00] <cjwatson> *now
[12:01] <rbasak> doko: we have an SRU exception for Juju, so new releases theoretically should land in Vivid and stable releases concurrently (server users care only for Precise and Trusty really).
[12:01] <cjwatson> I believe there's something quite subtle about juju major version upgrades where they don't work right until they're registered in upstream simplestream as well
[12:01] <rbasak> Right - I want packages to land in Vivid and Trusty only after upstream have published the simplestreams data for it for an official release.
[12:01] <cjwatson> But as a general point it seems unhelpful to say "any reason for that?" when there are reasons given in the bug.  If you don't like the reasons, explain why
[12:02] <infinity> cjwatson: He doesn't like the reason cause it's blocking his upload. :P
[12:02] <rbasak> But we want to coordinate testing before that, so they don't release until Ubuntu -proposed has binaries and they can test those too.
[12:02] <infinity> But it's blocked on ppc being FTBFS anyway.
[12:02] <infinity> So meh.
[12:02] <doko> yeah, I saw that too
[12:02] <rbasak> IIRC, there were issues with the 1.21.1 proposed release, so I was asked to hold - presumably pending a newer upstream proposed release. I need to check with upstream.
[12:02] <rbasak> What are you blocked by?
[12:03] <infinity> rbasak: He mangled your build-deps.
[12:03] <infinity> http://launchpadlibrarian.net/199658027/juju-core_1.20.14-0ubuntu2_1.20.14-0ubuntu3.diff.gz
[12:03] <rbasak> Ah, OK
[12:04] <rbasak> Looks like I never actually uploaded 1.21.
[12:04] <rbasak> So I think that should be OK to push through.]
[12:07] <mlankhorst> can someone on the ubuntu-release team ack https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1424980 ?
[12:08] <infinity> mlankhorst: Is fglrx still not ready?
[12:08] <mlankhorst> no :/
[12:08] <infinity> mlankhorst: Well, not much to ACK, then.
[12:10] <pitti> rbasak: https://jenkins.qa.ubuntu.com/job/vivid-adt-mysql-5.6/lastBuild/? \o/
[12:11] <rbasak> \o/
[12:11] <rbasak> Thank you!
[12:11] <mlankhorst> infinity: if lucky it will be there soon, could I get a conditional ack depending on fglrx at least?
[12:11] <pitti> rbasak: that won't magically fix the perowossname issue of course, but my stack of "Jenkins Failed" mails is slowly getting smaller :)
[12:11] <infinity> mlankhorst: Not sure what good a conditional ACK does you, you can't half upload it. :P
[12:12] <mlankhorst> all the paperwork being done mostly..
[12:12] <infinity> mlankhorst: Yes, I think updating to 1.7 is probably the right thing to do, but there's no point examining it until we know it won't break fglrx.  If fglrx comes too late, we won't risk it.
[12:13] <pitti> do we still require flgrx?
[12:13] <pitti> in the sense of, is the free driver still not good enough?
[12:13] <pitti> (it seemed to be quite nice many years ago, then I stopped buying non-Intel graphics hw)
[12:14] <mlankhorst> it has some features not in the free driver, and in some cases it works when the free driver doesn't.. but other way around is true too
[12:14] <infinity> pitti: The free driver is decent for desktop use, fglrx is still better for gaming.  Kinda hoping that's not true in another year or two, as AMD was dumping resources into radeon.
[12:15] <infinity> They at least have a plan to kill fglrx, which is more than I can say for nvidia.
[12:16] <mlankhorst> nvidia uses the nouveau stuff for their K1 :P
[12:16] <rbasak> I've been all-Intel for years, but have been considering buying an AMD/ATI/whatever setup recently.
[12:16] <mlankhorst> not on desktop yet thoug
[12:17] <infinity> rbasak: The price/performance ratio for AMD video cards is hard to pass up.  The absolute top end flip-flops every 6mo between AMD and nvidia, but if you're buying middle of the road, AMD's been winning at cheap for years.
[12:18] <infinity> rbasak: But if you're doing high end 3D in Linux, the drivers matter a lot more than the cards, and fglrx is a flaming heap compared to the nvidia binary driver. :/
[12:18] <infinity> (For a Win32 gaming box, though, I'd recommend AMD any day of the week, unless you have thousands to burn)
[12:18] <rbasak> When it's working presumably. I don't want to be beholden to a binary driver though.
[12:19] <rbasak> Or, if I have to do it, then at least have the choice of a free driver that is reasonable.
[12:19] <StevenK> I've found Nividia better for the dual boot case, too. Because oh god, fglrx
[12:19] <infinity> rbasak: So, free driver wise, nouveau and radeon are both pretty decent these days.
[12:19] <rbasak> Hence AMD. But I also want my setup to drive six heads, and also want it to be quiet when it isn't doing heavy lifting.
[12:20] <rbasak> And apparently multi-card on Linux is pretty poor/nonexistent with AMD
[12:20] <StevenK> Six heads? So 3 SLI/whatever the heck AMD call it?
[12:20] <rbasak> So I haven't done anything yet
[12:20] <StevenK> Crossfire? I think?
[12:20] <rbasak> Yeah that thing. Apparently it just doesn't work on Linux
[12:21] <StevenK> rbasak: Given how fglrx behaves with only one card and one output, I am not at all surprised.
[12:21] <rbasak> I'm thinking of getting something that drives 4 heads, with a couple of Matrox dualhead2go things
[12:21] <infinity> Yeah, Crossfire and Linux will make you want to cry, I imagine.
[12:21] <infinity> They're likely to implement it sanely in the free driver, but they've not done so yet.
[12:21] <rbasak> Apparently I can mess with libxinerama to make X clients think I have six monitors and so everything should work properly
[12:21] <rbasak> Expensive though :-/
[12:22] <rbasak> And I'm still not sure about quiet operation when not doing 3D stuff
[12:23] <infinity> All the high end cards do variable fan speeds and other such things, but the low-end ones (if you're not a hardcore gamer) are often last year's tech, die-shrunk, and passively cooled.
[12:23] <infinity> Which is much more pleasant for a businessy system.
[12:34] <rbasak> infinity: I've been struggling to find a passively cooled one that also does enough heads :-/
[12:35] <mlankhorst> it's a premium
[12:35] <mlankhorst> not something they would put on low end cards
[12:35] <rbasak> Yeah
[12:35] <rbasak> But then it gets noisy :(
[12:35] <rbasak> I have a goal of having a silent office
[12:35] <rbasak> (apart from the noisy keyboard)
[12:38] <mlankhorst> use watercooling :p
[12:38] <rbasak> I have considered that :)
[12:38] <rbasak> Not sure I want the hassle though!
[12:40] <rbasak> doko: are you working on the powerpc FTBFS for juju-core? We could temporarily drop block-proposed from bug 1416051 to allow 1.20 through when that's fixed.
[13:02] <dobey> anyone care to sponsor https://code.launchpad.net/~dobey/ubuntu/vivid/intltool/release-0-51-0/+merge/252235 please?
[13:04] <dobey> rbasak: use a white noise generate to generate a signal that's 180 degrees out of phase with the noise your PC generates :)
[13:05] <rbasak> dobey: I'd prefer not to have to wear a noise cancelling headset in my office thanks :-P
[13:06] <cyphermox> good morning!
[13:06] <dobey> rbasak: don't wear one then. just get a wall plug thing :P
[13:08] <smb> rbasak, I seem to experience bug 1429849 on my current attempts to install VMs from the current server daily. Is this something that is already known?
[13:09] <rbasak> smb: I'm not aware of it. Do you have installer logs handy, please?
[13:10] <smb> rbasak, I got the VM at the point of fail, so yes... just need to send them over
[13:22] <smb> rbasak, Ok a tarball of all logs attached to the bug (could not decide which one, so I went for all of /var/log and /target/var/log)
[13:27] <rbasak> smb: thanks. I wonder if you can see debconf values anywhere?
[13:27] <rbasak> I'm not sure how to retrieve those
[13:27] <rbasak> /var/cache/debconf/config.dat maybe
[13:30] <smb> rbasak, In /target/var/... shall I just attach a copy of that file?
[13:36] <rbasak> smb: yes please
[13:36] <smb> rbasak, its there
[13:37] <rbasak> smb: thanks. Looks like d-i debconf seeds are stored somewhere else :-/
[13:38] <smb> rbasak, Ok... Not sure this is relevant but at least there is some list in config.dat which has vda5 as first element and vda after that...
[13:39] <smb> in grub-pc/install_devices
[13:52] <flexiondotorg_> infinity, An Ubuntu MATE community member has ported Ubuntu MATE 15.04 to the Raspberry Pi 2.
[13:52] <flexiondotorg_> infinity, What packages should I look at for figuring out how to enable this as an official hardware platform?
[13:53] <flexiondotorg_> infinity, I'm guessing livecd-rootfs and debian-cd, but want to check this is indeed possible.
[14:18] <pitti> kirkland: hey Dustin, how are you?
[14:19] <kirkland> pitti: yo!
[14:19] <kirkland> pitti: thanks for the pollinate systemd fixes -- I committed those upstream
[14:19] <pitti> kirkland: I just investigated bug 1429354 -- TL;DR: our installer sets up a /dev/cryptswap1 in crypttab and fstab, but apparently never initializes that device
[14:19] <pitti> kirkland: cheers
[14:19] <kirkland> pitti: oh, sweet
[14:19] <kirkland> pitti: what did you find?
[14:19] <pitti> kirkland: would you mind giving a quick overview in the bug how this is supposed to look and  behave?
[14:19]  * kirkland looks
[14:20] <pitti> kirkland: i. e. I take it we do want some encrypted swap partition which gets reinitialized on boot or so
[14:20] <pitti> but that doesn't seem to work (under either upstart or systemd), just under systemd you actually get an error
[14:20] <kirkland> pitti: right -- mainly that the key to swap should be randomly generated at each boot and never stored
[14:20] <pitti> kirkland: I'm not sure how the fs structure should look like, and when the outer (luks) and inner (swap) devices are supposed to get initialized?
[14:21] <kirkland> pitti: I think the core of the problem is that doing this, creates a different uuid of the partition each boot
[14:22] <pitti> kirkland: right, the UUID in crypttab is certainly weird; but ther's nothing on that partition after installation at all
[14:22] <pitti> not even a LUKS partition
[14:22]  * pitti will be back in one hour or so, I need a break
[14:22] <pitti> I didn't actually expect you to be awake yet :)
[14:22] <pitti> TTYL!
[14:22] <pitti> (there might be another installer bug about that already, just with upstart not telling you about it, it's not easy to discover)
[14:22] <kirkland> pitti: heh, it's 10:30am :-D
[14:23] <kirkland> pitti: okay, I suspect /usr/bin/ecryptfs-setup-swap might need some new logic
[14:23] <pitti> kirkland: larsu did an install with utopic btw, that's not a new thing
[14:23] <kirkland> pitti: right
[14:24] <pitti> kirkland: so, ATM I'd like to understand how this is supposed to work, and then we can see how we fix that, and how we can fix existing installations
[14:25] <kirkland> pitti: sure, you want to ping me in an hour when you're back?
[14:25] <kirkland> pitti: and we can talk through it?
[14:42] <directhex> hi. what's the best way to set up a gcc5 test environment right now?
[14:49] <teward> infinity: around for me to bug you about something?
[15:15] <pitti> kirkland: re
[15:19] <roaksoax> 3/win 13
[15:23] <mlankhorst> mvo: I seem to be unable to create a depends list for ubuntu-sdk that allows me to install it with lts-utopic on trusty, and without lts-utopic on trusty.
[15:38] <mvo> mlankhorst: in a meeting right now, sorry
[15:38] <mlankhorst> feel free to look at it later :)
[15:39] <mvo> mlankhorst: more meeting and then hockey today, but can we talk tomorrow morning? I am around from 8am (european time) :)
[15:39] <mlankhorst> oke
[15:39] <mvo> thanks!
[15:52] <bdmurray> pitti: Can you have a look at bug 1419061, particularly comment #20.
[16:30] <flexiondotorg_> Who can I chat with about creating armv7hf images?
[16:30] <rbasak> flexiondotorg_: try #ubuntu-arm maybe
[16:31] <flexiondotorg_> Thanks.
[17:13] <doko> infinity, could you have a look at https://launchpadlibrarian.net/199754193/buildlog_ubuntu-vivid-amd64.google-perftools_2.2.1-0.2_BUILDING.txt.gz (vivid test rebuild)
[17:28] <tyhicks> pitti: re 953875> Hi - I'm going to be publishing ecryptfs-utils security updates today (if testing goes as planned)
[17:28] <tyhicks> pitti: I wanted to let you know so that your work on the SRU doesn't collide
[17:29] <tyhicks> pitti: the packages that I plan on pushing out can be found here: https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+packages
[18:39] <mdeslaur> pitti: so I just rebooted, and systemd didn't mount my nfs shares
[18:52] <mdeslaur> pitti: bug 1429975
[18:55] <mdeslaur> seb128: please tell me how to kill all the retarded gtk deprecation warnings?
[18:56] <mdeslaur> seb128: is there an environment variable I can set or something?
[20:16] <doko> Riddell, ScottK: looking at https://launchpadlibrarian.net/196577810/buildlog_ubuntu-vivid-amd64.qtwebkit-source_2.3.2-0ubuntu7_FAILEDTOBUILD.txt.gz
[20:16] <doko> https://bugs.webkit.org/show_bug.cgi?id=82824
[20:17] <doko> libxml2 is now built using icu, and qtwebkit already has icu enabled ...
[20:19] <ScottK> Mirv: mitya57 ^^^
[22:03] <sarnold> pitti: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1429938
[22:03] <sarnold> pitti: should those be left against their own packages or filed against systemd?
[22:05] <cjwatson> It may be a bug in the openssh service file
[22:06] <sarnold> I don't know for certain that systemd isn't supposed to do exactly that... but I figured pitti would be in the best position to report intentional/notintentional or suggest fixes
[22:07] <cjwatson> Odd though, we're using KillMode=process
[22:07] <sarnold> .. and this is probably not the last such case, I'm curious where he'd like them aimed :)
[23:04] <infinity> flexiondotorg_: Well, it would be worth discussing what you mean by "ported", first.  But yes, it's mostly a livecd-rootfs thing.  Or telling users to use the d-i netboot image.
[23:04] <infinity> teward: I wasn't, but I am now, ish.
[23:06] <infinity> cjwatson: Isn't the systemd default MO to violently whack the cgroup it started a service in?  I don't speak it fluently enough to know how to intentionally avoid that.
[23:08] <teward> infinity: i think https://bugs.launchpad.net/bugs/1214352 needs your attention - see the bottom of it, and note the OP emailed into bugcontrol asking for an SRU
[23:08] <teward> (you're marked as the assignee for the glib2.0 part)
[23:09] <bluesabre> hey infinity, with the xfce4.12 upload, we have a few packages that will need to be rebuilt (no changes needed) that I do not have upload rights for, not sure if you'd be interested in triggering those rebuilds?
[23:09]  * bluesabre needs to request a xfce packageset
[23:09] <infinity> bluesabre: Toss me a list.
[23:10] <infinity> bluesabre: And yes, a packageset would be helpful.  How do you not have one?
[23:10] <infinity> bluesabre: Or is it that there's a "xubuntu" one, but we need a generic "xfce" one for studio/xubuntu/etc that all overlap?
[23:10] <bluesabre> xfce4-eyes-plugin xfce4-hdaps xfce4-mixer
[23:10] <bluesabre> we have a xubuntu one, but no xfce one
[23:11] <bluesabre> I'll request its creation... as a xfce contributor I'll also request upload rights for it as a whole
[23:11] <Unit193> Should be just about everything pkg-xfce has access to, minus lightdm.
[23:11] <infinity> teward: Well, we're not rebuilding everything in precise that depends on glib2.0.  So, I need to assess what we can do with minimal impact there.
[23:12] <bluesabre> what Unit193 indicated :)
[23:12] <teward> infinity: i think it was already mentioned the regression potential is infinite and that it's a bad SRU candidate
[23:12] <teward> infinity: and that was when Dave Kokandy marked it Fix Released on glibc
[23:13] <infinity> teward: s/glibc/glib/ :P
[23:13] <infinity> Don't worry, I can't type "glib" without a backspace either.
[23:13] <teward> infinity: true
[23:14] <ochosi> shouldn't that be "infinitely true"?
[23:14] <cjwatson> infinity: Yeah, but I thought KillMode=process stopped it doing that.
[23:15] <teward> infinity: i think it just needs someone who knows more to say "We can't, here's why: foo bar baz foo reason foo foo"
[23:16] <infinity> teward: Yeah, I just haven't had the time to sit down and stare at it.  If the only thing it deeply affects (in a user-facing noticeable way) is LibreOffice, it's still possible we could do a targetted rebuild of some bits there, but I'm not sure it's worth the effort either.  I'll give it some thought.
[23:16] <teward> infinity: i think that's not what the current case is
[23:17] <teward> oop my bad
[23:17] <teward> i have 5 bugs on screen, confusing myself
[23:17] <teward> infinity: yeah it seems to be a LibreOffice issue, but if fixing it in glib to fix it in libreoffice would cause problems for everything else, you hit the infinite regression potential problem again
[23:18] <teward> infinity: if I had a say in it (and I don't really) I'd say it's not SRUable because of the regression potential, but I'm not affected by the issue
[23:18] <teward> (trusty is better than precise :P
[23:18] <infinity> teward: Yeah, I dropped a comment on the bug to that effect, but am in no mood (took a personal day today) to actually think hard about it.
[23:18] <teward> infinity: indeed.
[23:18] <sarnold> honestly how many programs are goin to be doikng byteswaps? how many of those will use the macros with complex arguments?
[23:19] <teward> infinity: sorry for bugging you on your 'personal day', i just wanted someone who has a familiarity with the bug/issue to take a peek
[23:19] <teward> since that user is bugging bugcontrol on the SRU i thought i'd poke someone much more familiar with the bug
[23:19] <infinity> teward: To be fair, I'm not sure that fixing the macro is actually much of a regression potential at all, since most callers will get exactly the same result they always did, except the ones that were already broken.
[23:19] <teward> mmm
[23:19] <infinity> teward: But glib's rdep list is impressively long, so some care is required.
[23:20] <teward> infinity: right.
[23:20] <teward> infinity: if this is fixable in just LibreOffice that reduces the potential.  But if it ends up needing SRU'd with all the packages on that bug (glib included) then it's poor candidate
[23:21] <teward> infinity: given Norbert and LocutusOfBorg's comments on the bug though it looks like they were looking at glib updates, which is why i pinged you
[23:21] <teward> thanks though
[23:22] <infinity> teward: The correct fix is in glib, yes.  I wasn't arguing otherwise.
[23:22] <infinity> teward: That said, once glib is fixed, a non-determinate number of rdeps need to be rebuilt to make libreoffice happy.
[23:22] <infinity> (According to the penultimate comment, fixing glib and rebuilding LibO wasn't enough)
[23:23] <infinity> Or, someone did it wrong. :P
[23:23] <infinity> That said, one could fix it just in LibO, if that was all that needed the rebuild, by just redefining that macro after every inclusion of glib.h
[23:23] <teward> infinity: right
[23:24] <infinity> Realistically, though, if anything was relying on the broken non-bracketed behaviour, I'd be very surprised.
[23:24] <infinity> Either you were calling with a single non-complex argument, and it works either way, or you're not, and it was subtly broken and you didn't notice because you don't have a testsuite or users.
[23:26] <infinity> I can't think that anyone was calling it with complex arguments and thinking "boy, aren't we lucky that this macro misparses the arguments in just the way we were hoping?"
[23:26] <teward> infinity: do you mind if i quote you here either in paraphrasing or direct quotes in my response to their message to the 'bugcontrol' list?
[23:26] <teward> (Just so they know *someone* is watching their messages)
[23:26] <infinity> teward: All the copy-and-waste you want, go for it.  This is a publically logged channel. :P
[23:26] <teward> infinity: indeed.
[23:26] <teward> whether the person emailing in knows how to log it, is another story.
[23:27] <teward> blargh, the page hasn't updated on irclogs
[23:27] <teward> i'd give a link if it were
[23:28] <infinity> teward: I think that only updates hourly or something unhelpful.
[23:28] <teward> mmm
[23:29] <infinity> sarnold: What's your take on my regression potential analysis above?  Starting around 24m past whatever hour it is for you.
[23:30] <sarnold> infinity: I suspect you're right, I especially luiked the bit about no tests or no users :)
[23:32] <sarnold> chances are good very little needs to be rebuilt, but just rebuilding packages that actually used the macros should be safe and not as terrible as building everything with build-dep headers
[23:32] <infinity> sarnold: Yes, we need a codesearch.ubuntu.com :P
[23:32] <sarnold> infinity: yes.
[23:34] <infinity> sarnold: That said, I think finding the exact package(s) that need(s) love to fix the LibreOffice sadness is probably all we really need to do here.  It's not like people are piling on this bug from 37 different "it also breaks $foo" directions.
[23:34] <infinity> So, checking LibO deps for the macro being used might be less painful and greppable locally without a fully unpacked mirror and a search engine. :P
[23:35] <sarnold> infinity:  it's a balance of human time to check programs vs build farm time / mirror downloads space and time...
[23:36] <infinity> sarnold: I'm not actually hugely concerned about machine time, but having to download 280 packages to fix a bug is not ideal (PS: this incident is a great example for the static linking lovers) and, furthermore, impossible for us to test before we release.
[23:37] <infinity> sarnold: If we just fix glib and, say, 3 LibreOffice deps, we can actually test those, and then future rebuilds of other glib things for other SRUs will get tested when they happen, and people can yell at us if the macro fix broke them (which it won't have, but at least the binaries are legitimately being tested).
[23:38] <sarnold> infinity: good points
[23:44] <infinity> teward: Anyhow, today was a day I set aside for not thinking, so that's enough for me.  But if I forget about this, feel free to bug me later in the week. :P