[03:59] <lamont> what does it mean when .xsession-errors has: upstart: at-spi2-registryd respawning too fast, stopped
[04:43] <pitti> Good morning
[04:43] <pitti> flexiondotorg: wow, congratulations!
[04:52] <pitti> infinity: seems your linux force-badtest isn't working? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[06:33] <mardy> seb128: Hi! A friend is affected by bug 1286779 in trusty
[06:34] <mardy> seb128: as seen from other comments, it seems that the bug was fixed in utopic, but the fix was not backported yet
[06:34] <mardy> seb128: do you know how one can mark the bug as still being in Confirmed state for a series?
[06:35] <mardy> seb128: because the problem is that users who look at this bug page, are led to think that the bug is fixed in all versions, and they get confused
[06:45] <mardy> Mirv: or do you know? ^
[06:56] <Mirv> mardy: you can propose it for a series
[06:56] <Mirv> mardy: use the "Nominate for series"
[06:57] <Mirv> which should be on the right of "Also affects distribution/package" unless it requires some rights
[06:58] <infinity> pitti: The linux badtest was superseded by a newer linux.
[06:58] <mardy> Mirv: I think it does, I don't see it
[06:58] <infinity> pitti: Which, I hope, also fixes the test...
[06:59] <Mirv> mardy: ok, nominated. since there's a patch and there's the impact/testcase/regressionpotential trio (as per https://wiki.ubuntu.com/StableReleaseUpdates), can you subscribe ubuntu-sponsors to the bug?
[06:59] <seb128> mardy, Mirv, what Mirv said, you should be able to propose it for nominations even if you can't approve those (or is that restricted to ubuntu bugsquad?)
[07:00] <Mirv> seb128: I think even nomination might be bugsquad only, "Ask the Ubuntu bug control team to nominate the bug"
[07:00] <mardy> seb128: there's just no "Nominate for series" link anywhere for me
[07:01] <seb128> mardy, I guess you are not in ubuntu bug control, I though you would be, sorry
[07:03] <Mirv> mardy: ok it should be all set and be visible at http://reqorts.qa.ubuntu.com/reports/sponsoring/ soonish
[07:03] <mardy> seb128: np. Should I be in that group?
[07:04] <seb128> mardy, well, apparently you are not missing not being in it? I though you were triaging the ubuntu bugs for the packages you maintain, and without that team memberships you don't have full triaging rights, do you?
[07:04] <mardy> Mirv: thanks
[07:06] <mardy> seb128: correct. I generally don't need these permissions, but sometimes I feel the need of editing the status of bugs for the software I maintain, when they are filed on the source package
[07:07] <seb128> mardy, yeah, other teams tend to ask for bugsquad memberships because most team standardize on using the ubuntu package buglist as their main buglist, since that's where most users are going to file bugs
[07:07] <seb128> mardy, anyway, if you want to be added just talk to bdmurray about it
[07:07] <mardy> seb128: OK, thanks!
[07:08] <seb128> yw!
[07:08] <mardy> seb128: just to be safe: if I get that membership, will I get notifications for all Ubuntu bugs, even those I don't care about?
[07:08] <seb128> mardy, no, bugsquad has a list, emails go to the list, if you don't subscribe to the list you don't get any email
[07:09] <mardy> seb128: cool, thanks
[07:09] <seb128> yw :-)
[07:13] <doko> pitti, autopkgtest for zope.session 3.9.5-0ubuntu2: Regression (Jenkins: public, private)
[07:13] <doko> but the link shows success ...
[07:21] <pitti> doko: erk, public jenkins fail, it's missing the log from #6; see http://d-jenkins.ubuntu-ci:8080/view/Vivid/view/AutoPkgTest/job/vivid-adt-zope.session/lastBuild/?
[07:25] <doko> pitti, ahh, thanks
[07:31] <seb128> didrocks, pitti, slangasek: btw what's the status of the systemd transition? still looked at for vivid? do we have a bug/ffe recording the status, what's still needed, etc?
[07:32] <didrocks> seb128: IIRC, slangasek told to pitti the other day to go ahead on the NFS systemd porting
[07:32] <didrocks> as he didn't get the time to catch it
[07:32] <didrocks> and NFS upstream has a systemd unit
[07:32] <seb128> k
[07:32] <pitti> yeah, that's the status now -- we need to find someone to fix NFS
[07:33] <seb128> do we still plan to do it/have a ffe filed for it?
[07:33] <didrocks> that's all about my knowledge, getting back some butter to spread on bread (like my knowledge :p)
[07:33] <pitti> (and get familiar enough with it to test)
[07:33] <pitti> didrocks: so I guess you aren't interested in looking at it?
[07:34] <pitti> I need to work on some other urgent things today/Monday, but I'll try to find some time to set up a test system and get familiar with our split upstart jobs and the NFS components
[07:34] <didrocks> pitti: I don't have enough knowledge apart from having used it for a while (and not anymore), but it seems to be quite tricky, no, like /home or /usr on NFS…?
[07:34] <didrocks> I can give a look on Monday if needed
[07:34] <pitti> didrocks: let's not start /usr on NFS :)
[07:35] <didrocks> but I would clearly need double checking :)
[07:35] <pitti> /home or /srv or so are quite reasonable, though
[07:35] <pitti> didrocks: yeah, we can team up, to add our (so far) nonexistant knowledge :)
[07:35] <didrocks> pitti: let's do that, I'll start on Monday
[07:36] <pitti> didrocks: I propose we first figure out a bunch of scripts/VMs to test this under upstart, then port the server (NFS server should be really simple, compared to client), and then tackle the client bits
[07:36] <pitti> didrocks: nice, thanks! the two of us should figure this out hopefully
[07:37] <didrocks> pitti: let's cross fingers! (and sounds like a good plan)
[07:37] <pitti> didrocks: right, upstream git has systemd units, let's see how well they match up with our upstart job / existing config files
[07:37] <pitti> although I'd hope that we didn't change upstream's config files in Ubuntu
[07:38] <didrocks> yeah, I guess a new week with fresh brain will help :)
[07:38] <pitti> meh, systemd's tests take aaages now; but oh well, ++confidence
[07:39] <pitti> speaking of that, we don't have an fsck test yet
[07:39]  * didrocks always prefer long running tests (especially when you don't have to run on your machine itself) than no confidence :)
[07:39] <didrocks> yeah, I want to tackle this
[07:39] <didrocks> I think I would have to go to integration tests, not sure about units…
[07:40] <didrocks> and having a mock plymouth socket, listening to events
[07:40] <pitti> didrocks: nah, an integration autopkgtest
[07:40] <didrocks> that wouldn't do it for upstream though, right?
[07:40] <pitti> didrocks: like, plug in the mock fsck, check that the systemd still starts and that fsckd ran and finished, somethign like that?
[07:40] <didrocks> oh, no more fine-grained?
[07:41] <didrocks> maybe sending at least a Control+C and seeing it being intterupt?
[07:41] <didrocks> (if it's easy to do that in autopkgtests)
[07:41] <didrocks> interrupt*
[07:41] <pitti> didrocks: well, something that guards against boot failure is already valuable; verifying that it displays the expected stuff is harder, but also much easier to recover from if we screw that up
[07:42] <pitti> didrocks: upstream also has these VM tests; the same approach ought to work there, too
[07:42] <didrocks> yeah, I would still like that we check cancellations works
[07:42] <didrocks> oh nice
[07:42] <didrocks> just need to ensure it's easy to send key press to the vm
[07:42] <pitti> didrocks: hm, injecting ^C into plymouth in a VM without screen or keyboard, we have to think about that
[07:42] <didrocks> yeah
[07:42] <pitti> didrocks: we could talk to the monitor, but an autopkgtest doesn't have access to that
[07:43] <didrocks> right, as it's inside the vm…
[07:43] <pitti> didrocks: oh, perhaps via uinput
[07:43]  * didrocks doesn't know that, but noting down…
[07:43] <pitti> didrocks: http://thiemonge.org/getting-started-with-uinput
[07:43] <didrocks> pitti: first google result ;)
[07:43] <pitti> didrocks: it's what autopilot uses as well to fake keypresses and mouse moves
[07:44] <pitti> ah, /me pats firefox awesome bar :)
[07:44] <didrocks> heh :)
[07:44] <didrocks> pitti: ok, if it works, just need to ensure I can get the right timing (when checking for process)
[07:44] <didrocks> and having a flag in the mock fsck to tell "fsck ended properly"
[07:44] <didrocks> and just checking the flag file isn't prevent when cancelled and no more process
[07:44] <didrocks> sounds easy enough
[07:46] <pitti> didrocks: so you'd need to create a unit which runs on boot Before=systemd-fsck-root.service and then sets up uinput and polls for /sbin/fsck? (or just fsckd running)
[07:46] <pitti> didrocks: the autopkgtest will only resume after the boot finished, so you can't do it right there; but adding such a helper unit before reboot should work
[07:47] <didrocks> pitti: yeah, the unit approach for this sounds the easiest and putting flags
[07:53] <dholbach> good morning
[07:55]  * pitti waves to dholbach
[07:58] <dholbach> hi pitti
[08:03] <darkxst> hey pitti, didrocks
[08:04] <darkxst> is systemd init still happening this cycle?
[08:04] <didrocks> darkxst: hey! backlog here, we discussed about NFS ^ I guess once it's done, we can discuss the FFe
[08:04] <pitti> we still aim for it, yes
[08:05] <darkxst> ok we have a really bad bug (some sort of race) with upstart init atm and that will need to be fixed if systemd doesnt land
[08:07] <darkxst> bug 1424731
[08:28] <pitti> doko: ah, missing pkg_resources.component_re is indeed related to new setuptools, right? is that intended, and zope.session needs to be updated, or is that a setuptools bug?
[08:28] <infinity> pitti, jibel: Seeing tests for "glibc_2.19-10ubuntu2" on vivid's update_excuses, which is utopic's version.  I assume the same as the linux_3.16 thing I saw yesterday...
[08:28] <pitti> infinity: right
[08:29] <infinity> pitti: Any idea what's up with that? :P
[08:29] <pitti> infinity: not immediately, I'm afraid; this code is horrible, and I had hoped it would have died several months ago :/
[08:31] <pitti> so the version is correct in results.history
[08:39] <doko> pitti: van.pydeb fixed
[08:39] <pitti> doko: ah, that's what zope.session used? thanks
[08:39] <pitti> doko: if it doesn't re-trigger the test automatically, I'll kick it in about an hour
[08:40] <doko> pitti, van.pydeb is now in the release pocket
[08:41] <pitti> ah, great (doesn't even need to be, proposed is enough); zope.session test requeued
[08:41] <pitti> but the queue is full, will take a bit
[08:43] <jibel> infinity, I think it's the same thing than linux yesterday, but didn't find what it is yet.
[08:43] <jibel> +1 to make this code die quickly
[08:47] <doko> infinity, what is the status of the two disabled ppc64el buildds? besides being disabled
[09:03] <apw> doko, would the curent failure on the glibc test regarding relocs be related to the binutils fix you uploaded this hour ? (see pm for the errors)
[09:04] <doko> apw, that was updated on Tuesday, not now. it just migrated
[09:10] <apw> doko, ahh so it did, fooled me
[09:11] <doko> apw, but honestly, let's wait until infinity uploads glibc-2.21 built with GCC 4.9 ...
[09:12] <apw> doko, you think that will ever build :)
[09:13] <doko> the limiting factor is infinity, not GCC ;-P
[09:33] <infinity> doko: How does waiting for a new glibc change that the current binutils broke glibc's testsuite? :P
[09:35] <doko> infinity, is it binutils?
[09:35] <infinity> doko: It sure looks like it at a glance.
[09:36] <infinity> /usr/bin/ld: copy reloc against protected `protvaritcpt' is invalid
[09:36] <infinity> /usr/bin/ld: failed to set dynamic section sizes: Bad value
[09:36] <infinity> collect2: error: ld returned 1 exit status
[09:36] <doko> and you are sure that gcc-4.8 is still correct?
[09:37] <infinity> No code changes in glibc, hard to blame anyone else but binutils or gcc.
[09:37] <doko> I like makefiles like these:
[09:37] <doko> # Beautified output
[09:37] <doko> quiet_GEN = @echo "  GEN        $@"; $(GEN)
[09:37] <doko> quiet_CC  = @echo "  CC $@"; $(CC)
[09:37] <doko> quiet_LD  = @echo "  LD $@"; $(LD)
[09:37] <doko> quiet_INSTALL = @echo "  INSTALL        $?"; $(INSTALL)
[09:38] <infinity> doko: Erm, I'm sure we should move to 4.9 at some point, but "the toolchain we're using stopped working correctly" is the bug being reported here.
[09:38] <doko> infinity, what is the status of the two disabled ppc64el buildds? besides being disabled
[09:40] <infinity> doko: Non existant, except in the UI.  They will exist again some day.
[09:41] <doko> ugh
[09:43] <infinity> https://sourceware.org/bugzilla/show_bug.cgi?id=17709 <-- binutils regression that hjl is blaming on glibc, and no fix in either project.  Yay.
[09:47] <doko> he's blaming it on glibc ...
[09:47] <doko> apw, is there a build log in launchpad?
[09:49] <infinity> doko: Yes, I said he's blaming it on glibc. :P
[09:50] <infinity> doko: Still, bisecting the offending breakage in binutils (that was backported from 2.26 to 2.25, apparently, yay cowboys) shouldn't be too hard?  I don't think it's unreasonable to expect to be able to build current glibc with our binutils.
[09:50] <apw> doko, it is in the adt builders, i'll paste the log urls in pm for you
[09:53] <infinity> pitti: Can we revisit the concept of artificial rdeps for triggering tests that we want despite no direct dependencies?  (ie: glibc/binutils)
[09:54] <pitti> infinity: yes; that's somewhere in the big stack of things to do, create a Tests.gz index (like Packages.gz, but for all debian/tests/control)
[09:54] <pitti> with that we can do reverse test dependency triggering
[09:54] <pitti> infinity: binutils ought to trigger on glibc uploads already, though?
[09:55] <infinity> pitti: If it does, someone forced binutils in...
[09:55] <infinity> pitti: Err, no.  The other way around.
[09:55] <infinity> pitti: binutils needed to trigger a glibc test.
[09:55] <infinity> pitti: And glibc doesn't depend on binutils (why would it?)
[09:56] <pitti> right; I think that's the direction which isn't currently happening
[09:56] <pitti> actually it does
[09:56] <pitti> Build-Depends: ... binutils (>= 2.21)
[09:56] <infinity> pitti: Some of this would be caught if we were also testing rbuilddeps along with rdeps, but that doesn't really help for build-essential. :P
[09:56] <infinity> pitti: We don't test rbuilddeps, do we?
[09:56] <pitti> infinity: we do; at least the code makes an effort to
[09:57] <pitti> and we most certainly want to
[09:57] <infinity> pitti: Well, I'm going to go with "no, you really don't".
[09:57] <infinity> pitti: Cause the last glibc test was Feb 19, and binutils was uploaded way after that.
[09:57] <infinity> pitti: And it migrated without fuss.
[09:57] <pitti> infinity: maybe, but that's a bug then, and not intended
[09:58] <pitti> infinity: no, I have a "Jenkins Failure - vivid-adt-glibc 32" from this morning
[09:58] <pitti> http://d-jenkins.ubuntu-ci:8080/job/vivid-adt-glibc/32/? clearly failed
[09:58] <infinity> pitti: Is it really a bug, though?  The number of people who build-dep on build-essential packages when they shouldn't would blow up the reverse test map, I'd guess.
[09:58] <infinity> pitti: Yes, 32 was after binutils had migrated.
[09:59] <doko> infinity, there's a lot of the copy-relocs changes ... will need to do that manually
[10:02] <pitti> infinity: hm, digging through http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses/vivid/2015-02-27/ to see excuses; whee, we run it every 10 mins now?
[10:02] <pitti> er, what is that
[10:02] <pitti> are they double-gzip'ed?
[10:02] <pitti> so they are
[10:03] <jamespage> pitti, morning - the latest python2.7 update had a slightly bad effect on gobject-2 - see bug 1426294
[10:04] <pitti> infinity: confirmed, bintuils only triggered a handful of packages, not glibc
[10:05] <pitti> argh bug :/ /me piles on TODO to investigate
[10:05] <pitti> jibel: reverse build deps triggering not working doesn't happen to ring a bell, I figure?
[10:05] <jibel> pitti, no it's new.
[10:06] <jamespage> pitti, related to:
[10:06] <jamespage> Issue #22079: PyType_Ready() now checks that statically allocated type has
[10:06] <jamespage>       no dynamically allocated bases.
[10:06] <pitti> jibel: ack, so TODO it is
[10:06] <jibel> pitti, I can have a look in 1hour or so
[10:12] <infinity> pitti: I'm still not positive we *want* reverse build-deps to trigger.  You might want to build a map of what that would look like before doing it.
[10:16] <doko> jamespage, any update on the required gccgo-go changes?
[10:17] <jamespage> doko, switching to use the go stuff provided by gccgo right?
[10:17] <doko> yes
[10:17] <doko> if it works ...
[10:18] <doko> jamespage, I can add go and gofmt symlinks too in gccgo for those architectures where go and gofmt don't exist (arm64, powerpc, ppc64el?)
[10:19] <jamespage> doko, both golang-go and gccgo-go use alternatives for the various binary conflicts - maybe follow that approach? then we can switch between them for comparison
[10:19] <jamespage> if all is good then we can just drop gccgo-go
[10:19] <jamespage> I'm all up for that - it was a temporary hack I was never that happy with
[10:21] <doko> jamespage, so both go and gofmt are handled by alternatives?
[10:22] <jamespage> let me check
[10:22] <jamespage> I think it might just be go
[10:28] <flexiondotorg> Morning
[10:29] <flexiondotorg> pitti, dholbach Just wanted to say thanks for your help getting Ubuntu MATE official.
[10:29] <flexiondotorg> You went online last night when I thanked the others.
[10:29] <flexiondotorg> Oh, and didrocks. Thanks.
[10:29] <flexiondotorg> https://ubuntu-mate.org/blog/ubuntu-mate-vivid-beta1/
[10:29] <dholbach> thanks a lot for working on Ubuntu MATE :-)
[10:30] <dholbach> great work!
[10:30] <pitti> flexiondotorg: ^5s, great work!
[10:31] <didrocks> you're welcome flexiondotorg, nice work on Ubuntu MATE! ;)
[10:31] <darkxst> hey flexiondotorg
[10:31] <flexiondotorg> darkxst, 'sup?
[10:32] <darkxst> flexiondotorg, winding down for the night, built a deck today so a little sore
[10:34] <jamespage> doko, just go atm
[11:01] <doko> jamespage, can we do that for gofmt too, or isn't that installed by golang?
[11:18] <xnox> hallyn: where is shadow upstream?
[11:32] <Mirv> pitti: is that the bot of yours or are you manually rekicking autopkgtest jobs? thanks, regardless of which :)
[11:33] <pitti> Mirv: it's the jenkins -> imap -> mutt -> pitti -> jenkins pipeline :)
[11:33] <Mirv> oh, that automation :)
[11:33] <pitti> our CI machines are melting again, and we get the usual random fallout
[11:45] <mardy> pete-woods: hi! Do I understand correctly, that libqtdbusmock is something that makes it easier to use python-dbusmock from Qt apps?
[11:46] <mardy> pete-woods: I'm having a look at the code, but despite seeing python3-dbusmock in the deps, I don't find where it's using it
[12:21] <pete-woods> mardy: there are two related libraries. libqtdbusmock and libqtdbustest. the former makes talking to dbusmock easier, while the latter simplifies testing dbus stuff in Qt much easier
[12:23] <pitti> tseliot: hm, ubuntu-drivers-common's tests recently started to fail on the -304 versions; are you aware of any recent changes there?
[12:25] <pete-woods> mardy: each time you register a mock in qtdbusmock, it registers a binary, and associated dbus stuff to look for against libqtdbustest
[12:25] <pete-woods> so it's actually the test lib that starts dbusmock
[12:25] <pete-woods> but the mock lib that configures it
[12:27] <tseliot> pitti: maybe I forgot to patch it to work with linux 3.19. That would explain it (if you're talking about vivid)
[12:27] <pitti> tseliot: yes, vivid
[12:27] <pitti> tseliot: ah, could have been triggered by the new kernel, indeed
[12:27] <tseliot> pitti: I'm trying to install it in my chroot to see if I can reproduce the problem
[12:29] <pitti> tseliot: note the new kernel is still in vivid-proposed
[12:29] <pete-woods> mardy: http://bazaar.launchpad.net/~unity-api-team/indicator-network/integration-testing/view/head:/tests/integration/indicator/TestIndicatorNetworkService.cpp is a reasonably detailed example of usage
[12:29] <tseliot> pitti: is it possible that we are getting the failure from vivid-proposed?
[12:29] <pitti> tseliot: yes, we run all tests in -proposed
[12:30] <pitti> tseliot: we want to detect regressions in -proposed already after all, not only when they already landed
[12:30] <pitti> ... usually
[12:30]  * pitti waves at binutils and sighs
[12:31] <pete-woods> mardy: http://bazaar.launchpad.net/~indicator-applet-developers/hud/trunk.15.04/view/head:/tests/unit/service/TestVoice.cpp is a simpler example, with more usage of the dbusmock interface
[12:31] <tseliot> pitti: ok, good, that's what I remembered but I wasn't sure
[12:33]  * tseliot -> lunch
[13:10] <mardy> pete-woods: thanks a lot, that's very useful!
[13:14] <diwic> Hi. It seems PulseAudio 1:6.0-0ubuntu4 is stuck in proposed? I thought this was due to beta freeze, but the beta freeze should be over, and thus PA should migrate to the release pocket?
[13:15] <pitti> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#pulseaudio
[13:15] <pitti> looks like another jenkins hiccup, I restarted fluidsynth
[13:15] <diwic> pitti, ok, thanks
[13:19] <infinity> pitti: While people are being whiney about autpkgtest, the public mirror sure seems to be laggy...
[13:20] <pitti> retoaded, psivaa_ ^ that's something I can't help with; can you?
[13:21] <pitti> publishing queue of public jenkins?
[13:23] <infinity> pitti: I assume (hope?) that in the magical jenkins-free debci future, this will all be real-time via a public interface, instead of the user-hostile private/public split?
[13:23] <pitti> infinity: yes, should be; the cloud will save us all (famous last words..)
[13:26] <psivaa_> pitti: i've resurrected publisher plugin, i'll also watch it for some time
[13:26] <pitti> psivaa_: thanks
[13:37] <hallyn> xnox: github.com/shadow-maint/shadow
[13:38]  * hallyn mostly afk today - \o
[13:38] <xnox> hallyn: why that history is disjoint from git://anonscm.debian.org/pkg-shadow/shadow.git ?
[13:39] <hallyn> bc that one is the packaging tree.  (used to be separate mercurial branches)
[13:41] <hallyn> xnox: i thought there was a new github.com/shadow-maint tree for that one, buti don't see it...  hm
[13:42] <xnox> hallyn: i'll send patches to both, and mailing list.... i guess....
[13:44] <hallyn> xnox: thx.  i'll be back in on monday;  we can discuss more then if you like, especially if you have time/inclination to help out :)
[13:44] <hallyn> (the maintainers are pretty busy)
[13:48] <xnox> hallyn: i have a bunch of patches....
[13:52] <hallyn> cool.  i can help review and push upsream, but i don't touch the packaging tree
[13:53] <hallyn> anyway, i'll be in on monday - ttyl
[13:54] <rbasak> cjwatson: I've just come across bug 669481 and 872244 and am concerned about the default server headless case. utlemming thinks that you had a concern about desktop so didn't want to change the default.
[13:55] <rbasak> (this is about GRUB_RECORDFAIL_TIMEOUT)
[13:55] <rbasak> cjwatson: do you remember what the concern was please? I can't find any record of it.
[14:11] <infinity> rbasak: I ran into that with my parents' firewall a coulpe of months ago and had a conversation with Colin about it where, I *think* we concluded that an infinite timeout is bad, *but* the proper solution should probably involve a loop counter.
[14:14] <rbasak> infinity: in the shorter time, how about 30 or 60 seconds or something? Definitely on headless servers. I don't mind about desktops.
[14:14] <rbasak> shorter term
[14:15] <rbasak> infinity: it this necessitates server being different from desktop, I'd like to sort that out. I feel quite strongly that this is a critical bug in server LTS releases.
[14:15] <infinity> rbasak: I think the conversation (and the right answer) applies to both, TBH.  I don't really want to see a forked config here based on some heuristic about what a "server" is.
[14:16] <infinity> rbasak: Check, say, Win7/8, where a failed boot or unclean shutdown will present you with a menu with a 30s timeout.  I suspect most people think this is reasonable.
[14:16] <rbasak> infinity: so we can just set GRUB_RECORDFAIL_TIMEOUT=30 by default, no?
[14:17] <infinity> rbasak: But, ideally, we also don't want people in an infinite reboot loop either, which could happen with the right sort of breakage.
[14:17] <infinity> rbasak: But yeah, I think catering to the edge "what if there's a loop" case is probably being obtuse, and setting the timeout to 30 is probably a good first step.
[14:18] <cjwatson> rbasak: I'm afraid I don't remember the details.  I may have been acting under instructions from design or something.
[14:19] <rbasak> cjwatson: OK, no worries. Any objection to setting the default to 30 in Vivid now?
[14:19] <cjwatson> rbasak: 30s doesn't seem unreasonable, but please don't change the default config file if you can possibly avoid it to avoid potential upgrade prompts; it can be changed in 00_header instead.
[14:19] <cjwatson> rbasak: My only objection would be if it were done in an Ubuntu patch, rather than changing it in Debian.
[14:19] <rbasak> OK
[14:19] <cjwatson> Since it took me literally years to get the packages back in sync ...
[14:20] <cjwatson> (I haven't been able to find any record of this past conversation in my IRC logs.)
[14:20] <cjwatson> rbasak: If somebody sends me a patch I'd be happy to integrate it into the packaging in unstable.
[14:21] <rbasak> cjwatson: OK thanks. I'll see what I can do.
[14:21] <cjwatson> Don't worry too much about it being in exactly the right form, since it'll need to be several items deep in a git-dpm stack anyhow.
[14:21] <infinity> cjwatson: The conversation that led to the current behaviour, or the conversation with a grumpy me when I ran into it? :P
[14:21] <cjwatson> I just want something tested to have the right kind of behaviour.
[14:21] <cjwatson> infinity: The one utlemming thinks I had with them.
[14:22] <infinity> Or that.
[14:22] <cjwatson> Could've been at a sprint, I guess.
[14:22] <rbasak> utlemming thinks there was a reason that the default wasn't set to something positive in the first place.
[14:22] <infinity> cjwatson: Anyhow, I vaguely recall you and I agreeing that the current default was crap, but I don't recall if we mapped out what we thought the Right Thing was.
[14:22] <cjwatson> The best guess I have would have been concerns about infinite reboot loops, or possibly something to do with picking an appropriate default.
[14:22] <infinity> But a 30s delay seems like an okay compromise for now.
[14:23] <cjwatson> (that people could react to in reasonable time, since most people read slower than geeks who've seen the boot screen a thousand times)
[14:23] <cjwatson> But, hey, if it's wrong for everyone, I don't have a problem with trying a change.
[14:24] <infinity> I don't think "infinite" or "long enough to read all the text on the screen" are appreciably different for desktop users, especially when most of them will hit <enter> without reading it anyway.
[14:25] <infinity> And infinite is clearly wrong for unattended rebooting.
[14:25] <infinity> cjwatson: Oh, I remember how I was bitten by this.  Brownouts.  Machine bounced twice in under a minute, and the second one killed it.
[14:25] <cjwatson> Yeah, that'd do it
[14:25] <infinity> cjwatson: Which seems like a not unlikely scenario for power loss in general.
[14:26] <rbasak> That fits my understanding. Second failure after grub but before /etc/init.d/grub-common runs.
[14:30] <infinity> rbasak: That exact scenario on a Windows machine (for instance) will land you at either a 30s or 60s (I think 30, but I'd have to bounce a machine to see) timeout that says "we failed to boot completely on the last attempt, how do you feel about maybe trying safe mode?"
[14:32] <infinity> Ahh, youtube to the rescue, it's 30s.
[14:33] <infinity> rbasak: https://www.youtube.com/watch?v=WcLDch_OO3k#t=110 <-- For reference.
[14:33] <infinity> rbasak: And they have a fair bit of text to read, so I think 30s would be fine for us.
[14:33] <infinity> cjwatson: ^
[14:35] <infinity> Now, the difference is that they default to "recovery mode", and I think that would still be wrong for us, since our recovery mode doesn't have networking.
[14:35] <infinity> Or startup repair, even.  Which we don't have.
[14:36] <rbasak> Our most likely failure mode is a kernel upgrade.
[14:37] <rbasak> So ideally maybe default to the last known working kernel? That sounds non-trivial though.
[14:48] <pitti> doko: FYI, http://d-jenkins.ubuntu-ci:8080/view/Vivid/view/AutoPkgTest/job/vivid-adt-zope.session/8/ARCH=amd64,label=adt/console now fails because van.pydeb's module doesn't import "re"
[14:49] <doko> pitti, ouch!
[14:54] <xnox> pitti: nice catch =)
[14:56] <aeoril> I am trying to debug apport, so I have made a small application that just SIGSEGVs itself.  I have checked and apport seems to be fully enabled on trusty.  Why might this not bring up apport? https://gist.github.com/aeoril/7d2538d3db393d4b28a3
[14:56] <mardy> pitti: hi! About python-dbusmock: I'm adding a method which returns "a(ua{sv})", but I'm not sure how to code the return value ("ret = ...")
[14:56] <mardy> pitti: should I use GVariant, or just python types?
[15:01] <pitti> aeoril: probably because it's not a packaged application
[15:01] <pitti> aeoril: check /var/log/apport.log
[15:01] <pitti> aeoril: my favourite crash test is to call sh -c 'kill -SEGV $$'
[15:02] <pitti> aeoril: that'll create a report for dash
[15:02] <aeoril> pitti ok, thanks - what is dash?
[15:03] <pitti> aeoril: our default /bin/sh; you can also call bash -c ... of course, if you prefer
[15:03] <pitti> mardy: there is no automatic conversion, this is using dbus-python
[15:03] <aeoril> pitti ok, got it - thanks!  That will really help I am sure!
[15:04] <pitti> mardy: so you have to return something like dbus.Array([], signature='v')
[15:04] <aeoril> pitti just out of curiosity, what do the $$s do on that line?
[15:04] <pitti> aeoril: it's a magic variable whose value is the current pid
[15:05] <aeoril> pitti I figured, but was just checking - thanks!
[15:05] <pitti> aeoril: i. e. that starts a shell, and sends a SIGSEGV signal to itself
[15:05] <aeoril> gotcha! :)
[15:05] <mardy> pitti: ok, thanks
[15:06] <aeoril> pitti worked like a charm! :) thanks!
[15:26] <doko> pitti, van.pydeb in -release
[15:27] <pitti> doko: zope.session running
[15:29] <Laney> doko: do you know how to fix https://bugs.launchpad.net/ubuntu/+source/terminator/+bug/1426294 ?
[15:30] <doko> Laney, no, hoped for pitti ... in the worst case, we'll have to revert the upstream python fix
[15:30] <doko> but it's in the 3.4.3 release too
[15:31] <pitti> Laney: oh -- git-buildpackage screams the same thing at me now when it tries to notify me
[15:31] <pitti> python? that rather looked like "new glib" or so? but I haven't investigated it at all yet
[15:32] <pitti> doko: http://d-jenkins.ubuntu-ci:8080/view/Vivid/view/AutoPkgTest/job/vivid-adt-zope.session/9/ green!
[15:32] <pitti> thanks
[15:32] <pitti> that shold clear setuptools
[15:33] <pitti> Laney, doko: btw, "gio" isn't introspection, it's the old static bindings
[15:33] <Laney> indeed
[15:34] <doko> hmm
[15:49] <lamont> why is it that my dist-upgrade today has cause ctl-alt-T to stop launching a terminal?
[15:49] <lamont> (yes, vivid)
[15:50] <Laney> what terminal emulator?
[15:52] <lamont> terminator, actually
[15:53] <Laney> see immediately above
[15:53] <lamont> interestingly, right-click, "open terminal" works just fine
[15:53] <pitti> hm, still works here
[15:53] <Laney> did you get new python?
[15:53] <pitti> but I dist-upgraded this morning (11 hours ago)
[15:54] <pitti> Laney: python2.7? or literally the metapackage?
[15:54] <pitti> Laney: I do have teh broken gio bits, if that's the same
[15:54] <Laney> I think 2.7, just trying to downgrade now to check
[15:54] <lamont> 2.7.9-1ubuntu1
[15:54] <pitti> also works in a guest session
[15:55] <pitti> lamont: got that
[15:55] <Laney> changelog mentions this identified upstream bug
[15:55] <lamont> I want to say that it's gtk2 vs 3 or some such ancient crack
[15:55] <attente_> hi, has anyone tried using Qt5LinguistTools in a cmake file? i'm encountering https://bugs.launchpad.net/ubuntu/+source/qttools-opensource-src/+bug/1292986, but it says that the fix was released
[15:55] <lamont> (handwavy half-recollection of a previous discussion about terminator not having migrated to some new rev of something, about a year ago)
[15:56] <lamont> and by "about" I mean give or take 6-12 months
[15:58] <Laney> http://paste.ubuntu.com/10450739/
[15:58] <Laney> (& happy terminator)
[16:04] <lamont> Laney: what all debs did you reinstall?
[16:05] <Laney> lamont: enough of these guys to please dpkg https://launchpad.net/ubuntu/+source/python2.7/2.7.9-1/+build/6635827
[16:05] <lamont> ok
[16:05] <Laney> libpython* python2.7 python-minimal
[16:06] <lamont> sadly, terminator became somewhat less useful to my workmodel when changing font size meant that it went bug-nutso if you created a new tile.
[16:06] <lamont> my remaining question is wtf happened to my window manager at the home machine
[16:06] <lamont> what passes for a top-bar is nothing but the nautilus menu
[16:07] <lamont> s/menu/topbar/
[16:07] <lamont> and none of the shortcuts seem to interest the computer anymore
[16:08] <lamont> current plan is to see if a reinstall makes it happier
[16:08] <lamont> (sving the old root, of course)
[16:16] <Odd_Bloke> How can I see what IP address apt-get is resolving archives to?
[16:22] <doko> Laney, pitti: should we revert this one bug fix for now? if yes, please do it. I'll have to leave soonish
[16:23] <Laney> doko: I have NFC about python modules so there's not much chance I can fix pygobject-2
[16:23] <doko> Laney, no, revert the fix that one issue in python2.7
[16:24] <Laney> Yeah, but I'm guessing that a real fix is preferable
[16:24] <Laney> Happy to revert in the meanwhile though
[16:24] <doko> sure
[16:26] <Laney> see if pitti has a bright idea, otherwise I'll do that before EODing
[16:55] <doko> Laney, leave me a message on irc, will be back very late tonight
[17:16] <flexiondotorg> Is there anyone here who would sponsor the update of a couple of package for Ubuntu MATE?
[17:16] <flexiondotorg> One is the meta package, the other is the settings.
[17:29] <flexiondotorg> infinity, Could you update a couple of packages for me?
[17:36] <aeoril> I am trying to figure out how to build apport from source (bzr branch lp:apport).  I saw "setup.py" and looked at it and it looked like a likely suspect.  I ran it, but got this error and am not sure where to go from here:  https://bugs.launchpad.net/ubuntu/+source/apport/+bug/348250 Google search unfortunately led me nowhere
[17:36] <aeoril> oh, I guess that is fixed now
[17:37] <aeoril> nm, i was confused by the ubottu message - it is not fixed yet
[17:37] <aeoril> pitti ^
[17:38] <aeoril> whoops, I meant to link to my gist:  https://gist.github.com/aeoril/4084dc205732a553044c not just the bug report
[17:39] <aeoril> (and that was the wrong bug report anyway)
[17:41] <flexiondotorg> Could someone please tell me what the correct merge target for indicator-sound is please?
[17:41] <flexiondotorg> Because I've just generate a massive MP from just a couple of lines change?
[17:41] <flexiondotorg> https://code.launchpad.net/~ubuntu-mate-dev/indicator-sound/mate/+merge/251295
[17:42] <cjwatson> the correct merge target is typically whatever you branched from in the first place.
[17:42] <aeoril> flexiondotorg uggghh - that happened to me!
[17:42] <flexiondotorg> cjwatson, I branched from lp:indicator-sound and tried to merge back to it.
[17:42] <cjwatson> No, you didn't
[17:42] <cjwatson> You branched from lp:ubuntu/indicator-sound
[17:43] <flexiondotorg> Ooops.
[17:43] <cjwatson> But I'm pretty sure that's not used; I suggest rebranching from lp:indicator-sound and reapplying your change
[17:43] <flexiondotorg> I'm an idiot.
[17:43] <flexiondotorg> cjwatson, Thanks.
[17:43] <flexiondotorg> I need a drink.
[17:43] <aeoril> flexiondotorg you are not an idiot :)
[17:43] <cjwatson> lp:indicator-sound is AFAIK the usual merge target
[17:46] <Laney> doko: uploading it
[17:50] <alexbligh1> packaging question: I have a package X, that depended on a package foo-open-isci, which was an alternate build of open-iscsi. I now want to bring in stock open-iscsi instead. So I have made X' (new version of X) depend on a transitional package T, T depends on open-iscsi, and Conflicts, Provides, Replaces, Breaks foo-open-iscsi. However, as the two open-iscsi packages contain the same files, dpkg complains it c
[17:50] <alexbligh1> an't overwrite files in foo-open-iscsi with a file from open-iscsi of the same name. I thought Breaks: was meant to ensure foo-open-iscsi was removed first, but perhaps that only ensures it is removed before T is installed, not T's dependencies. Any ideas?
[18:01] <aeoril> oh, its python - I don't compile it, I guess
[18:12] <Noskcaj> xnox, Is there anything in particular i should be doing to get a +1 from you for MOTU?
[18:20] <aeoril> pitti you around?  I have been dinking all around the apport source from lp:apport and just cannot figure out how to test the gui.  I am trying to fix:  https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1422176 and beleive I already know how to fix it (seems simple) but have no idea how to test my changes.  Would you be willing to help me with this fix?
[18:25] <aeoril> pitti oh, I think I see how to test - change them live in the installed directory, then test them, then update the source branch ... does that sound reasonable?
[20:05] <smoser> slangasek, https://launchpadlibrarian.net/195014257/cloud-init_0.7.7%7Esnappy%7Ebzr1045-0ubuntu2_0.7.7%7Esnappy%7Ebzr1045-0ubuntu3.diff.gz
[20:05] <smoser> is that appropriate for cloud-init upstream ?
[20:07] <smoser> you had previously submitted systemd-user-sessions.service
[20:08] <smoser> ah. nevermind. i see that you fixed with systemd-user-sessions.service