| === Guest69248 is now known as rcj | ||
| === rcj is now known as Guest46616 | ||
| === phunyguy is now known as phunyguy-zombie | ||
| === phunyguy-zombie is now known as phunyguy | ||
| pitti | Good morning | 06:24 |
|---|---|---|
| === didrocks1 is now known as didrocks | ||
| pitti | @pilot in | 10:14 |
| === udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: pitti, seb128 | ||
| === _salem is now known as salem_ | ||
| LocutusOfBorg1 | wow pitti thanks! | 11:34 |
| LocutusOfBorg1 | I'm still setting up my lucid VM :p | 11:34 |
| pitti | LocutusOfBorg1: lucid? | 11:34 |
| LocutusOfBorg1 | s/lucid/precise | 11:36 |
| LocutusOfBorg1 | :) | 11:36 |
| pitti | LocutusOfBorg1: ah, I just tested in a schroot | 11:37 |
| LocutusOfBorg1 | I can't test in my pbuilder-dist chroot because it grabs the host kernel | 11:39 |
| pitti | infinity: are you going to handle the eglibc precise SRU in bug 1020210 or want me to sponsor? (merging to current precise-security, of course) | 11:47 |
| ubottu | bug 1020210 in eglibc (Ubuntu Precise) "Race condition using ATOMIC_FASTBINS in _int_free causes crash or heap corruption" [Undecided,In progress] https://launchpad.net/bugs/1020210 | 11:47 |
| LocutusOfBorg1 | pitti, it fails with another error | 11:47 |
| LocutusOfBorg1 | please let me fix this one too | 11:48 |
| pitti | LocutusOfBorg1: i. e. do you want me to remove the previous upload? | 11:55 |
| LocutusOfBorg1 | yes if possible | 11:58 |
| LocutusOfBorg1 | I need to test with the exact kernel version, to avoid further uploads... | 11:59 |
| LocutusOfBorg1 | chroot seems to be not enough | 11:59 |
| pitti | LocutusOfBorg1: rejected, and bug updated (you can re-use the same version number) | 12:00 |
| pitti | LocutusOfBorg1: yeah, I was wondering why it still failed against 3.13, even though .7 claimed to fix that | 12:00 |
| pitti | but that bug is for 3.5 | 12:01 |
| === MacSlow is now known as MacSlow|lunch | ||
| === kitterma is now known as ScottK | ||
| LocutusOfBorg1 | pitti, virtualbox always make me sad | 12:28 |
| LocutusOfBorg1 | :) | 12:28 |
| LocutusOfBorg1 | kernel folks do their best to screw up virtualbox everytime :p | 12:32 |
| LocutusOfBorg1 | and virtualbox folks to their best to make low low low low kernel modules everytime ;) | 12:32 |
| rbasak | pitti: so my dep8 test failed with: juju-quickstart: error: bad API response: cannot upload charm to provider storage: 504 504 Gateway Time-out | 12:33 |
| rbasak | pitti: I suspect an interaction with a proxy. Does this seem likely to you? | 12:33 |
| rbasak | pitti: I don't remember the details of what happens with the proxy in the test environment. Is this documented anywhere? | 12:34 |
| pitti | rbasak: right, we don't have a direct network connection in the DC; http_proxy and https_proxy are set, but maybe the upload doesn't work through the proxy | 12:42 |
| * pitti bbl | 12:43 | |
| === MacSlow|lunch is now known as MacSlow | ||
| didrocks | jodh: pitti: added some validity unit checking for systemd reference to the wiki page (https://wiki.ubuntu.com/SystemdForUpstartUsers?action=diff&rev2=66&rev1=65) | 13:33 |
| jodh | didrocks: nice! thanks! | 13:34 |
| didrocks | jodh: yw, it's a handy tool I'm using before my uploads, especially for the server stuff when I don't always have the whole setup to test :) | 13:35 |
| jodh | didrocks: ack. would be great if we could find a way to auto-check all packages containg units before they hit the archive. I always wanted that for upstart as it would have saved a few problems :) | 13:36 |
| seb128 | wgrant, hey, launchpad is supposed to share strings from a same component between different series, right? | 13:37 |
| seb128 | do you know why | 13:37 |
| seb128 | https://translations.launchpad.net/ubuntu-rtm/14.09/+source/ubuntu-system-settings/+pots/ubuntu-system-settings/fr/535/+translate | 13:37 |
| seb128 | is untranslated | 13:37 |
| didrocks | jodh: agreed, it seems this can work offline, I need to test it though and maybe we can put it in dh-systemd | 13:37 |
| seb128 | while https://translations.launchpad.net/ubuntu/vivid/+source/ubuntu-system-settings/+pots/ubuntu-system-settings/fr/485/+translate | 13:37 |
| seb128 | is | 13:37 |
| didrocks | jodh: will handle that | 13:37 |
| seb128 | cjwatson, ^ your work on launchpad now, right? ;-) | 13:38 |
| pitti | didrocks: oh nice, I didn't know about that yet either | 13:38 |
| seb128 | is that because ubuntu-rtm != ubuntu | 13:38 |
| pitti | jodh, didrocks: wiki FTW :) | 13:38 |
| didrocks | indeed! ;) | 13:38 |
| cjwatson | seb128: I don't know Translations at all well, but I don't believe that there is any sharing between templates in different distributions, only templates in the same distribution source package and across upstream packaging relationships. | 13:44 |
| cjwatson | seb128: That said, I've just linked the ubuntu-system-settings sources in both ubuntu and ubuntu-rtm to the corresponding upstream project, which may help (possibly). | 13:44 |
| seb128 | cjwatson, ok, thanks, did that enable upstream/downstream sharing? because I think we desactivated that to get the packaging template used instead of the trunk one (the packaging one is updated on upload, the trunk one needs to be manually updated and we keep forgetting) | 13:45 |
| wgrant | It's complicated. | 13:50 |
| wgrant | I didn't fix it all completely, let me see what the edge cases are. | 13:50 |
| wgrant | Right, so there is currently no sharing between packages of the same name in related distributions, except via links to products. | 13:52 |
| wgrant | So if the package isn't connected to upstream, it won't be shared between the distros. | 13:52 |
| wgrant | cjwatson: POTemplateSharingSubset, fwiw | 13:52 |
| cjwatson | Right, found that with the big block comment listing the rules. | 13:53 |
| cjwatson | seb128: OK, if you need to deactivate it again then go for it, but it seemed like the obvious thing to do ... | 13:53 |
| wgrant | It is reasonably possible to share through DistroSeriesParent directly, if we really need that. http://pastebin.ubuntu.com/8166797/ is the terrifying query. | 13:56 |
| wgrant | But we've generally gotten away without it so far | 13:56 |
| * cjwatson hides | 13:57 | |
| didrocks | jodh: I can either add a note or remove EnvironmentFile in "Do not run service if no daemon configuration file created" case, as the upstart job doesn't source the environment file | 13:58 |
| didrocks | jodh: so the equivalent is the already present ConditionPathExists | 13:59 |
| didrocks | jodh: I can maybe add a note to precise that EnvironmentFile is doing a sourcing | 13:59 |
| didrocks | jodh: oh sorry, didn't see the env config= | 13:59 |
| didrocks | jodh: so ConditionPathExists= isn't necessary actually, EnvironmentFile will fail if the file isn't present and the job will fail | 14:00 |
| andreas__ | hi, is there a way other than inspecting /usr/share/doc/*/copyright to get all the licenses that make up the installed system? | 14:01 |
| andreas__ | I didn't find some sort of metadata key for licenses in the control file of a source package, or in "apt-cache show"'s output | 14:02 |
| svenx | woo, nice. i just managed to pull off a full reinstall without rebooting the system, by way of a tmpfs ramdisk and pivot_root | 14:04 |
| svenx | reboot to get a newer kernel in the end, though. but worked smoothly without involving any installation media. only debootstrap | 14:04 |
| didrocks | andreas__: you have to rely on /usr/share/doc/*/copyright, a lot of them now are following DEP5 (http://dep.debian.net/deps/dep5/) and so, is machine-parsable | 14:05 |
| andreas__ | didrocks: but I have to have the packages installed then, I can't get the licenses of the dependencies without installing the dependencies | 14:08 |
| andreas__ | right>? | 14:08 |
| didrocks | andreas__: you can apt-get source <package> and look at <package_dir>/debian/control if you enable the source, or download the deb manually and dpkg-deb -x to extract it in a directory | 14:09 |
| === Guest46616 is now known as rcj | ||
| === rcj is now known as Guest97390 | ||
| pitti | @pilot out | 14:19 |
| === udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: seb128 | ||
| seb128 | wgrant, cjwatson, with the change to link to the project it means the template from trunk is going to be used instead of the ubuntu build one, right? | 14:21 |
| cjwatson | seb128: I don't know for sure, so if you think there's a risk of problems then undo it. | 14:21 |
| pitti | oh, that'd be wrong | 14:22 |
| pitti | as upstream regularly forgets to push POT updates | 14:22 |
| pitti | e. g. recently vrruiz asked me about a recently changed string ("Orientation" -> "Rotation") which didn't appear in the upstream translations, but in rtm only | 14:22 |
| seb128 | pitti, right, cjwatson did that to try to get translations shared between ubuntu and ubuntu-rtm packages | 14:22 |
| pitti | ah, sharing the translations should be fine | 14:22 |
| seb128 | pitti, that's the same issue that brought that discussion | 14:22 |
| pitti | as long as ubuntu, rtm, and trunk all keep their own POTs | 14:23 |
| cjwatson | I've undone it then. | 14:23 |
| seb128 | pitti, well you can't share between different distros, out by linking to the same project | 14:23 |
| seb128 | cjwatson, thanks | 14:23 |
| seb128 | pitti, which leads to the trunk template to be used | 14:23 |
| seb128 | so I guess we need to redo translations in rtm | 14:23 |
| cjwatson | Maybe you can push them in bulk? | 14:23 |
| seb128 | or at least revalidate the suggestions that are made from the ubuntu translations | 14:23 |
| pitti | seb128: ok, that would *definitively* be wrong; but that's not how I understood message sharing | 14:23 |
| pitti | I thought each upstraem and release would always have their own template | 14:24 |
| pitti | and then message sharing merely copies matching translations back and forth | 14:24 |
| pitti | but not force a different pot? | 14:24 |
| pitti | yes, they can be pushed in bulk, it just needs to happen | 14:24 |
| pitti | also, so far message sharing actually does seem to work fine | 14:24 |
| pitti | at least between trunk and rtm | 14:24 |
| pitti | back then, I only translated trunk, and the translations appeared in RTM | 14:25 |
| pitti | (those which match the older RTM versions, at least) | 14:25 |
| pitti | so "PO sharing" → yes please; "forced POT sharing" → OMGno; that is never ever a correct thing to do | 14:26 |
| seb128 | pitti, what you describe works accross different series of Ubuntu | 14:26 |
| seb128 | but rtm is a different distro | 14:26 |
| pitti | seb128: message sharing (i. e. po sync) also generally works between upstream and distro | 14:27 |
| pitti | I don't know about direct distro to distro, I suppose that doesn't work | 14:27 |
| pitti | but rtm <-> trunk and trunk <-> ubuntu should certainly both work, and thus sync that way? | 14:28 |
| === Snow-Man_ is now known as Snow-Man | ||
| seb128 | pitti, can we enable message sharing without template sharing? if you know how to do so please do it for ubuntu-system-settings ;-) | 14:28 |
| pitti | seb128: as I said, until now I thought that message sharing always just synced the po files, and never the pots | 14:29 |
| pitti | seb128: i. e. it's the only way of message sharing which I'm aware of | 14:29 |
| seb128 | hum, k | 14:29 |
| seb128 | I think it shares template | 14:29 |
| pitti | but now I'm very confused | 14:29 |
| seb128 | because before we had that one before and the list of strings was the one from trunk | 14:30 |
| seb128 | and not the one from the package build pot | 14:30 |
| wgrant | It doesn't share the templates. | 14:30 |
| wgrant | However, I think I remember that it won't import Ubuntu *translations*. | 14:30 |
| wgrant | Or something like that. | 14:30 |
| seb128 | wgrant, it was not important the ubuntu build .pot when that setting was on | 14:30 |
| seb128 | importing* | 14:30 |
| wgrant | So if they wildly diverge, you can be missing a lot of translations from Ubuntu. | 14:30 |
| seb128 | oh, maybe it was only the .pot | 14:31 |
| seb128 | I guess we can enable the setting again and see what happens on next upload | 14:31 |
| pitti | hm, could it be that whatever cjwatson did destroyed the correct translations in RTM? | 14:31 |
| pitti | https://code.launchpad.net/~ken-vandine/ubuntu-system-settings/rtm-14.09_rotation_lock_string/+merge/240511 was the MP | 14:31 |
| pitti | Orientation -> Rotation | 14:31 |
| pitti | https://translations.launchpad.net/ubuntu-system-settings/trunk/+pots/ubuntu-system-settings/es/+translate?batch=10&show=all&search=tion+Lock | 14:31 |
| pitti | trunk is missing a POT update, so that one still has "Orientation" | 14:31 |
| pitti | yesterday, RTM's translations were correct: https://translations.launchpad.net/ubuntu-system-settings/rtm-14.09/+pots/ubuntu-system-settings/es/+translate?batch=10&show=all&search=tion+Lock | 14:32 |
| pitti | i. e. that one had "Rotation Lock" yesterday | 14:32 |
| pitti | now it has "Orientation Lock" again | 14:32 |
| wgrant | It couldn't have changed the template. | 14:32 |
| wgrant | It could have altered some of the translations, but not the msgids. | 14:32 |
| wgrant | (translation splitting is dreadfully buggy and should be avoided whereever possible, but it cannot corrupt the actual template) | 14:33 |
| pitti | wgrant: ah ok, so POTs are never ever copied between project and distros, with or without message sharing? | 14:33 |
| wgrant | Unless I gravely misunderstand it. | 14:33 |
| pitti | wgrant: that's how I understand it as well; copying POTs around would be just wrong | 14:34 |
| pitti | wgrant: ok, at least we believe the same thing :) | 14:34 |
| pitti | I just wonder how the RTM translations regressed since yesterday | 14:35 |
| seb128 | pitti, how regressed? | 14:35 |
| pitti | seb128: RTM translations had "Rotation Lock" yesterday | 14:36 |
| seb128 | pitti, it still has, https://translations.launchpad.net/ubuntu-rtm/14.09/+source/ubuntu-system-settings/+pots/ubuntu-system-settings/fr/535/+translate | 14:36 |
| seb128 | pitti, https://translations.launchpad.net/ubuntu-rtm/14.09/+source/ubuntu-system-settings/+pots/ubuntu-system-settings/es/535/+translate | 14:36 |
| wgrant | https://launchpad.net/ubuntu-rtm/14.09/+queue?queue_state=3&queue_text=ubuntu-system-settings | 14:36 |
| pitti | seb128: hm, curious -- https://translations.launchpad.net/ubuntu-system-settings/rtm-14.09/+pots/ubuntu-system-settings/es/+translate?batch=10&show=all&search=tion+Lock doesn't | 14:37 |
| pitti | oh, wrong URL then I suppose (that one is in my firefox history) | 14:37 |
| pitti | seb128: ok, then I just looked at the wrong URL today, it seems | 14:37 |
| seb128 | good | 14:37 |
| seb128 | so things should be sorted out | 14:38 |
| seb128 | wgrant, cjwatson, pitti: thanks | 14:38 |
| jamespage | didrocks, hey - can you steer clear on systemd enablement for the openstack core packages - or follow the pattern that we have for nova, cinder and keystone already | 14:55 |
| didrocks | jamespage: hum, unsure about what's not clear, I tried to follow the pattern that were used in the upstart jobs | 14:57 |
| jamespage | didrocks, so we are adopting the openstack-pkg-tools tooling to generate upstart, init and service files from a single configuration template | 14:58 |
| jamespage | didrocks, eg - https://launchpadlibrarian.net/194321367/keystone_1%3A2015.1~b1-0ubuntu1_1%3A2015.1~b1-0ubuntu2.diff.gz | 14:58 |
| didrocks | jamespage: ah, wasn't aware about that, sounds weird that openstack would have their own pkg integration, but in that case, I'll let handle your package transitions I guess | 14:59 |
| jamespage | didrocks, zigo has done a good job on this in Debian so its mostly cherry picking the init.in files and enabling the bits for rules and control | 14:59 |
| jamespage | didrocks, the reality is that pretty much every service/upstart/init file is much the same apart from the daemon, config-file and log-file names | 14:59 |
| didrocks | jamespage: I'm always checking what debian did and eventually merge, but AFAIK, I did only touch here some ubuntu-only packages | 14:59 |
| didrocks | ok, hence the generation, makes sense then | 15:00 |
| jamespage | didrocks, happy for you to leave it to my team - coreycb will be working on this | 15:00 |
| didrocks | jamespage: great, clock is ticking though if we want to do the switch ;) | 15:00 |
| jamespage | didrocks, I know | 15:01 |
| jamespage | didrocks, it should all be done in the next few working days | 15:01 |
| coreycb | jamespage, agreed should be done soon | 15:01 |
| didrocks | jamespage: nice :) | 15:01 |
| === roadmr is now known as roadmr_afk | ||
| === Guest97390 is now known as rcj | ||
| === roadmr_afk is now known as roadmr | ||
| === cmagina_ is now known as cmagina | ||
| infinity | pitti: I can pull it in. | 16:54 |
| pitti | infinity: ack, then I unsub'ed ubuntu-sponsors, to avoid someone else uploading the whole thing | 16:55 |
| pitti | stgraber: you might have missed my question from yesterday, or I missed your response -- what is the problem with virtual network interface bringup? | 17:04 |
| pitti | stgraber: "bond interfaces do not work because they're fully virtual and do not have udev events" | 17:04 |
| pitti | "same for vlans and bridges" | 17:04 |
| pitti | stgraber: if they are defined in /etc/network/interfaces, they should just work? or don't they? | 17:04 |
| pitti | stgraber: or do we have some upstart job which creates those from some different config files, which we need an equivalent unit for? | 17:06 |
| stgraber | pitti: if everything's defined in /etc/network/interfaces and all devices exist at the time ifup -a is called, it all works fine | 17:06 |
| stgraber | pitti: the problem is that you don't have to specify them all and some may show up later | 17:07 |
| pitti | stgraber: well, virtual devices don't "exist" before you ifup them? | 17:07 |
| stgraber | pitti: for example you can specify a bridge interface with bridge-ports set to eth5.1000 | 17:07 |
| pitti | stgraber: if you don't specify them in /e/n/i, then where else? | 17:07 |
| stgraber | neither eth5 nor eth5.1000 have to be defined in /e/n/i | 17:07 |
| pitti | stgraber: ok, so problem 1 is that if /e/n/i has a bridge to eth5.1000, and eth5.1000 comes up later, at that point we need to bring up the bridge | 17:08 |
| stgraber | the current code is simply that when eth5 does show up a udev rule will trigger, will check existing interfaces in /e/n/i, find the bridge, fine the interface in the bridge-ports and create the vlan on it | 17:08 |
| stgraber | right | 17:08 |
| pitti | stgraber: but it sounds like there is another case for "they are not defined in /e/n/i"? | 17:09 |
| stgraber | a good chunk of this is done through udev hooks today and they may actually be working fine regardless of the init system so long as systemd will always call ifup --allow=auto $INTERFACE whenever a udev net-device-up event is received AND call ifup -a at some point in the boot sequence | 17:09 |
| pitti | stgraber: net-device-up is an upstart event, not udev :) | 17:10 |
| pitti | (obviously we won't get them under systemd) | 17:10 |
| pitti | stgraber: at the moment we call ifup -a (through /etc/init.d/networking) during boot, and ifup <iface> through ifup@.service (udev triggered) for a hotplugged card | 17:10 |
| pitti | stgraber: so I guess the problem is that ifup <iface> only ups that iface, but not its "reverse depenencies"? | 17:11 |
| stgraber | pitti: net-device-added, sorry | 17:12 |
| stgraber | pitti: so if we want to mimick the upstart world, we need: | 17:13 |
| pitti | stgraber: never heard that, but I suppose this is just ACTION==add|remove, SUBSYSTEM="net" | 17:13 |
| stgraber | - call ifup --allow=auto <interface> whenever we get a net-device-added from udev (or the systemd name of it) | 17:13 |
| stgraber | - call ifup -a in the boot sequence | 17:13 |
| pitti | stgraber: that's what currently calls ifup@.service | 17:13 |
| pitti | stgraber: ok, understood | 17:14 |
| stgraber | - possibly update the ifupdown hook to get something like our existing static-network-up event in systemd (so services can know that we're done briging everything up) | 17:14 |
| pitti | stgraber: net-dedvice-added is still upstart, not udev, but I think I know what you mean | 17:14 |
| pitti | stgraber: anyway, I think I understand the problem now, thanks for explaining! | 17:15 |
| stgraber | pitti: right, it's the name of the upstart event as pushed by the udev <-> upstart bridge | 17:15 |
| pitti | stgraber: and I have a reasonably good idea how to automate a test for this | 17:15 |
| LocutusOfBorg1 | pitti can you please loook again at #1408939 ? | 17:16 |
| LocutusOfBorg1 | I tested both patches successfully | 17:16 |
| stgraber | static-network-up may be treaky-ish to implement with systemd. The idea behind it is that it's something jobs can depend on which is only triggered when all defined (auto) interfaces are up OR after a 2 minutes timeout. | 17:16 |
| stgraber | the way this is done is that we have an ifupdown up.d hook which has the logic to figure out whether everything was brought up and if that's the case, the event is emitted through upstart | 17:17 |
| pitti | stgraber: I updated the whiteboard to: virtual interfaces (bond, vlan, bridges) in /etc/network/interfaces do not work. E. g. /e/n/i might define a bridge for "eth1.5000" which only appears later on during runtime, thus isn't covered by "ifup -a". Thus ifup@.service needs to bring up not just the hotplugged interface but all of its reverse dependencies. | 17:18 |
| pitti | stgraber: does that sound like a correct summary? | 17:18 |
| stgraber | on the upstart side we have a job which is triggered at boot and has a 2 minute wait loop. That job is stopped when static-network-up is emitted (cancelling the wait loop). If it's not emitted within 2 minutes, then that job emits it and unblocks the boot sequence. | 17:18 |
| stgraber | pitti: no. I think the rdepends logic should basically just work with systemd since (and I just re-checked), it's currently mostly done through udev hooks directly and not custom upstart jobs | 17:19 |
| pitti | stgraber: so that's like "Depends=networking" with an additional timeout? | 17:19 |
| pitti | stgraber: ah, even better | 17:19 |
| pitti | stgraber: well, then at least the "write an autopkgtest for this" part should hold, and we have a written down explanation what that problem is :) | 17:19 |
| stgraber | pitti: I'm not very familiar with systemd, but that sounds about right, networking there being the equivalent of our current static-network-up, that is, something becoming true when all interfaces have been brought up OR a 2min timeout has been reached | 17:20 |
| pitti | LocutusOfBorg1: queued, but probably not today any more; Monday morning? | 17:20 |
| pitti | stgraber: "networking" is just /etc/init.d/networking, nothing magic | 17:20 |
| pitti | stgraber: we don't currently have a timeout for that; if ifup -a fails, the unit fails, and everything depending on it won't be started | 17:21 |
| pitti | FWIW, I'm not saying that Depends=networking is a good idea -- it's a bad one | 17:21 |
| stgraber | pitti: ok, so I guess an equivalent would be to define a unit called static-network-up (if we want to make the names match, I don't know) which does the check we've got in /etc/network/if-up.d/upstart every second or so with a 2min timeout | 17:22 |
| slangasek | stgraber, pitti, hallyn: so regarding cgmanager, it seems that we have a rough agreement that we do want cgmanager to be running and UAL to use it when pid1=systemd, correct? | 17:23 |
| stgraber | that'd give us the same functionality but in a systemd world and /etc/network/if-up.d/upstart simply wouldn't do anything with systemd | 17:23 |
| pitti | stgraber: if we need that as a dependency for upstart jobs to convert, we can do that, yes | 17:23 |
| pitti | stgraber: just to be sure -- that's totally unrelated to the virtual iface problem, right? | 17:23 |
| slangasek | if so, can we just make that change now for Ubuntu, and deal with any fallout later, unblocking the unity8 desktop? | 17:23 |
| pitti | slangasek: from my POV, yes | 17:23 |
| stgraber | pitti: we need that to keep providing some reliability to server, yes. Currently services depending on network to be ready will simply be racy under systemd and that's not acceptable. | 17:23 |
| pitti | slangasek: the main point I'd like to clarify is what cgmanager does at startup, i. e. whether it mounts /sys/fs/cgroups differently or alters the layout in a relevant way | 17:24 |
| stgraber | pitti: (when thinking of servers that can take minutes before all network cards are done showing up at boot) | 17:24 |
| LocutusOfBorg1 | pitti, I don't get the "queued", means "uploaded/waiting for accept?" or queued in your personal todolist? ;) | 17:24 |
| pitti | slangasek: but I tested it on a spare laptop, and that seemed to work reasonably well | 17:24 |
| LocutusOfBorg1 | I subscribed again -sponsors | 17:24 |
| LocutusOfBorg1 | :) | 17:24 |
| pitti | stgraber: well, a two minute timeout is racy :) | 17:24 |
| pitti | stgraber: services which make that assumption are broken by design; it's just a workaround | 17:25 |
| pitti | stgraber: but if we need it, we can provide something similar for sure | 17:25 |
| pitti | LocutusOfBorg1: into my personal todo list, I meant; sorry | 17:25 |
| stgraber | pitti: services which allow you to set the IP address that you want to bind and are fine starting up before the IP is configured are very very rare :) | 17:25 |
| LocutusOfBorg1 | ok wonderful | 17:25 |
| LocutusOfBorg1 | so I'll wait for you ;) | 17:26 |
| LocutusOfBorg1 | have a nice weekend, and feel free to ping me by mail | 17:26 |
| LocutusOfBorg1 | if needed | 17:26 |
| pitti | LocutusOfBorg1: please do re-subscribe sponsors, though; no need to block on me particularly | 17:26 |
| LocutusOfBorg1 | already done ;) | 17:26 |
| pitti | stgraber: so, I'll add another work item for that then | 17:27 |
| pitti | stgraber: I still don't understand how static-networking-up prevents races rather than introducing them, but *shrug*, I'll just look into mimicking the current behaviour then :) | 17:29 |
| LocutusOfBorg1 | bye folks! | 17:30 |
| pitti | LocutusOfBorg1: bye! | 17:30 |
| stgraber | pitti: it solves the case where the main networking job is run before all the hardware showed up by allowing an extra 2min window for everything to be up | 17:32 |
| pitti | stgraber: ah, so that way around; thanks! | 17:32 |
| pitti | stgraber: OOI, where is the 2 minutes timeout in the upstart jobs or the ifupdown hook? | 17:33 |
| seb128 | @pilot out | 17:33 |
| === udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| pitti | /etc/init/networking.conf doesn't have that, and neither /etc/network/if-up.d/upstart | 17:33 |
| stgraber | pitti: upstart (/etc/init/failsafe.conf) | 17:33 |
| stgraber | pitti: we wait 20s, show a message, wait 40 more seconds, show another message, then wait a whole more minute and give up | 17:34 |
| pitti | stgraber: ok, but how does that emit static-networking-up after 2 mins? | 17:35 |
| stgraber | pitti: hmm, very good question :) | 17:36 |
| pitti | stgraber: I thought s-n-u would be emitted after "all interfaces present" or "two minutes gone"; failsafe.conf looks more like an interactive boot question | 17:37 |
| pitti | err, not question, just message | 17:37 |
| stgraber | pitti: so apparently we don't (I was sure we did!) instead things are apparently supposed to depend on "static-netowrk-up or failsafe-boot" | 17:37 |
| pitti | ah, rc-sysinit.conf | 17:37 |
| stgraber | pitti: I guess the design was that for things simply starting on a runlevel, it'd all be fine | 17:37 |
| pitti | that has "start on (filesystem and static-network-up) or failsafe-boot" | 17:37 |
| stgraber | because we only process the regular runlevel jobs on static-network-up or failsafe-boot | 17:37 |
| stgraber | right, that | 17:38 |
| pitti | (which is the only consumer of failsafe-boot) | 17:38 |
| pitti | but that only runs rcS, not rc2 or others | 17:38 |
| stgraber | sorry, implemented all that stuff in oneiric, been a while :) | 17:39 |
| pitti | ok, enough for this week; have a good weekend everyone! | 17:39 |
| pitti | stgraber: heh, no worries; thanks for the heads-up! | 17:40 |
| stgraber | pitti: I don't think it's only rcS, the last line calls telinit which will trigger the other rcX, no ? | 17:40 |
| pitti | stgraber: possibly, yes | 17:40 |
| pitti | stgraber: it still leaves the question that other upstart jobs that expect static-network-up will never get it | 17:41 |
| pitti | that might or might not be intended | 17:41 |
| pitti | anyway, timeout, my wife is complaining rather loudly now :) | 17:41 |
| * pitti waves | 17:41 | |
| stgraber | yeah, not sure how many cases we have of people using static-network-up only | 17:41 |
| stgraber | I sure have been doing it for local jobs in the past and now understand why some of those were still racy (and shall fix them) :) | 17:42 |
| hallyn | pitti: slangasek: stgraber: on, cgmanager makes no changes to the cgroups it mounts. well, it makes no changes if they were pre-mounted. | 18:02 |
| hallyn | If they were not pre-mounted, then it sets a release-agent | 18:02 |
| hallyn | but that means systemd was not running on the host | 18:02 |
| hallyn | I suppose actually we could similarly only act on name=systemd if we find that controller was pre-mounted | 18:03 |
| hallyn | hm, no, that'll produce more differnet cases to debug, forget that | 18:03 |
| === rickspencer3_ is now known as rickspencer3 | ||
| === roadmr is now known as roadmr_afk | ||
| === salem_ is now known as _salem | ||
| === roadmr_afk is now known as roadmr | ||
| bu5hm4n | hello, can someone point me to a correct appIndicator Spec. ? :) | 22:32 |
| bu5hm4n | or Documentation | 22:32 |
| bu5hm4n | https://unity.ubuntu.com/projects/appindicators/ those links are bringing me to a 404 | 22:32 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!