[00:31] <slangasek> barry: bug #1454457 - do you recall where we ended up wrt stable device identifiers?
[01:03] <kgunn> robert_ancell: hey, how's life ?
[01:03] <kgunn> got a question just now, thot you might know a trick....
[01:04] <kgunn> 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] <kgunn> overlay is newer than the ppa i want to install...so it doesn't install the debs i want
[01:05] <kgunn> is there some trick, possibly with apt source list file naming or something...
[01:05] <kgunn> to always pick a particular ppa regardless of which one is newer
[01:05] <kgunn> ?
[01:06] <sarnold> kgunn: apt_preferences(5) describes some pinning that may be able to help
[01:06] <kgunn> thanks!
[01:06] <kgunn> seems i recall "pinning" from some forgotten time
[01:07] <sarnold> (it doesn't mention ppas, and the location seems to be based on server name, so it might not actually work out..)
[01:18] <robert_ancell> kgunn, yeah, pinning is what you want
[01:18] <kgunn> robert_ancell: sarnold ...thanks guys, worked
[04:16] <tbharath_> can we find some articles on how to develop lxc templates?
[04:49] <pitti> Good morning
[05:42] <pitti> utlemming: ah nice, ! now we just need a /current symlink, and we're all set?
[07:16] <dholbach> good morning
[07:39] <sitter> ScottK, cjwatson: syslinux-themes-ubuntu-wily needs proding through binary NEW if you can find a minute
[08:02] <infinity> sitter: Done.
[08:09] <sitter> 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] <mgedmin> ugh, I meant https://bugs.launchpad.net/ubuntu/+source/gfxboot-theme-ubuntu/+bug/1442586
[08:44] <Mirv> mgedmin: most probably that should have been updated for vivid indeed.
[08:44] <Mirv> 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] <infinity> 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] <cjwatson> Mirv: I think mathieu-tl now, but honestly the "why" is probably basically "fell through the cracks because cjwatson moved to" ... that.
[08:46] <Mirv> right, that explains it
[08:53] <LocutusOfBorg1> hi folks
[09:43] <ogra_> 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] <sil2100> ogra_: uh, well, I think simply all packages were copied
[09:44] <sil2100> So I guess nothing was adjusted
[09:44] <ogra_> the former chuck has slangasek's signature
[09:44] <ogra_> this one came alone and signed by a bot
[09:44] <ogra_> *chunk
[09:45] <ogra_> oh
[09:45] <ogra_> that was just the migration from proposed ... ignore me :P
[09:45] <pitti> sil2100: btw, do you forward-copy with or without binaries?
[09:45] <ogra_> (it was actually in the set from yesterday)
[09:46] <pitti> (rebuilds would be more correct, as wily has a newer toolchain, etc.)
[09:47] <sil2100> pitti: that was a binary copy still - a rebuild would require each version number to be changed before upload
[09:47] <pitti> sil2100: why?
[09:47] <pitti> oh, in case someone wants to dist-upgrade from vivid+PPA to wily?
[09:47] <pitti> (seems like a corner case to me, but *shrug*)
[09:47] <pitti> copying binaries seems wrong as well
[09:48] <pitti> they might not even be installable, due to different shlibs (that'll be caught in -proposed, but still)
[09:48] <sil2100> 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] <sil2100> It was just a one-time operation
[09:48] <sil2100> We don't intend to do any more binary copies :)
[09:48] <pitti> ah, it sounded like we'd regularly do this from now on
[09:48] <sil2100> Nooo
[09:48] <sil2100> No way
[09:48] <pitti> ah, ok; ignore me then :)
[09:56] <caribou> xnox: remember my task & start on rc RUNLEVEL=[2345] question of yesterday ?
[09:59] <xnox> caribou: si
[09:59] <xnox> caribou: what's your actual problem/but that you are trying to solve with above?
[10:00] <caribou> xnox: kdump-savecore must complete before any job started by 'runlevel' starts
[10:00] <caribou> xnox: For instance the CEPH OSD's start while kdump is dumping a kernel dump, hence eating up all  the memory
[10:01] <caribou> xnox: triggering OOM during kexec session which has limited memory
[10:01] <xnox> 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] <caribou> xnox: it requires that root be mounted rw
[10:02] <caribou> xnox: i.e. just before the rc-sysinit emits the 'runlevel' event
[10:02] <xnox> one can do it with systemd... where you can make this thing a dependency of the basic target.
[10:02] <caribou> xnox: problem is trusty specific
[10:03] <caribou> xnox: I fixed it with systemd & it works fine
[10:03] <caribou> xnox: trusty currently uses a sysvinit script, but it doesn't block upstart jobs from starting
[10:04] <xnox> yeah, keying on to rc is to late
[10:04] <caribou> 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] <xnox> task
[10:04] <xnox> start on starting rc-sysinit
[10:04] <xnox> ..
[10:05] <xnox> but it means that you will be executed each time there is a switch between runlevels
[10:05] <xnox> thus you'd need to handle that gracefully.
[10:05] <caribou> xnox: doesn't seem to work if I used 'starting on rc' as suggested yesterday
[10:05] <xnox> caribou: yes rc is just after, but rc-sysinit should be just before...
[10:06] <xnox> reading it again.
[10:06] <xnox> caribou: or better use initctl2dot to get a full graph and figure out where you need to be.
[10:09] <caribou> xnox: that's what I thought. & Yes, I found out about jodh initctl2dot already :-)
[10:09] <caribou> xnox: thanks!
[10:19] <infinity> xnox: Will that make rc-sysinit block on his job, or is there a different and special way one can achieve that?
[10:19] <infinity> 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] <infinity> s/it/is/
[10:19] <xnox> infinity: start on starting -> blocks until one starts. "task" makes one emit "started" only after one quits.
[10:20] <infinity> Ahh. shiny.
[10:20] <caribou> infinity: yeah, looks like it's blocking normal boot
[10:20] <infinity> Things I never bothered to learn, and no longer need to...
[10:20] <xnox> infinity: it's Type=oneshot RemainAfterExit=true in the new world order.
[10:20] <caribou> might need to tweak my job a bit
[10:21]  * xnox cannot get enough of https://youtu.be/Q5lxM6uGr54
[10:22] <infinity> xnox: I don't mean to alarm you, but you might be a 17-year-old white girl.
[10:23] <xnox> infinity: dunno, but quiting everything and moving to surf in costa rica sounds attractive right about now.
[10:23] <infinity> Heh.
[11:57] <pitti> jdstrand, sbeattie: OOI, do you plan to merge apparmor with Debian for wily?
[12:58] <diwic> 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] <cjwatson> dputting it to Launchpad will get you a rejection.
[12:59] <diwic> ok
[12:59] <ogra_> diwic, sounds like to built a binary and not a source package
[12:59] <rbasak> git-buildpackage -S should give you a _source.changes.
[12:59] <rbasak> git-buildpackage takes all the same parameters that dpkg-buildpackage does.
[12:59] <diwic> rbasak, thanks
[12:59] <diwic> I'll try that
[12:59] <pitti> it's "gbp buildpackage" now, FTR
[12:59] <pitti> (has been for a few years, but in wily the git-* aliases got removed)
[13:00] <xnox> pitti: you mean $ dgit sbuild, right?!
[13:00] <xnox> =))))) </giggle>
[13:01] <diwic> pitti, gbp ? okay
[13:01] <kalxas> 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] <kalxas> https://launchpad.net/~gcpp-kalxas/+archive/ubuntu/ppa-tzotsos/+packages
[13:02] <diwic> thanks everyone
[13:02] <kalxas> I would really appreciate a hint on this problem. libxml 2.8.0 builds fine and finds Python.h in UbuntuGIS
[13:03] <kalxas> https://launchpad.net/~ubuntugis/+archive/ubuntu/ubuntugis-unstable/+sourcepub/2892970/+listing-archive-extra
[13:04] <barry> slangasek: no.  also, are you sure about that bug #?
[13:06] <cjwatson> 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] <kalxas> cjwatson, thanks!
[13:08] <kalxas> will try and report back
[13:53] <pitti> xnox: btw, did you see that Lennart reviewed your "runtime preset" patch a few weeks ago?
[13:56] <xnox> pitti: i did, but i didn't have time to reply yet. Busy with something else at the moment.
[13:57] <xnox> 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] <xnox> pitti: but need to test this first.
[13:57] <pitti> xnox: ack, just wanted to confirm that you saw it, as it took a while to get reviewed
[13:57] <xnox> yeah
[13:57] <xnox> we are using it in clearlinux.org, and it's alright. But we don't like that it delays boot =(
[13:58] <kalxas> cjwatson, thank you very much for your help! https://launchpad.net/~gcpp-kalxas/+archive/ubuntu/ppa-tzotsos/+build/7424658
[14:04] <slangasek> barry: yes, that's the bug number, see comment #1 :)
[14:05] <cjwatson> kalxas: great, you're welcome
[14:10] <pitti> xnox: delays because it has to read all units on startup, not just the enabled ones?
[14:10] <xnox> pitti: yes.
[14:11] <xnox> pitti: and it doesn't cache them....
[14:11] <xnox> pitti: speaking of which.....
[14:18] <smoser> hey. i'd appreciate someone reading https://bugs.launchpad.net/ubuntu/+source/curtin/+bug/1443542
[14:18] <smoser> input on my final comment (#4) would be appreciated.
[14:18] <smoser> basically i assume:
[14:18] <smoser>  a.) <some-partition-table-operation>
[14:18] <smoser>  b.) blockdev --rereadpt /that/block-device
[14:19] <smoser>  c.) udevadm settle
[14:19] <smoser> will guarantee that partitions created in 'a' will exist in /dev
[14:19] <ogra_> dont you need a "udevadm trigger" too ?
[14:20] <ogra_> or is rereadpt enough to trigger udev
[14:20] <smoser> well, it certainly *generally* is enough. to have allowed my assumption to get as far as it has.
[14:21] <smoser> 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] <smoser> er... sorry. above 'b' and then 'c' for my previous statement .
[14:22] <smoser> i guess that 'c' could read an empty queue if 'b' hadnt populated it.
[20:40] <flyinprogrammer> anybody know how/where i might find the scripts that make the squid debs ?
[20:40] <flyinprogrammer> oh maybe i should go to app-devel
[20:40] <flyinprogrammer> or packaging LOL i'm an idiot - sorry guys
[21:49] <hallyn> 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] <infinity> 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] <hallyn> 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] <infinity> 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] <hallyn> in a bug opened against lxcfs?
[21:53] <infinity> hallyn: Aye.
[21:53] <hallyn> infinity: thanks.  will post that in a bit
[22:06] <hallyn> 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] <hallyn> going by ff example i guess 0.9-0ubuntu0.15.04.1
[22:10] <infinity> 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] <infinity> hallyn: We tend to prefer the latter, but if packaging changes are equally important in this case, the former works.
[22:11] <hallyn> it can be a straight backport.
[22:11] <hallyn> oh, you *prefer* the latter?
[22:12] <hallyn> np, can do
[22:12] <hallyn> thakns
[22:12] <infinity> 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] <hallyn> cool
[22:14] <infinity> 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] <infinity> hallyn: Probably not actually true or meaningful in this case, but yeah.
[22:14] <infinity> 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] <hallyn> and, i should attach a debdiff, or point to new source?
[22:16] <infinity> 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] <hallyn> cool, thanks.
[22:19] <hallyn> posted bug 1454862, now leaving for the week (will check in tonight)
[22:23] <infinity> hallyn: Ta.  I'm out for the week too, but I'll open that in a tab and consider caring. ;)
[22:23] <hallyn> lol
[22:23] <hallyn> thanks i appreciate that :)
[23:32] <cyphermox> oops.
[23:32] <cyphermox> @pilot out