[00:31] barry: bug #1454457 - do you recall where we ended up wrt stable device identifiers? [00:31] bug 1454457 in Ubuntu system image "Update fails on lack of space, after factory reset still won't update" [Undecided,New] https://launchpad.net/bugs/1454457 [01:03] robert_ancell: hey, how's life ? [01:03] got a question just now, thot you might know a trick.... [01:04] so i've hit this twice now, where i want to install a ppa on the phone...and since phone is now vivid+overlay ppa [01:04] overlay is newer than the ppa i want to install...so it doesn't install the debs i want [01:05] is there some trick, possibly with apt source list file naming or something... [01:05] to always pick a particular ppa regardless of which one is newer [01:05] ? [01:06] kgunn: apt_preferences(5) describes some pinning that may be able to help [01:06] thanks! [01:06] seems i recall "pinning" from some forgotten time [01:07] (it doesn't mention ppas, and the location seems to be based on server name, so it might not actually work out..) [01:18] kgunn, yeah, pinning is what you want [01:18] robert_ancell: sarnold ...thanks guys, worked === doko_ is now known as doko === tmpRAOF is now known as RAOF [04:16] can we find some articles on how to develop lxc templates? [04:49] Good morning === ming is now known as Guest29940 === freeflying__ is now known as freeflying [05:42] utlemming: ah nice, ! now we just need a /current symlink, and we're all set? === dholbach_ is now known as dholbach [07:16] good morning [07:39] ScottK, cjwatson: syslinux-themes-ubuntu-wily needs proding through binary NEW if you can find a minute [08:02] sitter: Done. [08:09] cheers [08:11] * mgedmin wonders if https://bugs.launchpad.net/ubuntu/+source/gfxboot-theme-ubuntu/+bug/1384188 will finally be fixed for 15.10? [08:11] Launchpad bug 1384188 in gfxboot-theme-ubuntu (Ubuntu) "Missing translations for 'Install Ubuntu GNOME' and 'Try Ubuntu GNOME without installing'" [Undecided,Fix released] [08:11] ugh, I meant https://bugs.launchpad.net/ubuntu/+source/gfxboot-theme-ubuntu/+bug/1442586 [08:11] Launchpad bug 1442586 in gfxboot-theme-ubuntu (Ubuntu) "gfxboot-theme-ubuntu needs an update with new translations export" [Undecided,New] [08:44] mgedmin: most probably that should have been updated for vivid indeed. [08:44] cjwatson: who should be pinged on reviewing why gfxboot-theme-ubuntu wasn't updated for vivid as per https://wiki.ubuntu.com/ReleaseProcess ? [08:46] Mirv: The why is probably simply because that was something cjwatson used to do and it slipped through the cracks while we tried to pass his bits around to everyone else. [08:46] Mirv: I think mathieu-tl now, but honestly the "why" is probably basically "fell through the cracks because cjwatson moved to" ... that. [08:46] right, that explains it [08:53] hi folks === Spr0cket- is now known as Spr0cket [09:43] sil2100, ugh, someone imported ubuntu-touch-meta from the vivid PPA to wily ... do you know if the wily seeds have been adjusted accordingly ? [09:44] ogra_: uh, well, I think simply all packages were copied [09:44] So I guess nothing was adjusted [09:44] the former chuck has slangasek's signature [09:44] this one came alone and signed by a bot [09:44] *chunk [09:45] oh [09:45] that was just the migration from proposed ... ignore me :P [09:45] sil2100: btw, do you forward-copy with or without binaries? [09:45] (it was actually in the set from yesterday) [09:46] (rebuilds would be more correct, as wily has a newer toolchain, etc.) [09:47] pitti: that was a binary copy still - a rebuild would require each version number to be changed before upload [09:47] sil2100: why? [09:47] oh, in case someone wants to dist-upgrade from vivid+PPA to wily? [09:47] (seems like a corner case to me, but *shrug*) [09:47] copying binaries seems wrong as well [09:48] they might not even be installable, due to different shlibs (that'll be caught in -proposed, but still) [09:48] pitti: since we don't want to lead to a situation where we have 2 packages with same version numbers with different binaries, where a dist-upgrade is certainly possible for touch [09:48] It was just a one-time operation [09:48] We don't intend to do any more binary copies :) [09:48] ah, it sounded like we'd regularly do this from now on [09:48] Nooo [09:48] No way [09:48] ah, ok; ignore me then :) [09:56] xnox: remember my task & start on rc RUNLEVEL=[2345] question of yesterday ? [09:59] caribou: si [09:59] caribou: what's your actual problem/but that you are trying to solve with above? [10:00] xnox: kdump-savecore must complete before any job started by 'runlevel' starts [10:00] xnox: For instance the CEPH OSD's start while kdump is dumping a kernel dump, hence eating up all the memory [10:01] xnox: triggering OOM during kexec session which has limited memory [10:01] caribou: .... and what does kdump-savecore require? you either will not have any writable filesystems to do so, or other things will be running.... [10:01] xnox: it requires that root be mounted rw [10:02] xnox: i.e. just before the rc-sysinit emits the 'runlevel' event [10:02] one can do it with systemd... where you can make this thing a dependency of the basic target. [10:02] xnox: problem is trusty specific [10:03] xnox: I fixed it with systemd & it works fine [10:03] xnox: trusty currently uses a sysvinit script, but it doesn't block upstart jobs from starting [10:04] yeah, keying on to rc is to late [10:04] xnox: so I'm switching kdump to an upstart job on trusty for that reason, but the upstart job must terminate before runlevel jobs start [10:04] task [10:04] start on starting rc-sysinit [10:04] .. [10:05] but it means that you will be executed each time there is a switch between runlevels [10:05] thus you'd need to handle that gracefully. [10:05] xnox: doesn't seem to work if I used 'starting on rc' as suggested yesterday [10:05] caribou: yes rc is just after, but rc-sysinit should be just before... [10:06] reading it again. [10:06] caribou: or better use initctl2dot to get a full graph and figure out where you need to be. [10:09] xnox: that's what I thought. & Yes, I found out about jodh initctl2dot already :-) [10:09] xnox: thanks! [10:19] xnox: Will that make rc-sysinit block on his job, or is there a different and special way one can achieve that? [10:19] Cause if his concern is that he needs to run *before* sysv, the last thing he'd want it to end up being in parallel with it. [10:19] s/it/is/ [10:19] infinity: start on starting -> blocks until one starts. "task" makes one emit "started" only after one quits. [10:20] Ahh. shiny. [10:20] infinity: yeah, looks like it's blocking normal boot [10:20] Things I never bothered to learn, and no longer need to... [10:20] infinity: it's Type=oneshot RemainAfterExit=true in the new world order. [10:20] might need to tweak my job a bit [10:21] * xnox cannot get enough of https://youtu.be/Q5lxM6uGr54 [10:22] xnox: I don't mean to alarm you, but you might be a 17-year-old white girl. [10:23] infinity: dunno, but quiting everything and moving to surf in costa rica sounds attractive right about now. [10:23] Heh. === MacSlow is now known as MacSlow|lunch [11:57] jdstrand, sbeattie: OOI, do you plan to merge apparmor with Debian for wily? === buxy_bak is now known as buxy === MacSlow|lunch is now known as MacSlow [12:58] hmm, I'm trying to use git-buildpackage and it just gives me an _amd64.changes, not a _source.changes like "dpkg-buildpackage -S" does. Do I dare to dput the _amd64.changes file or is that stupid? [12:58] dputting it to Launchpad will get you a rejection. [12:59] ok [12:59] diwic, sounds like to built a binary and not a source package [12:59] git-buildpackage -S should give you a _source.changes. [12:59] git-buildpackage takes all the same parameters that dpkg-buildpackage does. [12:59] rbasak, thanks [12:59] I'll try that [12:59] it's "gbp buildpackage" now, FTR [12:59] (has been for a few years, but in wily the git-* aliases got removed) [13:00] pitti: you mean $ dgit sbuild, right?! [13:00] =))))) [13:01] pitti, gbp ? okay [13:01] hi all, I am having a problem: I use travis CI on GitHub for testing my python application and I need libxml2 >= 2.9.0 for validation purposes. The problem is that I have not found this version in precise backports or in Launchpad. So I tried myself and I am stuck a bit. Could someone take a look at my ppa for some hint? [13:02] https://launchpad.net/~gcpp-kalxas/+archive/ubuntu/ppa-tzotsos/+packages [13:02] thanks everyone [13:02] I would really appreciate a hint on this problem. libxml 2.8.0 builds fine and finds Python.h in UbuntuGIS [13:03] https://launchpad.net/~ubuntugis/+archive/ubuntu/ubuntugis-unstable/+sourcepub/2892970/+listing-archive-extra [13:04] slangasek: no. also, are you sure about that bug #? [13:06] kalxas: The stuff in debian/rules probably wants to be just python-config rather than $(DEB_HOST_GNU_TYPE)-python-config for precise (similarly for python-dbg-config). The multiarch python-config names weren't introduced until python-defaults 2.7.3-10 in December 2012, which was after precise. [13:07] cjwatson, thanks! [13:08] will try and report back === bduncan_ is now known as bduncan [13:53] xnox: btw, did you see that Lennart reviewed your "runtime preset" patch a few weeks ago? [13:56] pitti: i did, but i didn't have time to reply yet. Busy with something else at the moment. [13:57] pitti: i don't believe he is right in his review... as without checks runtime presets default to "enable *" and there lies madness. [13:57] pitti: but need to test this first. [13:57] xnox: ack, just wanted to confirm that you saw it, as it took a while to get reviewed [13:57] yeah [13:57] we are using it in clearlinux.org, and it's alright. But we don't like that it delays boot =( [13:58] cjwatson, thank you very much for your help! https://launchpad.net/~gcpp-kalxas/+archive/ubuntu/ppa-tzotsos/+build/7424658 [14:04] barry: yes, that's the bug number, see comment #1 :) [14:05] kalxas: great, you're welcome [14:10] xnox: delays because it has to read all units on startup, not just the enabled ones? [14:10] pitti: yes. [14:11] pitti: and it doesn't cache them.... [14:11] pitti: speaking of which..... [14:18] hey. i'd appreciate someone reading https://bugs.launchpad.net/ubuntu/+source/curtin/+bug/1443542 [14:18] Launchpad bug 1443542 in curtin (Ubuntu) "curtin race on vivid when /dev/sda1 doesn't exist" [Undecided,Confirmed] [14:18] input on my final comment (#4) would be appreciated. [14:18] basically i assume: [14:18] a.) [14:18] b.) blockdev --rereadpt /that/block-device [14:19] c.) udevadm settle [14:19] will guarantee that partitions created in 'a' will exist in /dev [14:19] dont you need a "udevadm trigger" too ? [14:20] or is rereadpt enough to trigger udev [14:20] well, it certainly *generally* is enough. to have allowed my assumption to get as far as it has. [14:21] i imagined that 'a' makes some stuff happen in kernel, telling it to re-read ... then it sends events to udev, and 'b' is me saying "ok wait till that queue is empty". [14:22] er... sorry. above 'b' and then 'c' for my previous statement . [14:22] i guess that 'c' could read an empty queue if 'b' hadnt populated it. === JanC_ is now known as JanC === txspud` is now known as txspud === debfx_ is now known as debfx === dholbach_ is now known as dholbach === anthonyf is now known as Guest56189 === zyga is now known as zyga-phone === zyga-phone is now known as zyga === anthonyf is now known as Guest84788 === oSoMoN_ is now known as oSoMoN === benedikt_ is now known as Guest35914 === oSoMoN_ is now known as oSoMoN === Ionic is now known as Guest77056 === Guest77056 is now known as Ionic [20:40] anybody know how/where i might find the scripts that make the squid debs ? [20:40] oh maybe i should go to app-devel === pgraner is now known as pgraner-afk [20:40] or packaging LOL i'm an idiot - sorry guys === barry` is now known as barry_ === barry_ is now known as barry === Spads_ is now known as Spads === pgraner-afk is now known as pgraner === msbrown is now known as msbrown-afk [21:49] stgraber: infinity: so we have MRE for lxc; can that be applied to lxcfs (which only exists in wily and vivid right now)? [21:50] hallyn: I'm inclined to lump lxc and lxcfs together (and, indeed, not sure why the latter wasn't just bundled with the former in the packaging). [21:50] infinity: there are some bugs in vivid fixed in wily; what would be the process right now to get the wiliy package into vivid? [21:52] hallyn: Ask nicely, show a diff and explain the bugs fixed, and explain how it fits the general rules of the lxc MRE (no shiny new features, well-tested, blah blah). [21:53] in a bug opened against lxcfs? [21:53] hallyn: Aye. [21:53] infinity: thanks. will post that in a bit [22:06] infinity: hm, what do i call the version? (0.7-0ubuntu4 is the old version, 0.9-0ubuntu1 is the wily version)? do i create a 0.9-0ubuntu1~15.04.1 ? [22:07] going by ff example i guess 0.9-0ubuntu0.15.04.1 [22:10] hallyn: If it's a straight backport of the wily version (ie: identical source with a new changelog entry on the top), it's 0.9-0ubuntu1~15.04.1, if it's the vivid packaging with the new upstream applied, it's 0.9-0ubuntu0.15.04.1 [22:11] hallyn: We tend to prefer the latter, but if packaging changes are equally important in this case, the former works. [22:11] it can be a straight backport. [22:11] oh, you *prefer* the latter? [22:12] np, can do [22:12] thakns [22:12] hallyn: One changelog entry that actually spells out the reason for the SRU is much more pleasant than 7 changelog entries between old and new that say "new upstream; fixed a thing" over and over. [22:12] cool [22:14] hallyn: But the more usual reason for the argument is that packaging drifts over time to accomodate the rest of userspace/toolchain/etc in a newer series, and shoehorning the new upstream into the old packaging is usually the path of least disruption. [22:14] hallyn: Probably not actually true or meaningful in this case, but yeah. [22:14] hallyn: Anyhow, I won't reject either option, I imagine, if the result is sane, so do whatever feels more correct for the package. [22:15] and, i should attach a debdiff, or point to new source? [22:16] hallyn: A diff is fine. If the diff is unwieldly, that's usually a good sign that it's a lousy SRU candidate. [22:16] * infinity stares at the kernel team. [22:16] cool, thanks. [22:19] posted bug 1454862, now leaving for the week (will check in tonight) [22:19] bug 1454862 in lxcfs (Ubuntu) "[MRE] merge 0.9 (which is currently in wily) to vivid" [Undecided,New] https://launchpad.net/bugs/1454862 [22:23] hallyn: Ta. I'm out for the week too, but I'll open that in a tab and consider caring. ;) [22:23] lol [22:23] thanks i appreciate that :) [23:32] oops. [23:32] @pilot out === udevbot changed the topic of #ubuntu-devel to: Archive: wily 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: