[00:05] <TheMuso`> c
[04:08] <pitti> good morning
[04:09] <pitti> xnox: yes, unless it affects insserv ordering (which after yesterday's discussion won't land soon anyway) there's no need to create init.d scripts which will never be used anyway
[04:09] <pitti> xnox: we are only concerned about upstart and systemd, I don't think we want to start supporting sysvinit too :)
[04:10] <pitti> xnox: saw the bug, thanks
[05:20] <Mirv> slangasek: upstream won't develop/release libsdl 1.2 anymore but the bug report is there. I submitted the patch to Debian bug tracker yesterday now too.
[06:42] <dholbach> good morning
[06:44] <ion> that
[08:00] <cousteau> can windows / applications draw stuff over Unity's top bar?  or is it always over the applications unless they're fullscreened?
[08:02] <cousteau> because if they can, and it's also possible to get the length and position of the global menu on the screen, then applications could have their own "custom global menu" by drawing over it
[08:02] <ion> cringe
[08:08] <cousteau> (or one could just put that sort of stuff inside the window rather than the menu bar, but this might be a bit inconsistent with how Ubuntu looks and feels)
[08:10] <xnox> pitti: so with plymouth from proposed. On boot, i get plymouth splash, then ~8 lines of systemd-fsck and then it gets stuck there. Upon switching to tty1 it realises things and instantly starts up lightdm. I'm not yet sure what's going on there. Will test out how the transitions happen in e.g. virtual machine / debian.
[08:11] <pitti> xnox: thanks; sorry, I'm still stuck in putting out autopkgtest fires and now reviewing the britney fixes
[08:12] <xnox> pitti: no worries. there will also be malta to listen to my lenovo PC-speaker on systemctl reboot =))))
[08:12] <pitti> hehe
[08:14] <pitti> xnox: do you hear any beep on printf "\a"
[08:14] <pitti> xnox: or when installing and running "beep"? I don't
[08:15] <pitti> PC speaker, oh the days
[08:16] <xnox> nope, nothing.
[08:16]  * xnox ponders if that's not, in fact, pc speaker then.
[08:17] <xnox> maybe it's like a beep cod ?!
[08:17] <pitti> xnox: I think that used to work, but I faintly remember that we dropped the PC speaker from the kernel some years ago; ICBW though
[08:17] <xnox> code
[08:17] <xnox> pitti: yeah, it's blacklisted in /etc/modprobe.d/ throughout. I pondered if systemd doesn't read that.
[08:17] <pitti> xnox: so another hypothesis is that systemctl reboot pokes the bios/uefi in a different way than normal "reboot" (e. g. from upstart); could that be?
[08:18]  * xnox will read systemctl reboot code
[08:19] <pitti> I modprobed pcspkr, but neither \a nor beep do anything :/
[08:19] <xnox> system-module-load unit fails for me =(
[08:19] <pitti> xnox: yep, known; it's because of the obsolete "rtc" in /etc/modules
[08:19] <pitti> it's on my TODO to file bug for this (discussed quickly on IRC last week)
[08:19] <pitti> "bug against hw-detect for dropping rtc module, and kmod for removing it on upgrades"
[08:20] <pitti> xnox: it's quite clear from systemctl status system-module-load, you see the failed rtc there
[08:20] <xnox> pitti: do you want me to fix hw-detect ? & kmod?
[08:21] <pitti> xnox: if you want to and have time, sure :) (it's mostly cosmetical at this point)
[08:21] <pitti> xnox: I haven't yet checked when we dropped rtc, i. e. how careful we need to be on upgrades
[08:22] <xnox> "register-module rtc on amd64 (closes: Ubuntu #1659)"
[08:22] <pitti> "dropped rtc" as in "the module from the kernel"
[08:22] <xnox> pitti: is that bugzilla reference number?! =)
[08:22] <pitti> xnox: wow, four-digit bugs, that sounds like bugzilla
[08:23] <xnox> pitti: it's a delta from debian =) looks like debian never did that.
[08:23] <xnox> pitti: what about "lp" module?
[08:23] <pitti> xnox: too bad, it's not even on https://bugs.launchpad.net/bugs/bugtrackers/ any more
[08:24] <pitti> xnox: if it helps to drop it, do it; /etc/init/cups.conf already loads it
[08:24] <pitti> xnox: oh, actually it doesn't; our /etc/default/cups has LOAD_LP_MODULE=yes commented out
[08:25] <pitti> xnox: nevermind, it's now in /etc/modules-load.d/cups-filters.conf
[08:25] <pitti> xnox: so yes, can go
[08:27] <xnox> pitti: yeah, that should make /etc/modules empty.
[09:47] <shadeslayer> pitti: so kde4libs is missing from https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/
[09:48] <shadeslayer> pitti: uploaded it 17 hours ago
[09:48] <shadeslayer> https://launchpad.net/ubuntu/+source/kde4libs/4:4.13.0-0ubuntu2
[09:48] <pitti> shadeslayer: yes, it's missing the "XS-Testsuite: autopkgtest" header in debian/control
[09:49] <shadeslayer> ahhhh
[09:49] <pitti> that's how the CI machinery checks whether a package has tests
[09:49]  * shadeslayer checks
[09:49] <pitti> shadeslayer: but no hurry -- as far as I remember from yesterday that test wasn't that useful anyway as it just ran tests against the build tree
[09:50] <shadeslayer> yeah
[09:50] <shadeslayer> but might as well fix it since it should be trivial
[10:23] <geser> doko_: Hi, are you working on merging python-babel? I'd like to try to fix bug #1299442 (it looks like this was already fixed in Debian) which also includes to fix it in utopic first (probably by merging with Debian)
[10:26] <doko_> geser, no
[10:26] <geser> so it's ok if I do it?
[10:47] <doko> sure
[12:16] <shadeslayer> infinity: ping, I was wondering, the eglibc homepage says that it's unmaintained, are there any plans to switch back to glibc?
[12:30] <LocutusOfBorg1> shadeslayer, I wasn't aware, so sad
[12:30] <LocutusOfBorg1> but is good to have only one big glibc project
[12:30] <LocutusOfBorg1> rather than two
[12:30] <LocutusOfBorg1> :)
[12:36] <pitti> @pilot in
[13:09] <pitti> xnox: so someone went ahead of us and filed bug 1317077 :)
[13:09] <pitti> xnox: so in case you are already working on it, please add the bug ref to the changelogs?
[13:09] <xnox> pitti: ack, thanks.
[13:34] <xnox> infinity: for above bug ^ are you happy with attached patch there https://launchpadlibrarian.net/174864006/kmod.patch ?
[13:35] <pitti> xnox: LGTM (I think lt is fine, lt-nl might not suffice in weird corner cases)
[13:35] <pitti> xnox: thanks!
[13:35] <xnox> pitti: i'm now pondering if $2 is actually passed....
[13:36] <pitti> xnox: if I may be a bit nitpicky, I'd move the LP to the next line to satisfy changelog parsers
[13:36] <pitti> (dpkg-genchanges groks it, but e. g. not vim or LP)
[13:36] <xnox> pitti: all changelog parsers parse it correct!
[13:37] <pitti> xnox: yes, but my eye doesn't :) (but nevermind, just nitpicky)
[13:37] <xnox> pitti: of vim =) emacs doesn't correct.
[13:37] <xnox> pitti: fair point =)
[13:37] <pitti> xnox: $2 seems fine to me
[13:37]  * xnox ponders if emacs can be fixed to auto-wrap with non-breaking space.
[13:38]  * ogra_ thinks $2 is to cheap 
[13:38] <ogra_> :P
[13:38] <cjwatson> LP should grok it fine, I think it's just vim
[13:40] <xnox> pitti: nah $2 is bogus, cause it's not passed to the function, thus is empty, thus on every upgrade those modules are removed.
[13:40] <infinity> shadeslayer: I'm reviewing the delta and working on moving Debian and Ubuntu over to glibc, yes.
[13:41] <shadeslayer> \o/
[13:41] <shadeslayer> apachelogger: ^^
[13:42] <pitti> xnox: oh argh, right
[13:42] <infinity> xnox: FWIW, sounds like systemd is buggy here.
[13:43] <xnox> infinity: whilst true, it is also buggy to include modules that don't exist anymore. I've cleanup installer and cleaning up installed systems via kmod.
[13:43] <pitti> well, we could quiesce the load-modules job, but it really failed to load "rtc"
[13:43] <pitti> I think it's preferable to point that out than silently ignoring typos and other nonexisting modules
[13:44] <infinity> xnox: rtc exists.
[13:44] <pitti> and other than "status" yelling at you it doesn't break anything
[13:44] <pitti> $ modinfo rtc
[13:44] <pitti> modinfo: ERROR: Module rtc not found.
[13:44] <infinity> xnox: It doesn't "exist" in our distro kernel, but it's right to try to load it when it *is* modular.
[13:44] <pitti> infinity: and I think apw said it was removed many eons ago
[13:45] <infinity> pitti: That bug also shows some failures to parse modutils config files in general, etc.
[13:47] <pitti> asked the reporter to attach his /etc/modules (I don't get these "off" errors)
[13:47] <xnox> corrected the patch to remove those modules only once upon upgrade to 2ubuntu4 https://launchpadlibrarian.net/174864473/kmod.patch
[13:48] <xnox> infinity: hw-detect was only adding rtc module loading on amd64 & i386, and we do have kernels for those.
[13:48] <xnox> infinity: thus if indeed rtc should be loaded always & everywhere it should be done else, e.g. be a built-in module or get udev to load it.
[13:49] <pitti> xnox: only on amd64
[13:49] <xnox> right, yeah, even that.
[13:49] <pitti> because on i386 it gets loaded through isapnp
[13:49] <pitti> (haha!)
[13:49] <infinity> xnox: udev couldn't do it because it can't be detected.
[13:49] <infinity> xnox: Same reason why lp has to be a manual load.
[13:50] <xnox> infinity: lp is still a manual load. just via /etc/modules-load.d/cups-filters.conf
[13:50] <infinity> Which assumes that the only people who want to use that device are people with cups installed.
[13:50] <infinity> There's nothing wrong with trying to load it twice.
[13:50] <xnox> infinity: correct.
[13:51] <infinity> Look, I'm not against the installer dropping some of these options, I'm arguing that we don't need to "fix" old modules files to work around systemd being silly.
[13:52] <pitti> as I said, we *can* change the job to ignore nonexisting modules
[13:52] <infinity> If I don't have cups installed but use /dev/lp, you've just screwed me silently with your postinst.
[13:52] <pitti> at the expense of not telling you about errors
[13:52] <infinity> If I have a custom kernel with rtc built as a module, you just broke my computer.
[13:53] <pitti> and I'd rather have it tell me when I did a typo and why I just broke things, than silently claiming that everything went well
[13:53] <infinity> pitti: Well, modutils/modul-init-tools/kmod have never broken in this regard, I'm not fond of systemd telling me that I've been wrong for 20 years.
[13:53] <pitti> but oh well, not a biggie; either way is fine
[13:53] <pitti> infinity: please don't call it "broken" -- it's just as "broken" to not tell you about errors
[13:53] <pitti> it's a matter of deciding how to report errros
[13:53] <pitti> and if we don't want that, let's say so and we can do that
[13:54] <infinity> pitti: It's "broken" in that it's a regression.  You've always been able to have non-modules in those files before, specifically to allow one file to work for multiple kernels with different configs.
[13:55] <infinity> pitti: The idea being that you're saying "if this module exists, load it, cause I need it, otherwise, we assume it's built in".
[13:55] <pitti> infinity: fair enough
[13:55] <infinity> There could be a kmod bug here too, if it's not able to detect the built in status of rtc
[13:55] <xnox> shouldn't systemd-modules-load be smart in this regard and check if a given module is built in?
[13:55] <infinity> (It seems to do so for fuse)
[13:56] <infinity> So, okay, the rtc thing might be a genuine bug.
[13:56] <infinity> Removing lp sounds like overkill.
[13:56] <pitti> xnox: that seems rather unreliable to do? for this specific case it could check /sys/class/rtc/, but that doesn't generalize
[13:57] <xnox> infinity: yeah lp removal was mostly a piggy-back on top of rtc.
[13:57] <pitti> yeah, that was just cleaning up duplicate loading
[13:58] <infinity> pitti: Yeah, but it's not a duplicate, per se.  If a user has lp in /etc/modules, we should assume they wanted that at boot.
[13:58] <infinity> pitti: cups is saying "I really want lp", but that doesn't mean someone without cups doesn't also want it.
[13:58] <infinity> (I agree that it's time to drop lp from the installer, though, so few people even use the driver)
[13:59] <pitti> infinity: my thinking was that for someone without cups it's much more likely that he wants to use the parport by itself rather than lp claiming it
[13:59] <pitti> infinity: but, as you say, this is such an edge case these days that I really don't bother much
[13:59] <pitti> it just appeared to be something which could be cleaned up along
[14:00] <pitti> xnox: but ok, I don't think it's worth discussing this for long, so maybe let's put back lp?
[14:00] <xnox> pitti: so do we not have rtc module at all, not even built-in?!
[14:00] <infinity> The kmod builtin detection certainly fails to find rtc...
[14:00] <pitti> xnox: well, there *is* no rtc module..
[14:01] <infinity> rtc_generic             2711  0
[14:01] <infinity> Methinks it's been renamed.
[14:01] <pitti> there are things which you can build as module
[14:01] <infinity> So removing that is probably not world-ending.
[14:01] <pitti> whcih we build in
[14:01] <pitti> those appear in /sys/modules/
[14:01] <pitti> but rtc stopped being a module long ago
[14:01] <pitti> hence dropping it
[14:01] <xnox> debian wiki mentions genrtc module as well
[14:01] <infinity> So, yeah, dropping rtc is fine.
[14:02] <xnox> but keep the lp one?
[14:02] <xnox> (not doing any harm what's-so-ever)
[14:02] <infinity> pitti: So, assuming the kmod builtin detection actually works, I'm perhaps okay with failing on "unknown", assuming it's not also failing on "builtin" returns.
[14:02] <infinity> pitti: As in, that fuse builtin thing isn't causing issues, right?
[14:02] <pitti> xnox: yeah, I guess so; you could argue either way, but let's not for the 3 people in the world who still use parallel ports with Ubuntu (and can be broken either way around) :)
[14:03] <infinity> People who needed to use their lp port for something else already removed it from /etc/modules.
[14:03] <infinity> People who still have it there either don't care or prefer it that way.
[14:03] <infinity> So, remove lp from hw-detect, but not from existing installs.
[14:03] <pitti> infinity: it shouldn't; if it does, that'd be a bug in kmod or the systemd-module loader thingy (not sure which, but we can debug that if it happens)
[14:03] <ghy> hi everyone, what is your opinion about https://lists.ubuntu.com/archives/technical-board/2014-March/001852.html ? I think it needs some serious planning, to speed it up. Some doker tehniques ?
[14:03] <pitti> infinity: WFM
[14:03] <pitti> so xnox's hw-detect upload is fine, and in kmod he'll just drop the lp bit
[14:04] <infinity> pitti: kmod doesn't return an error for builtin, so it would be if systemd flips out at the output.
[14:04] <pitti> infinity: right, that seems fixable; i. e. a "builtin module" is trivial to detect
[14:05] <xnox> pitti: infinity: systemd-modules-load is fine with fuse, no errors.
[14:05] <pitti> so, all is well then :)
[14:05] <infinity> Okay, so the user removing that was overkill debugging. :P
[14:05] <infinity> The "name=off" stuff is curious, I'd like to know what's up with that.
[14:05] <pitti> except for that "off" error in the bug, I'll wait for the reporter's /etc/modules to see what he changed there
[14:06] <infinity> Could be a systemd bug, could be a kmod-not-compatible-with-m-i-t bug, or could be a broken config on his part.
[14:06] <pitti> *nod*
[14:07] <infinity> We've put a lot of work into making libkmod compatible with modutils/module-init-tools, but it's certainly not 100%, so the bug could be there.
[14:07] <infinity> Or he could just have had a broken config. :P
[14:09] <infinity> chrisccoulson_: Weird firefox bug, on a new window, the first time I click on the (locally-integrated) menus, the tab bar drops a pixel or two.  After that click, it stays that way for the life of the window.
[14:14] <xnox> pitti: are we gonna drop using plymouth on the desktop then?! =) i wonder.
[14:14] <xnox> pitti: s/desktop/server/
[14:16] <pitti> xnox: hm, I don't know; probably nobody would even notice on a server, but some of our scripts might expect it to be there?
[14:38] <xnox> pitti: shouldn't @builddeps@ implicitly include build-essential ?
[14:39] <pitti> xnox: it does
[14:39] <pitti> xnox: oh wait, sorry, no; it only implies "make"
[14:40] <infinity> It definitely should imply build-essential.
[14:40] <infinity> Well, what it should do is exactly what dpkg does.
[14:40] <infinity> (Which implies build-essential, but it would be saner to ask dpkg than to guess)
[14:41] <pitti> this got introduced through debian bug 720458 which had a different use case in mind
[14:41] <pitti> but no objection to extending that
[14:42] <pitti> (bug report s'il vous plaît?)
[14:43] <infinity> pitti: Right, the only reason that worked for that bug is because perl modules happen to depend on perl and not much else from build-essential. :P
[14:43] <pitti> *nod*
[14:43] <infinity> pitti: But, per policy, build-deps are incomplete without Essential+Build-Essential.
[14:43] <pitti> infinity: yes, I fully agree
[14:43] <pitti> just explaining where it came from
[14:43]  * infinity nods.
[14:44] <infinity> pitti: Once mvo is done with my wishlist apt bugs, this might be simpler.
[14:44] <infinity> (One of them being "apt-get build-dep source-pkg-1.23.dir/" which would parse debian/control and DTRT)
[14:44] <pitti> thumbs up!
[14:45] <pitti> this is a pain to implement by hand, and there are like 5 implementations out there
[14:45] <infinity> Which also should let me kill pbuilder-satisfy-deps usage from a few places in the DC.
[14:45] <pitti> pbuilder-satisfydepends-whatnot
[14:45] <pitti> and autopkgtest has its own as slangasek didn't like the dependency :)
[14:45] <infinity> So, yeah, getting him to do dir/debian/control and .dsc
[14:46] <pitti> mostly kidding, it's actually useful to also enable/disable recommends, and pbuilder-s-d has a few quirks which are now gone
[14:46] <infinity> Yeah, apt pretty much always gets it right, mind you.
[14:46] <infinity> And has --no-install-recommends
[14:46] <infinity> Etc.
[14:46] <pitti> all hail apt!
[14:47] <xnox> all hail mvo!
[14:47] <pitti> infinity: yes, adt-run counts on that
[14:47] <pitti> it builds a dummy package with the build-arch resolved dependencies, installs it, and then calls apt-get -f install
[14:47] <pitti> ugly, but the best I could come up with without dragging in tens of MBs of dependencies
[14:47] <pitti> (pbuilder, equivs, devscripts, etc.)
[14:49] <infinity> pitti: That's more or less the "right" way to do it anyway, IMO.  Except for the "apt-get -f install" part, the best way is to actually add it to a local repo and apt-get install.
[14:49] <infinity> pitti: The end result is usually the same, though.
[14:49] <infinity> (This is what modern sbuild does these days)
[15:08] <xnox> best bug comment ever https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/384633/comments/27 =)
[15:17] <pitti> infinity: yeah, but that needs another apt-get update, which is ridiculously expensive
[15:19] <pitti> infinity: so maybe we can add "apt-get update for only a particular sources.list.d/ file" to mvo's list :)
[15:19] <pitti> that would be really useful for add-apt-repository, autopkgtest, and presumably other cases
[15:20] <pitti> @pilot out
[15:21] <infinity> pitti: It's only expensive if the other mirrors have changed, in which case, don't you want the latest anyway?
[15:22] <infinity> pitti: But for your use, "apt-get build-dep package-dir/" will solve your problem anyway.
[15:22] <pitti> infinity: yes, but it just run a minute ago, for upgrading the VM
[15:22] <tarpman> pitti, infinity: iirc sbuild injects a list into /var/lib/apt/lists directly instead of doing a full update
[15:23] <pitti> infinity: and I need that so that apt-get source can get the right version, so I can't swap it around either
[15:23] <pitti> tarpman: oh, for what? I've never seen this
[15:23] <pitti> infinity: yes, apt-get build-dep package-dir/ FTW!
[15:24] <tarpman> pitti: well, for exactly what you were talking about: to get a repo containing the build-depends package but not do a full expensive apt-get update
[15:24] <infinity> tarpman: Indeed, yes, sbuild cheats. :)
[15:25] <tarpman> I assume it wouldn't have to cheat if "update one source" existed ...
[15:25]  * infinity nods.
[15:25] <infinity> It could be a fun extension.
[15:26] <cjwatson> You can cheat differently by creating a temporary sources.list with just the source you care about and using "apt-get --no-list-cleanup update"
[15:26] <cjwatson> err with -o whatever::the::sources.list::option::is=blah
[15:27]  * tarpman makes a note to try that with sbuild
[15:28] <pitti> cjwatson: nice trick!
[15:28] <bdmurray> mvo_: are crashs like https://errors.ubuntu.com/problem/f574669b9ee9e2de062ee26daa080c3d86b90665 useful?
[15:29] <zyga> hey, I'm trying to reproduce a build failure, a package build clean in sbuild locally but I've noticed that launchpad build it in a way where various parts of debhelper get invoked with '-a' and that caused the build to fail. How can I reproduce that locally with sbuild?
[15:30] <cjwatson> run sbuild without -A
[15:30] <mvo_> bdmurray: I don't think so, that should be fixed in update-manager
[15:30] <cjwatson> Or with --no-arch-all if you have $build_arch_all = 1; in .sbuildrc
[15:31] <mvo_> bdmurray: I put it on my list, sorry that the list if currently growing and not shrinking
[15:31] <zyga> cjwatson: I never pass -A, I have build_arch_all though, tried passing --no-arch-all
[15:31] <cjwatson> $build_arch_all = 1; is like passing -A for every build
[15:31] <bdmurray> mvo_: I'm happy to help if you could elaborate on what you mean exactly.
[15:31]  * zyga tries again, though it did work (built correctly) so I cannot reproduce the failure)
[15:31] <mvo_> bdmurray: sure, I think that aptdaemon/update-manager should just show a error message but not record this as a crash
[15:32] <zyga> cjwatson: just confirmed that it is *not* causing -a to show up
[15:33] <zyga> cjwatson: (I also removed build_arch_all from .sbuildrc to be sure)
[15:34] <bdmurray> mvo_: got it
[15:35] <cjwatson> zyga: would need a full transcript etc. if you want more help
[15:35] <zyga> cjwatson: I'm trying to reproduce this build failure: https://launchpadlibrarian.net/174871384/buildlog_ubuntu-trusty-amd64.pyotherside_1.2.0-0.0%2Btrusty_FAILEDTOBUILD.txt.gz
[15:35] <cjwatson> this isn't at all magic though
[15:35] <zyga> cjwatson: note that it '-a' is passed to debhelper everywhere
[15:36] <zyga> cjwatson: that failure doesn't happen otherwise
[15:36] <cjwatson> zyga: where is the source?
[15:36] <zyga> cjwatson: https://code.launchpad.net/~zkrynicki/+archive/experiments
[15:36] <cjwatson> (for future reference, the +build URL is strictly more useful than the build log)
[15:36] <zyga> cjwatson: sorry, noted
[15:36] <cjwatson> so https://code.launchpad.net/~zkrynicki/+archive/experiments/+build/5986554 in this case
[15:36] <zyga> yeah
[15:39] <pitti> vila: bzr fails on the various stderr spam (https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-bzr/1/ARCH=i386,label=adt/console) and doesn't declare "allow-stderr"
[15:40] <pitti> vila: is that stderr expected and considered "normal" (and thus we should add allow-stderr), or considered an indication of a bug?
[15:40] <cjwatson> zyga: (testing here but slow network, please wait)
[15:40] <zyga> cjwatson: thanks for your time! :)
[15:49] <vila> pitti: hmm, you mean the stderr output needs to be declared or the test fails ? Those messages... are caused by a minor bug... with annoying ramifications. I have a fix though but I never submitted it because I thought I was the only one observing it...
[15:50] <vila> pitti: it's a test-only bug for that matter
[15:50] <pitti> vila: yes, by default stderr is considered a failure, mostly to catch unexpected warnings and such
[15:50] <xnox> vila: i can upload allow-stderr in both debian & ubuntu if you wish.
[15:50] <pitti> vila: so allow-stderr should be okay here as python's unittest will exit with non-zero on real failures
[15:50] <pitti> yes, I'm happy to do the upload (not in Debian though), I just wanted to check that it's right before
[15:50] <xnox> vila: and we can drop that if/when your fix to clean that output patch lands.
[15:51] <xnox> pitti: i'm on debian-bzr team =))))
[15:51] <pitti> xnox: ok, you earned it then :)
[15:51] <xnox> pitti: ack.
[15:51] <vila> xnox, pitti : sounds like allows-stderr if the easiest path then
[15:51] <vila> xnox: good to know and thanks !
[15:52] <vila> pitti: and to better understand, is this new ?
[15:53] <pitti> vila: the stderr output is new, yes; fail-on-stderr has always been the case
[15:53] <vila> pitti: ack
[15:53] <xnox> vila: i did a recent upload of lp:bzr into debian and merged into ubuntu.
[15:54] <pitti> yes, it's stuck in -proposed and I'm currently reviewing excuses for stuff that is "my" fault
[15:54] <pitti> and fix a few easy things and report debian bugs for the non-obvious ones
[15:54] <vila> xnox: really ?? That's awesome !
[15:54] <xnox> vila: yeah, so debian & ubuntu are at 6595 revision at the moment.
[15:56] <vila> cool, not that the latest bugs are that bad but it's good that we don't diverge too much and well, bugs are bugs so it's sad to not share the fixes ;)
[15:56]  * pitti waves good night
[15:57] <zyga> night?
[15:57] <zyga> pitti: where are you
[15:57] <pitti> zyga: well, time for Taekwondo, and I started working 12.5 hours agol..
[15:57] <zyga> ouch!
[15:57] <xnox> zyga: pitti is a very early riser.
[15:58] <zyga> pitti: enjoy your rest then :-)
[15:58] <xnox> zyga: so you can think he is based in middle east or some such =)
[15:58] <zyga> heheh
[16:48] <bdmurray> superm1: what is the status of bug 1290460? I ask because I'm trying to figure out if I should write something to add duplicates going forward.
[16:49] <tgm4883> bdmurray: I'm actually testing if that is fixed now
[16:49] <tgm4883> I think I fixed it last night
[16:49] <bdmurray> tgm4883: okay, cool
[16:50] <cjwatson> zyga: Sorry for the delay.  This reproduces cleanly for me.  sbuild -d trusty --arch=amd64 pyotherside_1.2.0-0.0+trusty.dsc => http://paste.ubuntu.com/7411452/
[16:51] <cjwatson> zyga: My .sbuildrc: http://paste.ubuntu.com/7411456/
[16:51] <cjwatson> zyga: There's a fix for this problem in click/debian/rules.  Just add this:
[16:51] <cjwatson> # Sphinx documentation is architecture-independent.
[16:51] <cjwatson> (with no contents for that rule)
[16:51] <cjwatson> override_dh_sphinxdoc-arch:
[16:56] <xnox> cjwatson: i wish sphinxdoc just do the right thing to be honest.
[16:56] <xnox> cjwatson: cause a lot of packages need that fix.
[16:57] <cjwatson> I agree but ran out of round tuits when I first encountered that
[16:57] <xnox> ack.
[16:57] <xnox> i think these days addons can declare them self indep/arch only.
[16:58] <cjwatson> Well, some packages might have arch-dep sphinx docs (e.g. if they're generated in arch-dep ways)
[16:58] <cjwatson> But the debhelper idiom would be to not fail if it has nothing to do
[17:00] <infinity> Should just yank out the error block at the bottom and done, IMO.
[17:02] <infinity> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745690
[17:02] <infinity> Already marked pending.  Curious what the pending solution is. :P
[17:02] <infinity> mitya57: ^^
[17:03] <infinity> mitya57: How did you plan to fix this?
[17:03] <ogra_> decision pending :)
[17:03] <cjwatson> infinity: http://anonscm.debian.org/viewvc/python-modules?view=revision&revision=28648
[17:03] <infinity> http://anonscm.debian.org/viewvc/python-modules/packages/sphinx/trunk/debian/dh-sphinxdoc/dh_sphinxdoc?r1=22919&r2=28648
[17:03] <infinity> Hah.
[17:03] <infinity> cjwatson: Yeah, I got there when I realised the pending was added by an alioth account. ;)
[17:04] <infinity> Perhaps we should just cherrypick that commit right now instead of fixing any more rdeps.
[17:05] <cjwatson> zyga's problem is in trusty, mind
[17:05] <infinity> And cherry-pick as an SRU?
[17:05] <cjwatson> (And click will probably have to keep the workaround due to backports)
[17:05] <cjwatson> Or that
[17:05] <infinity> I can't see how it would be harmful to do so.
[17:05] <cjwatson> Yeah
[17:05] <cjwatson> infinity: Did you have a chance to look at my lp-buildd MP?
[17:06] <infinity> cjwatson: Not yet.  I've actually had things to do (people to argue with?) at this sprint.
[17:06] <cjwatson> Ah, didn't realise you were sprinting
[17:06] <infinity> Well, crashing someone else's sprint, but yes.
[17:22] <ogra_> hmm, why does germinate-update-metapackage tell me my debootstrap is to old ... my trusty is up to date
[17:22]  * ogra_ thought he saw that go inot -updates
[17:23] <ogra_> *into
[17:25] <ogra_> hmm, because germinate would like ubuntu1 instead of ubuntu0.1
[17:25] <ogra_> weird
[17:31] <infinity> Awesome, sphinx is FTBFS in both trusty and utopic.  Guess I need to fix that before I can SRU it.
[17:31] <infinity> Grr.
[17:31] <infinity> Lunch first.
[17:35] <cjwatson> ogra_: it just compares against the version which was used by whoever constructed the source package last
[17:35] <ogra_> ah
[17:35] <ogra_> well, i grabbed the new debootstrap from LP ... all fine now
[17:35] <cjwatson> You can also edit the debootstrap-version file if you know that the version decrement makes no practical difference
[17:37] <ogra_> pitti, hmm, you dropped cordova from touch sdk-libs ...
[17:37]  * ogra_ hopes thats fine and was coordinated with the webapps team ... 
[17:38] <ogra_> (since we still support 13.10 apps in utopic)
[17:42] <psusi> I'm looking at a bug report about not being able to get /etc/default/grub back after messing it up or deleting it... I would have thought that an apt-get install --reinstall grub-pc would do it, but it says it refuses to replace deleted config file.. is there a proper way to *really* reinstall, including config files, or do you just have to purge first?
[18:02] <zyga> cjwatson: thanks for looking at this, neither me nor roadmr could reproduce (both utopic and trusty, also on sid), I'll dig around
[18:03] <zyga> cjwatson: and thanks for the solution :-)
[18:04] <zyga> roadmr: ^^ interesting how it worked (by breaking) for cjwatson
[18:04] <roadmr> oh cool... reading backlog
[18:15] <infinity> psusi: dpkg --force-confmiss
[18:33] <superm1> bdmurray: once we fix it we will SRU, but people encountering it will keep encountering it unless they use our dailies or wait until next point release
[18:33] <superm1> it's probably worthwhile to have duplicates get directed thre
[18:33] <superm1> *there
[18:43] <infinity> zyga: I'm SRUing sphinx as we speak so your fix/workaround can be backed out soonish.
[18:44] <bdmurray> superm1: ah, that's true. okay I'll set something up.
[18:45] <superm1> thanks
[18:46] <infinity> zyga: And it's already fixed in utopic (as of a few minutes ago).
[18:50] <xnox> pitti: i think i got that upstart test fixed now \o/
[18:50] <xnox> pitti: but it's omg sad one though =)
[19:51] <mdeslaur> stgraber: what images don't support capabilities? (re: iputils)
[19:55] <stgraber> mdeslaur: currently our cloud images, lxc upstream images, core images, touch images are all broken
[19:55] <mdeslaur> touch because of ext2? why the cloud images?
[19:55] <mdeslaur> what are "core images"?
[19:55] <stgraber> mdeslaur: because tar just doesn't store xattrs by default
[19:55] <stgraber> mdeslaur: nor unpacks them if they are in there
[19:56] <mdeslaur> hrm
[19:56] <mdeslaur> ok, because this probably affects gnome-keyring too
[19:56] <mdeslaur> but I guess that's not used on those
[19:56] <stgraber> yeah, it does, though the keyring is mostly on desktop images which have installer hack to reset the capability
[19:57] <mdeslaur> right
[19:57] <mdeslaur> stgraber: ok, thanks
[19:57] <stgraber> we do have a vague plan of getting fscaps working properly (discussed it here at the sprint with infinity, rbasak and smoser) but that'd involve some dpkg/debhelper changes to do right and is something we should spec and discuss with Debian first
[19:58] <stgraber> so yeah, current easy fix for the issue is to go back to setuid everywhere and SRU that back to trusty
[19:58] <mdeslaur> cool
[20:20] <roadmr> aha, so the utopic mini.iso is trying to load files from archive.ubuntu.com/dists/trusty... this works against the internet-accessible archive but will break if trying to install from a local mirror built from a utopic iso (as I usually do)
[20:20] <xnox> mdeslaur: also all wubi installation of ubuntu desktop.
[20:20] <roadmr> this also happens if I pxeboot with files extracted from the full utopic iso
[20:20]  * mdeslaur pretends he didn't hear wubi
[20:21] <xnox> mdeslaur: installer recently gained capability to transfer capabilities.
[20:21] <xnox> roadmr: correct, we didn't refresh apt-setup for utopic yet.
[20:22] <roadmr> xnox: is it worth filing a bug over, is there a bug already, or is it best to wait?
[20:22] <roadmr> xnox: OTOH if there's no bug and one is filed, you can point lost souls like myself to it instead of explaining every time :)
[20:23] <xnox> roadmr: no need for bug-report. all d-i components need merging, that hasn't yet been done post archive opening.
[20:23] <xnox> roadmr: you are first one to notice and point-out as far as can remember =)
[20:23] <roadmr> xnox: I imagine few people install from a locally-hosted archive; most people wouldn't notice if they have internet access as it will just happily access the trusty archive
[20:24] <roadmr> xnox: but that's good to know: I have no problem waiting and if this is not affecting other people then it's ok. That was my main concern.
[20:29] <dobey> hmm, why is autoremove --purge not removing some old kernels? :(
[20:30] <dobey> i still have -10, -11, -12, and -23 on trusty
[20:39] <cjwatson> stgraber: I did fix the server installer to handle that too
[20:43] <xnox> roadmr: fixing installer, will upload after test build. It FTBFS with make 4 as well, so had to cherry-pick patches to fix it.
[20:44] <roadmr> xnox: oh thanks! much appreciated
[20:45] <mterry> pitti, have you used ofono-phonesim-autostart lately on the phablet image?   Having trouble getting it to work
[20:46] <mterry> pitti, well, specifically the "/usr/share/ofono/scripts/dial-number 199" call
[21:51] <infinity> zyga: Are you around?
[21:52] <doomlord_> anyone here familiar with compiz plugins? ... i'm curious to know how hard it would be to adapt the desktop management to do a few things..
[22:11] <infinity> zyga: dh_sphinxdoc in trusty-updates is now fixed, you shouldn't need the hackish workaround in debian/rules for your package.
[22:18] <SpamapS> Heh, bug 1313550 is a fun one.
[22:18] <SpamapS> Was going to verify it but looks like it is on the fast track to trusty-updates ?
[22:18] <infinity> SpamapS: Already done.
[23:25] <zyga> infinity: thanks, that's good to know! :)
[23:36] <zyga> infinity: curiously enough trusty worked but utopic failed, I assume that sphinx is still in -proposed somewhere and waits for migration to finish
[23:36] <zyga> infinity: https://code.launchpad.net/~zkrynicki/+archive/experiments/+packages
[23:36] <infinity> zyga: Exactly that, yes.  It's still in utopic-proposed.
[23:37] <zyga> infinity: ah, then nothing to worry about, thanks for the quick fix :)