[00:22] <mdeslaur> slangasek: thanks
[05:27] <pitti> Good morning
[05:29] <pitti> TJ-: we could add support for keyscripts, it's "just" a matter of doing it
[05:30] <TJ-> pitti: presumably not in the way upstream wants it done?
[05:31] <pitti> TJ-: I don't remember right now how they want it done; but at least noninteractive key scripts shouldn't be so hard
[05:31] <pitti> interactive ones will be of course, but I suppose the purpose of keyscripts is to be not interactive?
[05:32] <TJ-> It can be either; sometimes in order to 'find' a key-file on some external device
[05:32] <TJ-> Other times it might be to avoid the default keyboard input if it isn't trusted
[05:52] <TJ-> I was reading the mailing-list threads, and Lennart expressed a desire to wait until a generic API can be put in place that uses the kernel keyring, and there was mention of a FreeDesktop API for PasswordAgents. I've added a reference to that discussion to bug #1451032
[07:16] <dholbach> good morning
[09:13] <alkisg> Hi, in Wily there's an ifup@.service which unconditionally runs ExecStop=ifdown %I.
[09:13] <alkisg> Previously, init.d/networking and init/networking.conf cared so that ifdown wasn't run if a network file system, or a network swap, were active
[09:13] <alkisg> This affects us in the LTSP project. I can work around it, but possibly other projects will be affected as well.
[09:14] <alkisg> So, what would be the proper way to hanlde it? To file a bug report against systemd in Ubuntu?
[09:16] <alkisg> Also, when systemd calls sysvinit services, it doesn't set $RUNLEVEL. Some of the Ubuntu services do use that environment variable. Should I file another bug report for that?
[09:22] <pitti> alkisg: please file bugs against these services, yes; there is no concept of runlevel outside of sysvinit itself
[09:23] <pitti> I think upstart might have some emulation of it, but the whole concept has gone for a long time
[09:23] <alkisg> pitti: thanks, and what should I do about my first question?
[09:24] <alkisg> I.e. does systemd in ubuntu care about not running ifdown when the network is in use by file systems, like the networking service did?
[09:24] <pitti> alkisg: no, but this is a bit backwards
[09:24] <pitti> alkisg: ifup@.service gets stopped when the interface disappears
[09:24] <pitti> i. e. it calls ifdown to clean up ifupdown's state after a hot-unplug event
[09:25] <pitti> alkisg: but I might miss something there, can you please file a bug with the details and the journal so that we have the data there and can discuss?
[09:25] <alkisg> pitti, what I'm experiencing is, if I remove the ExecStop=ifdown line, then the interface stays around and is up and everything terminates correctly
[09:25] <pitti> alkisg: ah, I guess it might also be stopped during shutdown, yes; that sounds like some missing dependencies
[09:26] <pitti> alkisg: ah, so that was the previous workaround for not having proper dependencies, good to know :)
[09:26] <alkisg> Ah so the desired solution there would be to fix the dependencies so that ifup doesn't stop when the network filesystem is still needed?
[09:27] <pitti> no, that network-using services are stopped before tearing down the network
[09:27] <pitti> in particular, they should have After=network.target; most stuff should already have it, but it seems there are some missing bits?
[09:27] <alkisg> pitti, systemd says it supports the case of a networked root file system, as long as the network interface is brought up in the initramfs, and cleaned up there in the end
[09:28] <alkisg> They chain back to the initramfs for clean up
[09:28] <alkisg> But, ifdown must not be called and the network file systems must not be unmounted until the initramfs is called again
[09:29] <pitti> alkisg: we don't go back to the initramfs on shutdown
[09:29] <pitti> alkisg: I think dracut does that (or can do that), but we don't use that yet
[09:29] <alkisg> I know, I don't expect to have it solved properly soonish, but whatever we fix now should be in that ^ way, right?
[09:29] <alkisg> I.e., the interfaces should stay up, not be brought down...
[09:30] <pitti> alkisg: ack, so please file a bug; if you already know how upstart worked around that (i. e. what it test to see whether or not to shut down stuff), please link to that, to save some searching (if not, I'll find it somewhere)
[09:30] <alkisg> Sure, it's check_network_file_systems in /lib/lsb/init-functions
[09:30] <alkisg> Called by init.d/networking and init/networking.conf
[09:30] <pitti> alkisg: but then you keep processes like dhclient around which prevent proper unmounting of / and thus a clean shutdown
[09:30] <alkisg> Thanks, I'll file a bug report
[09:31] <alkisg> dhclient is supposed to be ran from the initramfs, if at all needed
[10:19] <pitti> Laney: do you have any concerns about bug 1492129?
[10:23] <Laney> pitti: I don't feel very confident in reviewing the actual change (I guess mbiebl or someone did though) but if it's genuinely opt-in then no
[10:24] <pitti> Laney: yes, it's out of the question to use this by default for wily (maybe snappy will consider it, but we haven't talked about it yet)
[10:25] <pitti> Laney: yeah, it's just a bureaucrazy, but I didn't feel like just slipping this in as it kind of is a new feature
[10:25] <pitti> (unless you consider missing integration with if-up.d/ a bug..)
[10:34] <Laney> pitti: what's the resolved integration going to be?
[10:34] <Laney> resolvconf*
[10:38] <sidi> I'm trying to force a package in my PPA to autoreconf before it configures, or else it wont be able to build
[10:39] <sidi> i've put this in my rules: http://bazaar.launchpad.net/~ucl-cs-study-devs/activityfinder/xfwm4-4.11.1-2ubuntu2/view/head:/debian/rules but it still wont call xdt-autogen
[10:39] <sidi> what am i doing wrong?
[10:40] <doko> apw, not sure if you or somebody else complained about th eppc64el cross compiler. but it's not updated
[10:40] <apw> doko, i think it was rtg who complained first, though i have noticed it is behind, and has the same -m issue that the main one did
[10:40] <doko> pitti, can we override all the gcc-5 triggered tests, to start the test rebuild?
[10:42] <doko> apw, ahh, ok. I assume rtg is doing some +1 maintenance. please could he avoid to change 'any' packages to arch specific ones?
[10:43] <apw> doko, i am not sure, i don't think he was fixing anything just notcing we couldn't pre-test cross
[11:07] <cjwatson> sidi: You've written "--with-autoreconf" when it should be "--with=autoreconf".
[11:08] <cjwatson> sidi: Also I would advise against having debhelper override rules depend on anything because I think it gets rather confusing; I'd just write "override_dh_auto_configure:" rather than "override_dh_auto_configure: override_dh_autoreconf".
[11:08] <cjwatson> (You could easily end up with multiple autoreconf runs your way, because make doesn't know when override_dh_autoreconf is done unless it's part of the same make run ...)
[11:09] <sidi> cjwatson, to be honest i've been testing various things at this stage... will fix the with line and see if it works!
[11:09] <sidi> if i get at least one autoreconf run i'm happy... i added dependencies and they're not picked up right now
[11:10] <cjwatson> cyphermox: FYI I'm merging wily's grub2 into unstable
[11:58] <jamespage> doko, libcommons-cli-java uploaded without maven
[11:59] <doko> jamespage, cool, thanks
[11:59] <jamespage> doko, probably a useful template for reverts going forard
[11:59] <jamespage> doko, http://launchpadlibrarian.net/216361477/libcommons-cli-java_1.3.1-2_1.3.1-2ubuntu1.diff.gz
[12:06] <doko> jamespage, I was looking at the dovecot merge, neglected for the 18 months ... debian dropped the ssl cert support between 2.2.13-5 and 2.2.13-8. do you have any suggestion how to handle that in ubuntu?
[12:09] <pitti> doko: absolutely; I usually do, just wanted to wait a bit until the queue settles down
[12:10] <pitti> doko: hint updated
[12:11]  * pitti hints apparmor as well, another victim of NetworkManager
[12:12] <pitti> Laney: resolvconf> I don't know yet for sure; the BP has some ideas
[12:13] <pitti> Laney: I adjusted bug 1492129, let's handle resolvconf separately then
[12:13] <Laney> pitti: OK, I was going to pre-ACK but wanted some idea of what it would be first. :)
[12:51] <tjaalton> tdaitx: there's already a MIR for uid/nss-wrapper
[12:51] <tdaitx> tjaalton, I saw it, thanks =)
[12:52] <tjaalton> and unorphaned in debian now, so moving to main should be ok
[13:24] <tnkhanh> hi where can I talk about wily?
[13:26] <dobey> tnkhanh: if you want support, #ubuntu is the channel for you
[13:27] <tnkhanh> dobey: ok thanks
[13:28] <ogra_> i think there is a special channel for support for  unreleased versions ... but the guys in #ubuntu can tell you
[13:29] <Laney> #ubuntu+1
[13:30] <ogra_> ah, right
[15:47] <Sweet5hark> stgraber: soo seb128 is on vacation and as I consider to reapply for package upload rights, I wonder if you could review and sponsor this: http://people.canonical.com/~bjoern/wily/5.0.1/libreoffice_5.0.1-0ubuntu1_source.changes and http://people.canonical.com/~bjoern/wily/5.0.1/libreoffice-l10n_5.0.1-0ubuntu1_source.changes
[15:47] <Sweet5hark> stgraber: sponsoring blocks of course on bug 1491964, but as we are late in the game and reviewing libreoffice takes a while, its probably better not to wait on the greenlight from ubuntu-release with reviewing
[15:49] <Sweet5hark> stgraber: note that this upload needs uploads for writer2latex and nlpsolver along with it, if you would want to review those too, just tell me ...
[16:03] <doko> barry, https://bugs.launchpad.net/ubuntu/+source/kubuntu-driver-manager/+bug/1474539 is not Python specific
[16:07] <barry> doko: doesn't matter.  still a ftbfs, and just piggybacking on existing bug
[17:29] <infinity> pitti: Around?
[18:13] <smoser> stgraber, around ?
[18:14] <stgraber> smoser: yeah
[18:14] <smoser>  http://paste.ubuntu.com/12275296/
[18:15] <smoser> we're writing a /etc/network/interfaces like that.
[18:15] <smoser> and it doesnt want to come all the way up on 'auto'
[18:15] <smoser> (i'm  pretty sure that the hwaddress are not needed on the eth* but removing them d oesnt cause a problem)
[18:15] <rharper> smoser: well, it does come all the way up; but only after quite some time
[18:15] <smoser> ifupdown never thinks its up
[18:16] <smoser> that is on trusty
[18:16] <rharper> right
[18:17] <stgraber> I'm not seeing anything wrong with this config, though I've never used active-backup...
[18:17] <stgraber> smoser: I'd suggest you wipe /var/log/upstart/*, then reboot and look for any networking related /var/log/upstart logfile
[18:18] <smoser> yeah, there is such things there.
[18:39] <smoser> stgraber, http://paste.ubuntu.com/12275511/
[18:39] <smoser> maybe that helps a bit. after a boot, nothing touched manually
[18:40] <smoser> remember / know that cloud-init is forcing a bottleneck in boot on
[18:40] <stgraber> smoser: so the "file exists" error usually indicates that the interface already had an IP or route on it
[18:40] <smoser>  start on mounted MOUNTPOINT=/ and stopped cloud-init-local
[18:41] <stgraber> smoser: unsure what the I/O error is though, never seen that one before
[18:41] <stgraber> smoser: oh, of course
[18:41] <smoser> that'd be toolate anyway though
[18:41] <stgraber> smoser: sorry I didn't see it before, your config is wrong
[18:41] <smoser> ie, 'networking' shoudlnt bring anything up
[18:41] <stgraber> smoser: you can't have two interfaces defining a gateway
[18:42] <smoser> what 2 interfaces do that ?
[18:42] <stgraber> eth0 and bond0
[18:43] <smoser> hm.
[18:44] <smoser> well in that case, how would you tell dhcp to not respect the gateway that it got ?
[18:44] <stgraber> you'd have to change /etc/dhclient.conf I suspect
[18:44] <smoser> and in the event of multipe ncs doing dhcp, how would that not be a problem. ie, i connect 2 nics to the 'usernet' in qemu
[18:44] <smoser> (or lxc if you'd rather)
[18:44] <smoser> and tell them to dhcp
[18:45] <smoser> wouldnt 'that inherently cause the same "multiple gateway" problem ?
[18:45] <stgraber> it would
[18:45] <stgraber> and there's nothing ifupdown can do about it, the kernel won't let you have two default gateway with the same priority
[18:46] <stgraber> it's also not something ifupdown can detect since whether you get a gateway or not depends on your dhcp client config and your dhcp server config
[18:46] <smoser> right.
[18:46] <smoser> rharper, ^
[18:46] <stgraber> you could have a dozen interfaces setup with dhcp and not run into that problem if their dhcp server wasn't pushing a default gateway
[18:47] <rharper> I'm dropping the extra gateway from the configuration;  if we do support that we'll have to do it via post-up scripts
[18:48] <rharper> you have to set metric IIUC
[18:48] <smoser> rharper, just commenting that out does solve the problem
[18:49] <rharper> yeah
[18:49] <smoser> its really quite painful
[18:49] <rharper> yes, yes it is
[18:49] <smoser> in as stgraber pointed out its an invalid config
[18:49] <smoser> but if you plugged eth0 into adifferent network, it might not be :)
[18:49] <rharper> or if you didn't get gateway back in dhcp response
[18:52] <smoser> rharper, http://ubuntuforums.org/showthread.php?t=2208119
[18:52] <smoser> we could potentially do something in a script in /etc/dhclient/dhclient-enter-hooks.d
[18:53] <smoser> that looked at the interfaces, and only listened to gateway if no other auto had a gateway
[18:53] <rharper> but how do we know they want that
[18:53] <rharper> the dhcp server configuration is out of our scope
[18:53] <smoser> or i guess since when you're rendering things, you know this.
[18:53] <rharper> it may have it one day and not another
[18:54] <rharper> we don't know if dhcp will return a gateway
[18:54] <rharper> and we don't know which route they'd prefer (explict one)
[18:54] <smoser> rharper, well, in your case its easy
[18:54] <smoser> your networking ocnfig that you're supplied is definitive and says that the gateway is on the bond.
[18:54] <smoser> so it should ignore anything else.
[18:54] <rharper> I don't think so
[18:55] <smoser> how so?
[18:55] <smoser> the config says the gateway is on that device.
[18:55] <rharper> at least it's not clear to me that we should do that; vs. saying bond has gateway is invalid when you also have a dhcp configuration
[18:55] <rharper> a gateway
[18:55] <rharper> you can have more than one, but must supply metric information
[18:56] <rharper> I want to step back and query folks who have existing configurations and validate those;  if we need to emit some sort of dhcp ignore new gateway if we've defined one; then we can do that
[18:56] <rharper> but it's more complicated than saying folks need to give us working input to begin with;
[18:57] <rharper> until today; it wasn't obvious to me that you couldn't put in more than one gateway (as I expose my lack of networking-fu to the channel)
[18:57] <rharper> retrospectively it seems obvious
[18:57] <smoser> right.
[18:58] <smoser> but your case is very simplified.
[19:08] <Sweet5hark> stgraber: did you see the backlog?
[19:12] <stgraber> Sweet5hark: oh, yeah, sorry, forgot to respond. I'm currently behind on a bunch of NEW reviews and am only around for a day or so next week due to travel, so unless you're fine waiting until after the 15th of September, I won't really be able to help you :(
[19:14] <Sweet5hark> stgraber: do you have someone in mind from the dmb who might step in with a review?
[19:16] <stgraber> Sweet5hark: as far as people being around on IRC lately, I can think of Laney and cyphermox but I have honestly no idea how busy they are these days :(
[19:26] <Sweet5hark> stgraber: kk, thanks
[19:33] <cyphermox> Sweet5hark: I can do reviews of stuff but I can't help you with NEW so much if it's to review things already in the queue
[19:56] <stgraber> cyphermox: my understanding is that it's a packaging + sponsor review of libreoffice by a DMB member in preparation for Sweet5hark re-applying for PPU of libreoffice
[19:56] <stgraber> *packaging review + sponsor
[20:03] <cyphermox> yeah, that's fine
[20:03] <cyphermox> except for the obvious "omg I'm uploading libreoffice"
[20:04] <cyphermox> :)
[20:09] <mterry_> bdmurray, ~sssd has committed to caring for nss-wrapper and uid-wrapper, FYI
[20:11] <bdmurray> mterry_: that's a lot of s'es
[20:11] <mterry_> bdmurray, :)
[20:31] <slangasek> @pilot in
[21:15] <doko> mterry_, http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg is your friend ;)
[21:17] <mterry_> doko, I usually use check-mir
[21:17] <mterry_> Just forgot  :(
[21:30] <Umeaboy> Hi!
[21:30] <Umeaboy> Any kernel devs here?
[21:31] <Umeaboy> I know that the PPA on Launchpad is for Testing of the kernel, but I wonder when 4.1 will be released as an update to 15.04.
[21:31] <Umeaboy> I have a driver issue with nouveau that I think is fixed in 4.1.
[21:32] <Umeaboy> And YES I have installed nvidia-prime for my Optimus as well.
[21:32] <Umeaboy> Sometimes Ubuntu 15.04 won't get to boot screen.
[21:32] <Umeaboy> It just halts.
[21:32] <infinity> Umeaboy: Never.
[21:33] <infinity> Umeaboy: We don't update to new major kernel versions in stable releases (except for hardware enablement stacks on LTSes, which 15.04 is not)
[21:33] <Umeaboy> infinity: Right.
[21:34] <Umeaboy> Can I use the official tar from kernel.org and build the necessary packages then?
[21:34] <infinity> I wouldn't recommend it.
[21:34] <Umeaboy> I have little to no experience with building debs.
[21:34] <Umeaboy> rpms YES.
[21:34] <infinity> You can install the wily kernel on vivid, if you really want to go that route.
[21:35] <Umeaboy> infinity: OK. Is there a changelog for it?
[21:35] <sarnold> the kernel-package package provides some tools to help build debs from upstream kernels
[21:35] <infinity> Yes, but upstream kernels lack all the Ubuntu sauce, which may not be what people really want.
[21:35] <sarnold> *nod*
[21:37] <Umeaboy> So, I have Hybrid Graphics.
[21:37] <Umeaboy> One Intel and one Nvidia GeForce GTX 850M
[21:37] <infinity> Umeaboy: There's a changelog: http://changelogs.ubuntu.com/changelogs/pool/main/l/linux/linux_4.2.0-7.7/changelog
[21:37] <Umeaboy> The package nvidia-prime IS installed.
[21:38] <infinity> Umeaboy: If you're experiencing an issue, though, filing a bug might be nice, too.  This isn't a support channel.
[21:38] <infinity> Umeaboy: "ubuntu-bug linux"
[21:39] <Umeaboy> Doesn't seem like it's solved.
[21:40] <infinity> Umeaboy: You installed it to test?  Or you're just guessing from the changelog?
[21:41] <infinity> Umeaboy: The changelog would be tens of thousands of lines if it listed every commit from 3.19 to 4.2
[22:10] <Unit193> Does apport not actually file bugs now?
[22:26] <sarnold> Unit193: it does, but not consistently, I'm not sure when it does vs when it just submits errors to the error tracker
[22:26] <Unit193> Nice.
[22:26] <Unit193> Thanks.
[22:36] <Unit193> sarnold: Could be it was already filed (found it under a different package than I first expected.)
[22:36] <Unit193> Found two debian bugs and an Ubuntu one.
[22:37] <sarnold> Unit193: heh, that's almost worse than finding no bugs..
[22:38] <Unit193> sarnold: Recent!  All filed today or yesterday!  There's hope still.
[22:39] <sarnold> oh! :) hooray
[22:39] <Unit193> (To be complete, lp 1492394)
[22:42] <sarnold> Unit193: eww
[23:23] <Umeaboy> Hi again!
[23:24] <Umeaboy> I added the PPA for the Canonical Kernel Team, but I didn't get the 4.1-kernel when updating.
[23:24] <Umeaboy> Could it be because I choose to not use Proposed Updates and Backports?
[23:25] <infinity> Umeaboy: (a) it's 4.2, not 4.1, (b) which PPA, (c) did you add wily or vivid (4.2 is only in wily).
[23:26] <slangasek> ppas include neither proposed updates nor backports.  however, that ppa exists for the kernel team's internal testing, not to provide newer kernels to users on older releases, so if you want the newer kernel you have to configure it to pull from wily as infinity says
[23:31] <Umeaboy> infinity: OK. I guess I should change to Wily then.