[00:00] <infinity> mwhudson: Oh, the sparc bit is an Ubuntu delta?  We can probably just drop that, then.
[00:00] <mwhudson> oh yes
[00:01] <mwhudson> you mean, stop building the package for sparc?
[00:01] <infinity> mwhudson: Yeah.
[00:01]  * mwhudson gets his rebase on
[00:03] <infinity> mwhudson: Oh, and probably add x32 to the x86 cases, in case Debian wants to pick it up.
[00:03] <infinity> mwhudson: Then rebase the whole thing down to one readable patch. :)
[00:03] <infinity> mwhudson: But looks good.
[00:08] <mwhudson> infinity: new commits on https://github.com/mwhudson/qemu/commits/qemu-kvm-arches
[00:09]  * infinity clones.
[00:10] <mwhudson> ok, deleted my first patches from the bug, attached a diff of the whole thing and linked to gh
[00:11] <mwhudson> i suppose i should do a testbuild
[00:12] <mwhudson> i should also have lunch
[00:15] <sarnold> Laney,xnox, http://ubuntu-codesearch.surgut.co.uk/ is returning "502 bad gateway", is this expected?
[00:15] <infinity> mwhudson: I like it.
[00:28] <mwhudson> infinity: thanks
[00:30] <infinity> mwhudson: If you carry on accidentally displaying competence with packaging, I might railroad you into applying for MOTU or core-dev.
[00:31] <infinity> mwhudson: Though, you'll have to explain to me some day how 4 is the integer after 1.
[00:31] <infinity> mwhudson: (Looking at your upload history, and the changelog in gccgo-go :P)
[00:32] <sarnold> well it's certainly not -before- 1 :)
[00:33] <infinity> sarnold: Fait point.  It's one of the many integers after 1, just not the one I'd expect. ;)
[00:33] <infinity> s/Fait/Fair/
[00:33] <sarnold> infinity: hehe :)
[00:41] <mwhudson> in my defense, i didn't actually propose that for ubuntu i think
[00:41] <mwhudson> i imagine 2 and 3 were broken versions in my ppa
[01:24] <mwhudson> infinity: E: qemu-kvm: subdir-in-usr-bin usr/bin/kvm/
[01:24]  * mwhudson fails
[01:25] <mwhudson> LIMITATIONS
[01:25] <mwhudson>        dh_install cannot rename files or directories, it can only install them with the names they already have into wherever you want in
[01:25] <mwhudson>        the package build tree.
[01:25] <mwhudson> well stink
[01:32]  * mwhudson vanishes for a bit
[01:32] <infinity> mwhudson: Oh, yeah, you probably just want good ol' install.
[01:37] <infinity> mwhudson: As in 'install -m755 debian/kvm.x86 debian/qemu-kvm/usr/bin/kvm'
[05:10] <Mirv> infinity: retry, https://ci-train.ubuntu.com/job/ubuntu-landing-014-2-publish/lastSuccessfulBuild/artifact/packaging_changes_compiz_1%3A0.9.12.0+15.04.20141105-0ubuntu1.diff
[05:15] <infinity> Mirv: +1
[05:15] <Mirv> thanks!
[05:27] <mwhudson> infinity: don't i need something to indicate that it should be part of the qemu-kvm package?
[05:28] <mwhudson> i guess a .install file suffices for that
[05:28] <mwhudson> (seeing as the installed file is the same on all platforms, that's the point :)
[05:31]  * mwhudson reads what infinity wrote again
[05:33] <infinity> mwhudson: No.
[05:33] <infinity> mwhudson: But I'm guessing you got there from your last comment.
[05:33] <mwhudson> yeah
[05:34] <mwhudson> didn't sleep well last night, please excuse lack of brain
[05:34] <infinity> mwhudson: The alternative would, indeed, be to install that to debian/tmp/usr/bin and then have an .install file that copies it, but that seems pointless.
[05:34] <mwhudson> yes
[07:24] <pitti> Good morning
[07:26] <pitti> jibel: gcc has that eternal "test in progress" problem again for r-cran-surveillance and cuneiform
[07:27] <pitti> doko_: ^ I already tried to work around it, but I don't have access to tachash; gosh, I'm so glad when this stuff gets replaced
[07:27] <pitti> doko_: but right, that's a nuisance :(
[08:24] <LocutusOfBorg1> can anybody please retry https://launchpad.net/ubuntu/+source/insighttoolkit4/4.6.0-3build1/+build/6541532 ?
[08:25] <LocutusOfBorg1> I don't know if rebuilding fixes, usually it does for itk4 :(
[08:25] <LocutusOfBorg1> in the meanwhile I talk with the maintainer :)
[08:26] <jibel> pitti, I cannot find any result for cuneiform, I'm looking into it. I regenerated a result and it will be fixed on next run of britney.
[08:28] <pitti> jibel: cheers! for r-cran-surveillance too?
[08:28] <jibel> pitti, yes both
[08:28] <pitti> jibel: merci
[08:29] <cjwatson> LocutusOfBorg1: retried
[08:29] <LocutusOfBorg1> thanks :)
[09:54] <pitti> infinity: as TIL you called dibs on the kmod merge (which curiously is missing from MoM); I just saw bug 1372035 which would be solved by that
[09:54] <pitti> infinity: do you plan to do the merge, or release it to the "general core-dev public"? (NB I can't do it right now, but probably within the next week or so)
[10:10] <jibel> pitti, wrt. cuneiform, the problem was that multiverse was not enabled on jenkins' side and results were just ignored because the package was not found.
[10:10] <pitti> jibel: ouch, you mean in our testbed VMs?
[10:12] <jibel> pitti, no the part that takes the results from the testbed and push them into the queue for britney
[10:13] <pitti> ah
[10:13] <pitti> jibel: wow, so we now know that we have exactly one multiverse package with a test :)
[10:13] <caribou> infinity: had any chance to look at the libnss-ldap merge ?
[10:17] <jibel> pitti, exactly 4 packages
[10:26] <didrocks> bdmurray: hey, it seems you didn't push whoopsie 0.2.41 to trunk, mind if I'm doing so?
[10:28] <pitti> didrocks: just do it
[10:29] <didrocks> pitti: ok, preparing that. I'm fighting with a FTBFS as well with the current version first (seems some automake targets are not triggered)
[10:31] <didrocks> pitti: mind pushing lp:~didrocks/whoopsie/0.2.41 to lp:whoopsie? (I don't have commit rights here)
[10:32]  * didrocks on the FTBFS now
[10:32] <Laney> builds for me in sbuild, fwiw
[10:32] <pitti> yeah, was working well for me too
[10:32] <didrocks> ok, my local system is having hard time then… weird as it's make -j1
[10:33] <didrocks> so not etoomanyprocesses…
[10:33] <pitti> didrocks: done
[10:33] <didrocks> thanks
[10:33] <pitti> didrocks: no automake -- this is a simple Makefile
[10:34] <pitti> didrocks: make -j4 works just fine here (right out of clean trunk)
[10:34] <didrocks> pitti: do you have valgrind installed?
[10:35] <pitti> didrocks: not in my build schroot, but also not on my workstation
[10:35] <didrocks> that's why it passes :)
[10:35] <didrocks> if type valgrind >/dev/null 2>&1; then \
[10:35] <pitti> (I do all builds in schroot, I don't have any -dev installed on my system)
[10:35] <didrocks> APPORT_REPORT_DIR=/tmp/tmp.ScDOedTr3S ./tools/check_valgrind; \
[10:35] <didrocks> fi
[10:35] <didrocks> this is what fails
[10:35] <pitti> ah
[10:36]  * didrocks files a bug for now
[10:41] <infinity> pitti: I'll do the merge, but I thought we already fixed that bug in Ubuntu.
[10:42] <infinity> pitti: Will look tomorrow, though.
[10:42] <pitti> infinity: ah, cheers
[10:42] <infinity> pitti: Oh, maybe someone broke it when they stole my last merge. :P
[10:43] <infinity> pitti: Anyhow, will check when I'm awake.  Going to ingest a gallon of cough syrup and try to sleep.
[10:43] <pitti> infinity: ouch, get better soon!
[10:52] <StevenK> infinity: A gallon? Damn.
[11:30] <pitti> stgraber: I think I already asked like three times, but I still don't know how: can I tell my ephemeral containers to mount the /delta thing on a tmpfs? at the moment it's hitting the disk, which is not only very slow, but also still tends to kill my SSD (probably a hardware or btrfs bug)
[11:31] <pitti> I see why this isn't being done by default for possibly RAM limited systems, but I've got plenty of RAM
[11:40] <sil2100> @pilot in
[12:05] <Laney> LocutusOfBorg1: it failed again, could you look?
[12:11] <sil2100> @pilot out
[12:46] <cjwatson> Logan_: Could you merge salome-kernel, please?  Needed for new hdf5
[12:48] <LocutusOfBorg1> Laney, I already asked to Gert, the debian maintainer, let me see
[12:48] <LocutusOfBorg1> I suspect this is due to the newly uploaded gcc 4.9.2
[12:49] <cjwatson> Logan_: And meep too please, same reason
[12:50] <LocutusOfBorg1> I'm going to reproduce with pbuilder/vivid and pbuilder/sid, will take a while
[12:54] <Mirv> any core-dev to ack removal of "libthumbnailer-dev" build dependency from UI Toolkit landing? https://ci-train.ubuntu.com/job/ubuntu-landing-010-2-publish/lastSuccessfulBuild/artifact/packaging_changes_ubuntu-ui-toolkit_1.1.1311+15.04.20141102-0ubuntu1.diff
[12:54] <cjwatson> doko: Could you merge libgpiv, please?  Needed for new hdf5
[13:06] <stgraber> pitti: if you're using lxc-start-ephemeral, then pass --storage-type tmpfs
[13:12] <LocutusOfBorg1> cjwatson, libgpiv built on debian/ppc64el, so what about sync it? :)
[13:23] <mzanetti> tvoss: hey, have a situation here on my phone where you might be able to help:
[13:24] <mzanetti> there's location-service taking 1GB of memory, causing oomkiller to kill the dash every time its respawned
[13:24] <mzanetti> and location-service's oom score is 452, while the dash is 50
[13:24] <mzanetti> so 2 issues I guess
[13:27] <mzanetti> tvoss: want me to fetch some logs for you?
[13:30] <pitti> stgraber: ooh! thanks!
[13:32] <tvoss> mzanetti, please file a bug against, https://bugs.launchpad.net/ubuntu/+source/location-service
[13:32] <tvoss> mzanetti, and please list device and image number
[13:33] <addiks> hi, when clicking on a background/non-focussed window, which program is responsible for bringing that window to the front, giving it focus and giving the click-event to the program belonging to that window?
[13:33] <mzanetti> ok. some interesting things (logs) to collect and attach? so far I'd go with dmes, location-service's oom score info and some memory stats
[13:33] <mzanetti> tvoss: ^
[13:33] <tvoss> mzanetti, yup
[13:34] <mzanetti> tvoss: btw, it keeps on leaking memory
[13:37] <tvoss> mzanetti, not much we can do about it right now
[13:37] <mzanetti> ok
[14:00] <cjwatson> LocutusOfBorg1: I'm not going to but doko is welcome to
[14:00] <cjwatson> LocutusOfBorg1: if he thinks it appropriate
[14:06] <LocutusOfBorg1> I was just giving my .02$ :)
[14:07] <cjwatson> that's fine, just don't give it to me in this case :)
[14:34] <pitti> stgraber: wth -- that reproducibly crashes my machine immediately (need to sysrq+b)
[14:47] <stgraber> pitti: hmm, that's, unexpected... are you getting a panic or oops or something similar?
[14:47] <pitti> stgraber: the screen goes off/black, so I don't really see anything
[14:47] <pitti> I can only sysrq+s+u+b
[14:48] <stgraber> and nothing interesting in kernel.log post-reboot I assume?
[14:50] <pitti> stgraber: was OTP, done now; let me check
[14:50] <pitti> stgraber: nothing relevant at all :/
[14:51] <pitti> stgraber: I guess I'll try that again without splash/quiet and on a VT
[14:51] <pitti> stgraber: anyway, when I have more data I'll file a bug (too much other things that keep me busy today)
[14:53] <stgraber> pitti: you may also want to install linux-crashdump and then turn it on in /etc/default if you don't already have it
[16:30] <RobertDupont> hello guys
[16:30] <RobertDupont> I got a packaging question if you guys don't mind
[16:31] <RobertDupont> I didn't get any useful answer from #ubuntu-packaging
[16:31] <RobertDupont> anyway, I'm trying to build a package
[16:31] <RobertDupont> I can build it manually just fine and I thing I pretty much got the thing set-up correctly
[16:31] <RobertDupont> well, almost
[16:32] <RobertDupont> I'm trying to package barnyard2
[16:32] <RobertDupont> and there is autoreconf first then it runs configure
[16:33] <RobertDupont> during the packaging phase, where it runs the configure, it test for the presence of a bunch of headers
[16:33] <RobertDupont> nothing unusual
[16:33] <RobertDupont> it works fine when building in the command line, manually
[16:34] <RobertDupont> however, within one of those dh_* commands, it adds some stuff when compiling those tests
[16:34] <RobertDupont> which makes compilation (and thus the test) fail
[16:34] <RobertDupont> I can see a bunch of different "gcc -c -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat =format-security -D_FORTIFY_SOURCE=2 conftest.c >&5" on the screen
[16:35] <RobertDupont> basically, you can see the issue is that it adds '=format-security' but there is an extra space
[16:35] <RobertDupont> I have absolutely no idea where this gets added (and it works just fine when doing manually)
[16:35] <cjwatson> Do you have a copy of the package and a full build log somewhere?
[16:36] <RobertDupont> and google didn't return me any useful answer
[16:36] <rbasak> Looking up dpkg-buildflags and https://wiki.debian.org/Hardening might help you there. That's where the hardening flags come from.
[16:36] <cjwatson> The actual string in libdpkg-perl used there is -Werror=format-security
[16:37] <cjwatson> I suspect some foolish bit of the package's build system is attempting to remove -Werror and botching the job
[16:37] <RobertDupont> cjwatson: is that logged somewhere or do I need to copy the content of the screen?
[16:37] <cjwatson> Depends how you built it
[16:37] <cjwatson> debuild leaves a .build file around, sbuild usually does too
[16:37] <cjwatson> But a copy of the packaging would probablyd o
[16:37] <cjwatson> *probably do
[16:38] <RobertDupont> found it
[16:39] <RobertDupont> I'll paste it somewhere
[16:39] <RobertDupont> it's in build-area
[16:39] <cjwatson> Honestly having looked into this I'm not actually that interested in the build log
[16:39] <cjwatson> Put a copy of the source package somewhere first :)
[16:40] <RobertDupont> the orig.tar.gz?
[16:41] <RobertDupont> or the directory containing the debian/ directory?
[16:41] <cjwatson> .dsc, .orig.tar.gz, and whichever of .debian.tar.* or .diff.gz exists
[16:44] <RobertDupont> http://demo.ovh.eu/en/c9c928994686b4ddce3d91f4ac466a58/
[16:46] <cjwatson> Bit more than what I asked for, but OK
[16:46] <RobertDupont> sorry about that
[16:47] <cjwatson> RobertDupont: look for the first mention of "Werror" in configure.ac, there's the problem
[16:47] <cjwatson> that sed needs to be smarter to avoid removing half an option
[16:48] <RobertDupont> so I guess, there was -Werror=format-security
[16:48] <RobertDupont> -Werror got removed
[16:48] <cjwatson> Simplest fix would be:   sed -e 's/-Werror\(^=\|$\)//g'
[16:49] <cjwatson> That's right
[16:49] <cjwatson> Though actually even the above isn't quite right, you need a matching change to the grep above it as well
[16:49] <cjwatson> Can you figure it out from here?
[16:50] <cjwatson> BTW your debian/rules is wrong in some other ways
[16:50] <cjwatson> DEB_CONFIGURE_EXTRA_FLAGS is a cdbs thing, and DEB_DH_AUTORECONF_ARG is a misspelled cdbs thing
[16:50] <cjwatson> Neither will do anything because you're using dh, not cdbs
[16:51] <RobertDupont> wow, I didn't know
[16:51] <cjwatson> You should be using override rules for dh_auto_configure and dh_autoreconf instead; see "man dh" and "man dh_autoreconf"
[16:51] <cjwatson> Also, the #! line should be the first line of debian/rules, not the second; you need to remove the blank line above that
[16:52] <RobertDupont> thanks a lot
[16:52] <cjwatson> Hopefully that gets you going a bit further
[16:52] <cjwatson> no problem
[16:52] <RobertDupont> oh yeah, it's helping me a lot
[16:52] <RobertDupont> awesome ;)
[17:01] <pitti> sil2100: ♥ @ https://wiki.ubuntu.com/LandingTeam
[17:01] <sil2100> pitti: glad you like it! Remember to poke us whenever you think somethin is missing :)
[17:12] <ogra_> sil2100, i have somethin missing ... the MilestoneProcess subpage :P ... once olli finally answered in the mail thread :)
[17:15] <olli> ogra_, yeah, I might be owing you a response
[17:15] <ogra_> :)
[17:20] <jdstrand> Riddell: question for you in 1389665
[17:31] <sil2100> ogra_: hah, it'll land there eventually!
[17:33] <ogra_> :)
[19:18] <pitti> slangasek: hey Steve!
[19:18] <pitti> slangasek: so currently under systemd we don't handle the system clock being in local time (bug 1377258)
[19:19] <pitti> slangasek: I put two options there; the other day you seemed quite firmly against using /etc/adjtime for this, so I'd like to ask your opinion about that
[19:19] <pitti> slangasek: as Debian uses /etc/adjtime for the LOCAL vs. UTC, we keep having a delta in at least two, maybe three packages (and perhaps some which we just didn't spot/change yet)
[19:21] <pitti> slangasek: personally I'd be in favor of dropping that delta and going with instead of against Debian here; in the end it doesn't matter that much where the setting lives, and in an upstart or systemd world "rcS" isn't quite the most intuitive name either any more :)
[19:21] <pitti> slangasek: but we can fix it either way
[19:22] <slangasek> pitti: it does matter, /etc/adjtime is a wrong interface and using it means using it for more than just the TZ setting
[19:22] <pitti> slangasek: yeah, it's not paying attention to the drift bit, just the utc vs. local option
[19:22] <slangasek> hmm
[19:22] <slangasek> ok
[19:22] <pitti> slangasek: you mean the definition (whereever that lives) of adjtime doesn't include those options?
[19:22] <slangasek> so in that case it's not buggy, but using this binary file for just the TZ is dumb and we should fix that in Debian
[19:23] <pitti> binary?
[19:23] <slangasek> isn't it?
[19:23] <slangasek> maybe I'm misremembering :)
[19:24] <pitti> slangasek: the manpages don't seem to document this, I'll google a bit for some POSIXy or similar spec
[19:24] <pitti> I thought it was just a simple text file with two nubmers for the drift
[19:25] <slangasek> hmm maybe so
[19:26] <pitti> we can probably argue at length whether one or the other is more elegant etc, but it seems for both admins (more consistent documentatino between distros) and for us (less delta and less potential breakage due to the diff) it's easier to follow Debian
[19:26] <pitti> "The correction factor for the RTC is stored in /etc/adjtime" -- thanks for being so precise
[19:27] <slangasek> pitti: so as long as we are using /etc/adjtime *only* for TZ, then that's fine; my concern is that if we're using adjtime, things will sneak in that assume it should be used for drift
[19:28] <pitti>         *   # /etc/adjtime
[19:28] <pitti>          *   0.0 0 0
[19:28] <pitti>          *   0
[19:28] <pitti>          *   UTC
[19:28] <pitti> I found that as the general format
[19:28] <pitti> TBH I have no idea what those numbers mean, aside from the drift
[19:29] <pitti> at least hwclock.sh and systemd only look for "UTC" vs. "LOCAL" in the third line, i. e. the equivalent of UTC=yes or no
[19:30] <pitti> slangasek: ooh! http://www.thegeekstuff.com/2013/08/hwclock-examples/#more-14337
[19:30] <pitti> not quite a reference, but an explanation at least
[19:31] <pitti> slangasek: ok, got it: "sudo hwclock --adjust" writes that file, and it has exactly that format
[19:34] <pitti> slangasek: so in summary, doing the migration sounds pretty much right to me..; WDYT?
[19:35] <pitti> (bbl)
[19:36] <bdmurray> Laney: I don't see a utopic upload of webkitgtk for -proposed
[19:41] <slangasek> pitti: again, my concern is that reinstating /etc/adjtime is going to cause people to start misusing hwclock --adjust
[19:42] <slangasek> which per Scott's analysis during the upstart implementation, we should not be doing ever
[20:06] <pitti> slangasek: oh, ok; I didn't actually identify that as the reason of your concern before
[20:08] <pitti> https://wiki.ubuntu.com/FoundationsTeam/Meetings/2009/0311 references it, but not much explanation
[20:14] <pitti> slangasek: so, if you happen to have more information about that (why it's a misuse, and what currently keeps people from using --adjust), I'd be very interested
[20:14] <pitti> but given that it's not very clear, I guess I'll patch systemd to read it from rcS for now
[20:17] <slangasek> pitti: well, it's a misuse in the context of system boot because it adds sleeps to an op that should be instantaneous :)
[20:17] <slangasek> system boot / shutdown
[20:17] <slangasek> maybe we don't need to worry about this in practice
[20:35] <flexiondotorg> As some of you maybe aware I am working on Ubuntu MATE.
[20:35] <flexiondotorg> I understand that it is possible to have newer MATE packages uploaded to the 14.04 archive by way of an SRU.
[20:36] <flexiondotorg> And in fact, this is desirable since the MATE packages in the 14.04 archive are incomplete and broken, so updating them would be for the good.
[20:37] <flexiondotorg> However, is it possible to retrospectively modify the build tools so that an official Ubuntu MATE 14.04.x could be made?
[20:38] <flexiondotorg> cjwatson, Your thoughts on the above?
[21:18] <RobertDupont> cjwatson: I got a few more questions if you don't mind
[21:19] <RobertDupont> I managed to fix that rule file and a bunch of other things but for some reason, I only see the documentation in the package
[21:19] <RobertDupont> it seems to do the autoreconf
[21:20] <RobertDupont> but not the configure and not compiling (and the patch I put in debian/patches (and in series in that directory) don't seem to be applied
[21:20] <RobertDupont> and it doesn't look like it takes care about the init.d file
[22:00] <blueyed> I am trying to debug why XBell() is silent for my user (via urxvt; https://github.com/exg/rxvt-unicode/blob/master/src/screen.C#L1971). xkbbell and other terminal emulators work, but they do not use XBell.
[22:36] <blueyed> It seems like pulseaudio-module-x11 "just" does not handle XBell calls.
[22:46] <blueyed> Investigation at: http://askubuntu.com/questions/546569/pulseaudio-does-not-ring-bell-through-xbell-function-urxvt
[23:05] <RobertDupont> cjwatson: I made some more progress but now I'm facing the issue where it removed or forgot to add -Werror=unused-but-set-variable
[23:05] <RobertDupont> that should be a 'fairly' easy fix