[01:25] <chrisccoulson> slangasek, regarding bug 894546, i've already asked that reporter not to do this once before already
[01:25] <chrisccoulson> seems he doesn't listen though :(
[01:26] <lifeless> erm wtf
[01:29] <wgrant> Lucky we have task deletion now :)
[01:30] <StevenK> Now we just need bug deletion
[01:59] <JanC> I wish he/she would file bug reports about missing manpages instead...   :P
[02:07] <dobey> ugh; man pages
[02:07] <dobey> and what a wonderful descript that bug has; a simple duplicate list of the things which it is filed as affecting
[02:30] <penguin_03> does ubuntu 10.04 obey the DEB_BUILD_HARDENING variable? In other worlds will it enable what http://wiki.debian.org/Hardening#Using_Hardening_Options says it does for debian?
[02:35] <dobey> penguin_03: if it works with debhelper 7, i would expect it would work on ubuntu 10.04
[02:36] <penguin_03> dobey, is there a obvious way to tell if its working or not?
[02:38] <dobey> penguin_03: build a package with it, and check the build log?
[02:38] <micahg> penguin_03: run hardening-check on the binary
[02:38] <dobey> and do that, as the wiki says :)
[02:41] <slangasek> chrisccoulson: ah, yuck
[05:41] <pitti> Good morning
[05:42] <pitti> tjaalton, cjwatson: pkgbinarymangler doesn't touch "copyright" either (symlink/compress)
[05:42] <pitti> that must be yet something else
[05:42] <pitti> tjaalton: 893826 is for everything _except_ copyright
[07:05] <ankit-tulsyan> Hi All, My name is Ankit. I have been using ubuntu for a while and  wanted to help out in squashing some bitsize bugs. I do have a programming background, but completely new in developing on ubuntu. I was wondering whether this is the right place to ask for help in trying to get started with this? If not, could it be possible for you to direct me to the right chat group?
[07:21] <ankit-tulsyan> Hi All, My name is Ankit. I have been using ubuntu for a while and  wanted to help out in squashing some bitsize bugs. I do have a programming background, but completely new in developing on ubuntu. I was wondering whether this is the right place to ask for help in trying to get started with this? If not, could it be possible for you to direct me to the right chat group?
[07:25] <pitti> ankit-tulsyan: in general this is the right place, indeed
[07:25] <pitti> ankit-tulsyan: thanks for your interest!
[07:27] <pitti> ankit-tulsyan: https://wiki.ubuntu.com/HelpingWithBugs might be a good page for you to start with
[07:27] <ankit-tulsyan> aah ok great. nope I have been using ubuntu for a while and been very appreciative of the work that has been done over the years..finally decided try and help out too and get my hands dirty ;)
[07:27] <pitti> ankit-tulsyan: it links to https://wiki.ubuntu.com/Bugs/HowToFix which describes the process how to do that
[07:27] <ankit-tulsyan> cool thanks
[07:28] <ankit-tulsyan> great thanks...
[07:28] <pitti> you're welcome, have fun!
[07:56] <dholbach> good morning
[09:33] <ogra_> cjwatson, hmm, Bug 893842 looks like there is an additional transition in order for dropping of the admin group
[09:34] <cjwatson> ogra_: I brought that up on ubuntu-release last night
[09:34] <ogra_> ah, i didnt read that yet :)
[09:35] <cjwatson> ogra_: er, I commented on the bug so you know I'm aware of it - what are you asking me?
[09:35] <ogra_> nothing, i just saw the recent comments ... sorry, probably i read them out of order
[09:35] <cjwatson> OK :)
[09:36] <cjwatson> as Martin says, there are probably a few places we've missed; I think it's worth doing it this way though, as it removes a long-standing divergence from Debian
[09:36] <cjwatson> stgraber: trying a fresh Edubuntu build now ...
[09:38] <pitti> cjwatson: I'm about to upload a new ubuntu-meta for the https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-default-apps stuff; is now a bad time?
[09:38] <pitti> cjwatson: oh, and good morning!
[09:39] <pitti> ogra_: BTW, I just saw that the ubuntu seeds had rhythmbox [armel] and banshee [!armel] all along, so that won't change much for you
[09:39] <ogra_> pitti, it will, since that change didnt drop banshee ... thanks to U1 rdeps
[09:40] <pitti> ah :)
[09:40] <ogra_> just drop all armel specifics there :)
[09:40] <pitti> yep, done
[09:40] <ogra_> thx
[09:40] <pitti> http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.precise/revision/1959
[09:41] <ogra_> pitti, on monday we need to talk about the tracker once again i fear (not all our specs are approved yet due to david traveling the whole week)
[09:41] <pitti> waiting with dput for cjwatson's yay or nay
[09:41] <pitti> ogra_: approved or not is not the issue, what's important for the trend lines is that the number of WIs don't change too much any more
[09:41] <cjwatson> pitti: go ahead
[09:41] <pitti> ogra_: but you can always adjust trend lines for individual milestones if you need to
[09:42] <pitti> ogra_: (it's in bzr, everyone in ~platform can commit)
[09:42] <ogra_> pitti, well, all unapproved ones dont show up on your page yet ... and i see specs we dont own at all
[09:42] <pitti> http://://bazaar.launchpad.net/~wi-tracker-configurators/launchpad-work-items-tracker/ubuntu-config
[09:42] <ogra_> s/your/our/
[09:42] <pitti> ogra_: they do; if they don't show up, they haven't been targetted to precise
[09:42] <pitti> or have a syntax error (missing "work items:"?) in the whiteboard
[09:42] <ogra_> oh, yeah, approval and atrgeting is the same thing in davids workflow :)
[09:42] <pitti> ogra_: the tracker doesn't take the status into account
[09:43] <ogra_> so not all show up yet
[10:22] <alexbligh> I am packaging something that puts libraries in /var/lib/foo/*.so*. I apparently need to add a file /etc/ld.so.conf.d/foo.conf containing the path /usr/lib/foo. Is there a 'proper' way to do this, or should I just install a normal file there from foo.install? IE can dh_makeshlibs etc. do this for me?
[10:23] <pitti> alexbligh: that looks utterly wrong; if they are private libraries that are loaded at runtime as plugins, they should go into /usr/lib/foo/*.so
[10:24] <pitti> alexbligh: and if they are "real" public libraries, they need to go into separate binary packages into /usr/lib/<arch>/
[10:25] <alexbligh> pitti, they are private libraries. It's actually the oneiric xen4 package being compiled on lucid. For some reason 'things to do not work' on lucid
[10:26] <alexbligh> well, actually, they aren't private libraries because our own stuff uses them, but they are written as private libraries, which is probably the issue.
[10:27] <alexbligh> e.g. libxen-dev package contains
[10:29] <alexbligh> apols
[10:29] <alexbligh> e.g. xen-utils contains
[10:29] <alexbligh> -rw-r--r-- root/root    142672 2011-11-23 12:17 ./usr/lib/xen-4.1/lib/libxenctrl.so
[10:31] <pitti> alexbligh: then adding them to ld.so.conf would be wrong, as that would make them public
[10:31] <pitti> alexbligh: the startup scripts could set LD_LIBRARY_PATH for that
[10:32] <pitti> alexbligh: but it's still wrong to put them into /var, they should be in /usr/lib/<pkgname>/
[10:32] <pitti> alexbligh: ./usr/lib/xen-4.1/lib/libxenctrl.so looks fine
[10:32] <alexbligh> I didn't suggest /var.
[10:32] <pitti> alexbligh | I am packaging something that puts libraries in /var/lib/foo/*.so*. [...]
[10:32] <alexbligh> libxenctrl.so is in effect a public library. You need it in order to build stuff that uses it
[10:33] <pitti> so if that was just a typo, ignore me :)
[10:33] <alexbligh> aaarggh s/var/usr/
[10:33] <infinity> alexbligh: Those are plugins, surely?
[10:33] <alexbligh> (sorry)
[10:33] <infinity> alexbligh: Nothing's actually linked against them...
[10:33] <alexbligh> We have a program which links against them.
[10:33] <pitti> alexbligh: it doesn't seem to have a SONAME, though, so it shouldn't be a public one
[10:33] <alexbligh> In another debian package
[10:33] <alexbligh> which you need to do in order to control xen programatically
[10:34] <alexbligh> but the package maintainer appears to have forgotten this.
[10:34] <infinity> alexbligh: Which package links againt it?  And which binary?
[10:35] <alexbligh> A proprietary package of ours (extility-xvpagent), but the same would be true of anything that links to xen using the modern xen API (I don't know if openstack have got that far yet)
[10:35] <alexbligh> (package maintainer has probably missed it because no one is doing it yet)
[10:35] <infinity> alexbligh: Err, but those pluginy things should be dlopen()ed, not linked at build-time.
[10:36] <alexbligh> what do you mean by "plugginy things". I don't think it's intended as a plugin. It's a straight shared library.
[10:37] <alexbligh> xen tools themselves are linked against it direct at build time.
[10:37] <alexbligh> (AFAIK)
[10:39] <infinity> adconrad@cthulhu:~$ ldd /usr/lib/xen-4.1/bin/xentop | grep xen-4.1 libxenctrl.so => /usr/lib/xen-4.1/bin/../lib/libxenctrl.so (0x00007fb3b737d000)
[10:39] <infinity> Indeed.
[10:39] <infinity> I smell rpath.
[10:40] <infinity> Which may have something to do with Xen's bizarre installation method.
[10:40] <alexbligh> infinity, no argument there!
[10:40] <alexbligh> I was trying to avoid our packaging hard coding the location
[10:41] <infinity> adconrad@cthulhu:~$ chrpath -l /usr/lib/xen-4.1/bin/xentop
[10:41] <infinity> /usr/lib/xen-4.1/bin/xentop: RPATH=${ORIGIN}/../lib
[10:41] <infinity> alexbligh: ^-- You probably want a similar RPATH setup in your packaging.
[10:41] <infinity> alexbligh: And to avoid hardcoding it, you can probably yank it at build-time from the current xen build-deps you have installed.
[10:42] <alexbligh> infinity, you would be assuming xen build deps actually work :-(
[10:42] <alexbligh> I am actually doing all this on lucid, so have my own package variants anyway.
[10:42] <infinity> Well, are you installing your stuff to /usr/lib/xen-4.1/bin?
[10:42] <alexbligh> No.
[10:43] <infinity> Despite the fact that they're Xenish binaries? :)
[10:43] <alexbligh> Because it's not xen stuff. It's our own agent, and we have version for (e.g) kvm too,
[10:43]  * infinity shrugs.
[10:43] <infinity> Fair enough.
[10:43] <infinity> But yeah, then you'll want an RPATH of /usr/lib/xen-4.1/lib
[10:43] <alexbligh> ok, so either rpath or bodge ld.so.conf.blah.
[10:43] <infinity> ld.so.conf is the wrong answer.
[10:43] <infinity> As it makes all those Xen libraries public to every binary on the system.
[10:44] <infinity> And there's no guarantees they won't collide.
[10:44] <ogra_> you could mount some bumpers :P
[10:44] <infinity> libflask.so and libfsimage.so, for instance, don't sound particularly namespace-friendly. :P
[10:45] <alexbligh> that's probably not an issue as it's an embedded system effectively, so we know what's on it, but yes it is horrible. The reason I am worrying about rpath is I think we currently override dh_shlibdeps and -X all the xen stuff simply because the build deps don't work properly.
[10:46] <infinity> I also wouldn't be shocked to discover that the rpath is necessary for the xen libs to load their own plugins.
[10:46] <alexbligh> (i.e. the -dev package contains neither all the headers necessary nor all the libraries)
[10:46] <infinity> But only one way to find out, I suppose. :P
[10:46] <alexbligh> oh it works fine with ld.so.conf bodged
[10:46] <alexbligh> I was just looking for an easy way to put it in the packaging.
[10:47] <alexbligh> (and there isn't one, because it shouldn't be there...)
[10:47] <infinity> In package.install works well enough.
[10:47] <alexbligh> ya
[10:47] <infinity> But I pray this package never sees the light of day outside your systems. ;)
[10:47] <infinity> Nothing personal. :P
[10:48] <alexbligh> Well hopefully someone will fix up xen-4.1 some time, then it should all build normally and we can take all this crap out.
[10:48] <infinity> (Futzing with the rpath seems like the correct fix, however, if you want to spend another 15 minutes fiddling)
[10:48] <infinity> I'm not sure xen needs "fixing" in this case.
[10:48] <infinity> Those libraries shouldn't be on the search path.
[10:48] <alexbligh> Is the fact that the -dev package does not contain all the necessary headers and libraries not a bug?
[10:50] <infinity> It has everything for xenctrl, xenguest and xenstore...
[10:50] <infinity> And, as an added bonus, has those three libraries as static libraries.
[10:50] <infinity> Which is probably the real solution.
[10:50] <infinity> Not rpaths and crazy dynamic linking.
[10:50] <alexbligh> (let me find what is missing)
[10:51] <infinity> It only allows you to dynamically link xenstore.
[10:51] <infinity> xenctrl and xenguest are static-only.
[10:52] <infinity> I suspect that's by design, not a bug.
[10:52] <infinity> Looking at how they work with the xen tools.
[10:52] <alexbligh> yup, and we static link xenctrl and xenguest, and dynamically link xen-store
[10:52] <infinity> With all their little plugins and other insanity.
[10:52] <infinity> Err, but if you statically link xenctrl, then you don't need to be loading the copy from /usr/lib/xen-4.1/lib
[10:53] <infinity> And my head just exploded.
[10:53] <alexbligh> So they miss libxlutil, libxenlight, and libblktabctl
[10:54] <infinity> I suspect those are meant to only be used internally.
[10:54] <infinity> Just as there are gcc stub libraries that don't ship on path or with headers, etc.
[10:55] <alexbligh> Our link line is:
[10:55] <alexbligh> -lxenlight -lxenctrl -lxenstore -lblktapctl -lxenguest -lxlutil
[10:55] <alexbligh> (non-xen stuff removed)
[10:55] <alexbligh> and that's pretty much the link line they use to build their own tools I think.
[10:55] <infinity> But... Does it actually have to be?
[10:56] <alexbligh> I believe that is the minimal link line to get things to compile, yes.
[10:56] <infinity> If you only include the top level xenguest.h and xenctrl.h, I can't see how you'd need to link all the private libs.
[10:56] <infinity> But alright.
[10:56] <infinity> You might be doing crazy things.  I'll concede that. :P
[10:56] <alexbligh> we do not only include xenguest.h and xenctrl.h
[10:56] <infinity> At which point, yes, the rpath would be the right way to go.
[10:56] <alexbligh> but we are not including private stuff.
[10:56] <infinity> And linking statically becomes pointless, cause you may as well pick up the other libs dynamically from the rpath too.
[10:57] <alexbligh> (i.e. the _priv headers)
[10:57] <infinity> Well, you did claim some headers were "missing".
[10:57] <infinity> That's often a sign that you're pulling private headers from the source. ;)
[10:57] <alexbligh> from the -dev package yes
[10:57] <alexbligh> it compiles fine if you build xen from source, do a make install, then build our stuff
[10:58] <infinity> Ahh, fair enough.
[10:58] <alexbligh> which makes me think that the package maintainer is not treating as much public as the xen folks do
[10:58] <alexbligh> (which is also fair enough in a way)
[10:58] <infinity> Well, please fil bugs on exactly what's wrong there, then.
[10:58] <alexbligh> yep, we should do that.
[10:59] <infinity> I won't deny that out xen packages haven't seen as much love over the last few years as I'd like.  Mostly just trying to get to the bottom of it all.
[11:00] <cjwatson> stgraber: hooray, you have Edubuntu images again
[11:00] <infinity> But yeah, for your quick-n-dirty "I promise I'm not giving this package to random people on the internet, just jamming it in an embedded device" use case, the ld.so.conf.d snippet works for now. :P
[11:00] <alexbligh> ./hypervisor/xen_libxl.c:#include <xentoollog.h>
[11:00] <alexbligh> ./hypervisor/xen_hypervisor.c:#include <xenctrl.h>		// Xen control
[11:00] <alexbligh> ./hypervisor/xen_hypervisor.c:#include <xs.h>			// Xen store
[11:00] <alexbligh> ./hypervisor/xen_hypervisor.c:#include <xenstat.h>		// Xen stat
[11:00] <alexbligh> ./hypervisor/xen_xl_internal.h:#include <libxl.h>
[11:01] <alexbligh> ^- that's all we include - public APIs only I think.
[11:01] <cjwatson> stgraber: your new ISO tracker seems to be down?
[11:06] <Daviey> cjwatson: Did you see that SpamapS shaved some size from wget-udeb?
[11:07] <cjwatson> I did
[11:08] <Daviey> rocking.
[11:09] <alexbligh> infinity, FWIW the problem is that  libxen-dev_4.1.1-2ubuntu4 does not contain ANY of the libxl (xenlight) API stuff, which is the recommend Xen 4.1 API. Will file a bug.
[11:10] <infinity> alexbligh: Please do.
[11:10] <infinity> alexbligh: And feel free to bug Daviey about it every day until it's fixed.  He loves that.
[11:11] <Daviey> alexbligh: Aww, sad - now it's at the bottom of the queue.. thank infinity for that :)
[11:13] <Laney> I'd appreciate knowing if https://launchpad.net/ubuntu/+source/haskell-vector/0.9-2/+build/2952098 builds quickly. Could someone rescore?
[11:14] <cjwatson> Laney: done
[11:15] <Laney> ta muchly
[11:15] <cjwatson> Daviey: I'll look into integrating that for the next d-i upload
[11:21] <alexbligh> Hmm, https://launchpad.net/ubuntu/+search?text=libxen-dev persistently gives an error. Is launchpad foobar'd?
[11:23] <infinity> alexbligh: https://launchpad.net/ubuntu/+source/xen
[11:23] <pitti> cjwatson: ntfs-3g> do you know what uses the "syncio" mount option? does anything still? certainly not in udisks
[11:23] <pitti> cjwatson: do some users have that in their fstab, from the installer?
[11:24] <Daviey> cjwatson: It's not actually blocking for us right now, but it will be in a few weeks when we look to try and default to providing preseed via ssl.
[11:25] <Daviey> So short term, no panic. ;)
[11:26] <cjwatson> pitti: it used to be set by wubi and there's no provision for transitioning it
[11:26] <cjwatson> it's no longer set by anything, that's why I marked it as compatibility :)
[11:27] <pitti> cjwatson: ah, it's not in a place where a postinst or some such could change "syncio" to "sync" in fstab?
[11:27] <pitti> thanks, I was just curious
[11:27] <alexbligh> infinity, Daviey : LP #894711
[11:30] <cjwatson> pitti: I think it was set as a kernel argument, and there's already enough stuff futzing with those :)
[11:31] <cjwatson> yeah, rootflags=syncio, and in the context of wubi I think it was pretty difficult to undo that
[12:04] <ogra_> pitti, hrm, i cant access the branch, seems canonical-arm isnt a member of canonical-ubuntu-platform or wi-tracker-configurators anymore
[12:13] <ev> pitti: regarding http://summit.ubuntu.com/uds-p/meeting/19445/desktop-p-dvd-image/ - 750MB is achievable on a CD with a 90min/800MB CD, no?  Just trying to understand why this needs to be a DVD.
[12:13] <ev> (context: working with John on the web team to help plan their changes to ubuntu.com/download)
[12:16] <cjwatson> the word I'd heard was that we probably wouldn't actually need that flexibility this cycle
[12:17] <cjwatson> so maybe don't commit to web changes just yet ...
[12:19] <pitti> ev: sure, I just don't know how widespread burners/readers for those are
[12:19] <pitti> ogra_: invited to join, you need to approve
[12:19] <ogra_> pitti, already fixed with michelle
[12:20] <ogra_> we're back in platform
[12:20] <ogra_> but thanks
[12:20] <pitti> ah, that way around
[12:20] <pitti> ogra_: so, please decline it the
[12:20] <pitti> n
[12:20] <pitti> I can't un-invite
[12:20] <ev> cjwatson, pitti: noted; thanks!
[12:20] <ogra_> yup, will do
[12:27] <JanC> I think most CD drives can read/write 800 MiB (and even larger capacity) CDs (unless something changed in recent years, but I never had issues back when I still used CD-Rs quite often...)
[12:28] <JanC> the thing that's trickier is that it's getting more & more difficult to find such CD-Rs  ;)
[12:29] <JanC> in the past you could buy them in "every" supermarket, now you probably need to go to a specialized shop...
[12:29] <bkerensa> Precise Pangolin is nice :D
[12:30] <ogra_> JanC, well, i bet there are countries in south america, asia and africa where you still cant buy them
[12:30] <ogra_> (that was one of the complaints that kept us from moving to 800MB in the past)
[12:31] <JanC> right
[12:31] <JanC> or if you can buy them there, it might be somewhere at the other side of the country, or whatever
[12:32] <ogra_> yeah
[12:33] <JanC> too bad USB sticks are still "expensive" compared to CD-Rs  ;)
[12:33] <ogra_> yup
[12:35] <nigelb> g29
[12:35] <nigelb> ugh
[12:35] <JanC> OTOH, we plan to order a bunch of USB sticks with our locoteam to replace at least part of the CD-Rs we distribute at events...
[12:51] <hrw> any opinions on bug 894732?
[12:53] <hrw> can someone confirm issue?
[14:19] <mdeslaur> chrisccoulson: I'll buy you a steak and a beer if you add indicator support to gnote :P
[14:20] <chrisccoulson> mdeslaur, i would like to renegotiate:
[14:20] <didrocks> chrisccoulson: do not forget ubuntuone syncing as well :)
[14:20] <chrisccoulson> how about, you buy me steak and beer and i don't add indicator support to gnote?
[14:20] <chrisccoulson> i think that's a better deal :)
[14:20] <mdeslaur> chrisccoulson: uh, not for me :)
[14:20] <chrisccoulson> lol
[14:20] <mdeslaur> chrisccoulson: a steak and _three_ beers?
[14:20] <didrocks> mdeslaur: i can use a steak and try to add this support, if I'm sure someone is doing the ubuntuone syncing side :)
[14:21] <chrisccoulson> is gnote even maintained?
[14:21] <mdeslaur> didrocks: I'll buy you a steak if you do it
[14:21] <didrocks> chrisccoulson: is tomboy really maintained? :)
[14:21]  * didrocks adds a tomoby note to add indicator support in gnote
[14:21] <chrisccoulson> lol
[14:22] <didrocks> and we all see that chrisccoulson agreed on the ubuntuone syncing support, so we are all set :)
[14:22] <chrisccoulson> heh
[14:22] <mdeslaur> didrocks: well, ubuntuone support is not required now that couchdb support is being dropped...
[14:23] <didrocks> mdeslaur: it wasn't using couchdb IIRC but another direct API
[14:23] <mdeslaur> oh? ah, cool, I wasn't aware of that
[14:26] <mdeslaur> chrisccoulson: so, if I understand your criteria, "maintained" means "Does the mozilla foundation work on it". Is that accurate?
[15:32] <mdeslaur> heh, empathy popped up a window, and unity thinks it's gimp. Added a gimp icon to the launcher for it.
[15:35] <ogra_> thats surely the newly added graphics editing functions of empathy :P
[15:35] <SpamapS> mdeslaur: new feature of empathy.. shared drawing space
[15:35]  * SpamapS eyes ogra_ suspiciously.. 
[15:35] <ogra_> heh
[15:35] <SpamapS> do I have to start wearing my tinfoil hat again?
[15:35] <ogra_> to late, i got everything on disk already
[15:35]  * ogra_ pulled a full backup
[15:36] <SpamapS> Hm, ok.. so.. mysql-server is now in two places.. main and universe.. since 5.1 is in main and 5.5 has not been promoted yet.
[15:37]  * SpamapS encrypts the entire contents of his brain with the WHISKEY-89 algorithm
[15:37] <ogra_> *slurp*
[15:37] <SpamapS> damn... one way algorithm.. oh well..
[15:38] <mdeslaur> hehe
[15:39] <cjwatson> Daviey: so, um - how is wget in d-i going to verify SSL certificates?
[15:39] <SpamapS> anyway, seems we need to drop the 5.1 mysql-server as right now apt decides its better to remove it than upgrade it to 5.5's version
[15:40] <cjwatson> SpamapS: actually, mysql-server-5.5 is in main
[15:40] <SpamapS> cjwatson: any ideas? ^^
[15:40] <SpamapS> Oh
[15:40] <cjwatson> SpamapS: I've demoted mysql-server-5.1
[15:40] <cjwatson> SpamapS: I doubt that will help with universe builds, though
[15:41] <SpamapS> I see two mysql-server packages apt-cache show right now
[15:41] <SpamapS> oh wait, one is installed
[15:41] <cjwatson> yeah, but that should be fine
[15:43] <cjwatson> Daviey: I'm really not keen on pulling ca-certificates into d-i - size aside, it would mean that we'd have to worry about security updates of d-i a lot more
[15:43] <Daviey> cjwatson: right, i was wondering - could we preseed a cert fingerprint?
[15:43] <cjwatson> Daviey: I suspect a lot of the use cases for this will be self-signed anyway, where HTTPS is just being used to prevent people tcpdumping for passwords.  Do you think we can just use --no-check-certificate and be done with it?
[15:43] <Daviey> Considering /most/ IMO will use self-signed.
[15:44] <Daviey> hah
[15:44] <Daviey> Hmm, chicken -> egg.
[15:44] <mdeslaur> cjwatson, Daviey: what are you talking about?
[15:44] <Daviey> mdeslaur: d-i support for ssl..
[15:44] <Daviey> grabbing preseeds via https.
[15:44] <SpamapS> cjwatson: dist-upgrade wants to remove mysql-server ... presumably because mysql-common 5.5.17-4ubuntu5 breaks mysql-server-5.1 ..
[15:45] <SpamapS> cjwatson: https://jenkins.qa.ubuntu.com/job/precise-upgrade/PROFILE=server-tasks-amd64,label=upgrade-test/lastBuild/artifact/server-tasks-amd64/apt.log
[15:45] <SpamapS>   Removing mysql-server:amd64 rather than change mysql-server-5.5:amd64
[15:45] <SpamapS> I don't understand why its doing that
[15:46] <cjwatson> let's think pretty carefully before permuting packages to try to solve it :)
[15:48] <SpamapS> I can remove the Breaks: line from mysql-common.. I think that will actually solve the problem.. but not in a way I fully understand.
[15:49] <SpamapS> I added it because the new mysql-common will cause mysqld and the mysql cmdline client to abort.
[15:50] <cjwatson> it's possible that adding "Breaks: mysql-server-core-5.1" would help
[15:50] <cjwatson> (likewise client)
[15:50] <cjwatson> this is just gut instinct though rather than a hard analysis
[15:51]  * SpamapS ponders how to test that without uploading..
[15:51] <SpamapS> reprepro maybe? :-P
[15:51] <cjwatson> it sort of makes sense though; mysql-server-core-5.5 Breaks mysql-server-core-5.1 and it prefers to hold back mysql-server-core-5.5, so pruning from the bottom of the dep tree rather than the top seems to make sene  
[15:51] <cjwatson> *sense
[15:52] <cjwatson> yes, if you can construct a chroot that exhibits that problem then you should be able to add another repository to it
[15:52]  * SpamapS is on it
[15:53] <Daviey> mdeslaur: Do you have any suggestions for the miminal requirements to validate an ssl certificate.  We can't validate based on fingerprint, can we?  We need the ca-cert on the local machine?
[15:54] <mdeslaur> Daviey: you need ca-cert on the local machine, but you need to be able to update that. If that can't be updated properly, you might as well not check certs, and properly document that certs are not checked.
[15:54] <mdeslaur> Daviey: is this just to hide the passwords that are in the preseed file?
[15:55] <Daviey> mdeslaur: So the local machine is a volatile enviroment (d-i).. so the problem is getting ther ca-cert to the machine, i don't imagine it fits on the kernel command line :)
[15:55] <Daviey> mdeslaur: Yes
[15:55] <SpamapS> I think there's a need to verify the identity of the cobbler server too
[15:55] <cjwatson> AFAIK it's just for hiding passwords
[15:55] <SpamapS> But it does sound more difficult. :-P
[15:55] <cjwatson> can I suggest that maybe verifying the identity should be done in some simpler way than pulling ca-certificates into d-i
[15:56] <mdeslaur> Daviey, cjwatson: in that case, I would much rather see the preseed file gain a way to specify a ssh public key
[15:56] <Daviey> It also provides 'some' assurance that it is /the/ correct server :)
[15:56] <mdeslaur> (if it's not already possible)
[15:56] <cjwatson> mdeslaur: uh, you need some kind of login credential ...
[15:56] <soren> Does pulling ca-certificates really provide any more confidence?
[15:56] <Daviey> mdeslaur: then setup an ssh tunnel?
[15:56]  * Daviey runs
[15:56] <soren> a) People are likely to use self-signed certs.
[15:56] <Daviey> soren: we discussed that :L)
[15:57] <soren> There's a b), too.
[15:57] <soren> Wait for it :)
[15:57] <SpamapS> Daviey: to that end.. PXE booting is usually reserved for private provisioning networks for this reason
[15:57] <cjwatson> mdeslaur: the preseed entries in question are things like the crypted password for the first user
[15:57] <cjwatson> (which can ALREADY be crypted but apparently some compliance processes pointlessly mandate HTTPS)
[15:57] <mdeslaur> no, I'm talking about giving an ssh public key as the initial user's login credential, instead of a password
[15:57] <cjwatson> I think that's a wildly separate issue
[15:58] <Daviey> ahh, that can be done with a late entry, right?
[15:58] <soren> b) Even if not, if people can hijack the connection to fetch the preseed, aren't they likely to be able to send a forged initrd (with a forged ca-certificates) in it?
[15:58] <cjwatson> and really rather considerably more complicated
[15:58] <cjwatson> sure, you can do that with a preseed/late_command
[15:58] <cjwatson> this doesn't solve the question of what to do with the wget command line used in the HTTPS case
[15:58] <Daviey> soren: right, but i'd like to try to provide some assurance.
[15:59] <cjwatson> easily broken assurance is worth nothing
[15:59] <cjwatson> I honestly think this is a fig leaf at best
[15:59] <Daviey> Well i agree it's worth less.. but we should start somewhere, rather than just not starting it?
[15:59] <mdeslaur> definitely, we shouldn't be encouraging non-secure use of https
[15:59]  * soren concurs
[16:00] <cjwatson> I'm not arguing against putting https support in the installer as a compliance fig leaf; I'm arguing against making use of it in anything we care about ourselves
[16:00] <SpamapS> better to encourage the provisioning network be separate from production than to imply you can provide assurances for the installer.
[16:00] <cjwatson> IMO a compliance fig leaf can just use --no-check-certificate because I think it's just to defeat snooping
[16:00] <Daviey> Hmm
[16:00] <cjwatson> people with stricter requirements can customise the installer initrd to add a certificate
[16:00] <Daviey> Then i could arp posion, MITM, and steal the creds regardless.
[16:01] <Daviey> True
[16:01] <soren> If you can do that, you can give the host a forged initrd as well.
[16:01] <cjwatson> this is turning from "please add wget" into a serious spec ...
[16:01] <soren> And if you can give a forged initrd, you can give a forged ca-certificates.
[16:01] <soren> etc.
[16:01] <mdeslaur> soren: yep
[16:02] <pitti> Riddell: thanks for the userconfig fix; does that also take care of recognizing "admin" group members as administrators, or now just "sudo"ers?
[16:02] <soren> In summary, if you can't trust the network you're passing the installer over, you're screwed.
[16:03] <Riddell> pitti: just sudo I think, it'll list "admin" as just another group without comment
[16:03] <SpamapS> PXE is effectively physical access.
[16:03] <soren> Yup.
[16:03] <cjwatson> Riddell: it needs to handle both; there's been no provision for migrating admin members to sudo
[16:03] <Daviey> cjwatson: If someone wanted to add the distro ca-certificates as a customisation, what would it involved?
[16:03] <pitti> Riddell: ah, the GNOME equivalent shows a list of users with "user" or "administrator", so there I had to make it recognize both
[16:03] <Daviey> As in, not done at distro level, but end user
[16:03] <soren> PXE is the easiest to forge, ironically.
[16:03] <cjwatson> Daviey: make an /etc/ssl/certs/, cpio and gzip, cat to end of installer initrd
[16:04] <soren> All communication is over UDP, isn't it? Or am I confused?
[16:04] <Daviey> Just re-roll the initrd including them?
[16:04] <Daviey> right
[16:04] <mdeslaur> soren: it's tftp, so yes
[16:04] <soren> That's what I thought.
[16:04] <soren> So you don't even have to mitm to inject a poisoned initrd.
[16:04]  * OdyX points that win32-loader does all the needed checking for trusted download of the debian-installer (gpgv with embedded debian-archive-keyring, md5sums, sha1sum)
[16:04] <soren> Yo ujust need to be fast.
[16:04] <cjwatson> the bug for this was bug 833994
[16:04] <Daviey> cjwatson: Okay, a kernel command line argument of "ssl-check=true" (default to false?)... Does that sound reasonable?
[16:05] <cjwatson> OdyX: which is fine as long as you have some trusted local thing to start with.  you can't do it securely when just pxe-booting
[16:05] <cjwatson> the bug starts with "As part of a PCI Compliance process we need to ensure that confidential information is passed in a secure way. Currently one can pxeboot machines and the root password travels encrypted with MD5 which nowadays is breakable and it is not part of the PCI Recommendations as follow below:"
[16:05] <OdyX> cjwatson: sure. And you have to trust win32-loader.exe. :->
[16:05] <cjwatson> which leads me to believe that these alleged compliance recommendations are quite happy with PXE booting but not with HTTP
[16:05] <cjwatson> which implies that they were written by a committee and confer no security
[16:06] <Daviey> That is because those validating don't understand PXE, possibly. :)
[16:06] <soren> cjwatson: It actually claims that it can fetch the kernel and initrd over https.
[16:06] <Daviey> you can.
[16:06] <soren> cjwatson: ...but I'll bet the thing that does that is fetched over tftp itself.
[16:06] <soren> So => fail.
[16:07] <mdeslaur> to achieve PCI compliance, he should simply be installing servers from a separate network
[16:07] <mdeslaur> cjwatson: you can specify the preseeded passwords already hashed?
[16:07] <cjwatson> mdeslaur: yep
[16:07] <mdeslaur> cjwatson: problem solved
[16:07] <cjwatson> although it is md5 crypt
[16:07] <soren> He points to md5 being the specific problem. What if they were passed as SHA512?
[16:07] <pitti> stgraber: http://91.189.93.73/qatracker/reports/defects -> oops
[16:07] <soren> That should be "fine".
[16:08] <soren> (as in "compliant", not as in "secure")
[16:08] <cjwatson> let me check whether that's actually hardcoded
[16:08] <soren> Certainly that'd be an easier problem to solve than any of the other things we've discussed :)
[16:08] <mdeslaur> if not, we should simply fix that so he can specify it as SHA512
[16:08] <cjwatson> it's just written straight to the password file.  I rather suspect that SHA512 will work fine
[16:08] <soren> Win.
[16:08] <Daviey> Note, that passwd isn't the only credential.
[16:09] <cjwatson> well, passed to usermod --password=
[16:09] <soren> Daviey: If it's the only credential his compliance doc cares about...
[16:09] <soren> I forgot how much I hate this compliance nonsense.
[16:10] <stgraber> pitti: that's jibel's fault ;) he's aware of it and should be fixed soonish. The report doesn't like having multiple active milestones
[16:10] <SpamapS> Why is there even a password allowed. ;-)
[16:10] <Daviey> soren: It's not only that bug that this is addressing. :)
[16:11] <soren> So, on Amazon S3, you can configure a bucket to encrypted. This means that Amazon will encrypt the contents for you on disk. Whenyou retrieve it, it's decrypted before you see it.
[16:11] <cjwatson> there are ways to arrange security that don't involve SSL, you know :-)
[16:11] <soren> Or so they say.
[16:11] <soren> I'm sure it fulfills some compliance requirements, but boy is it stupid.
[16:11]  * mdeslaur is so glad he's not a PCI compliance officer anymore
[16:12] <jibel> pitti, that's because there are different releases opened for testing, which shouldn't happen since there is only one development release.
[16:12] <jibel> I'll fix that
[16:12] <SpamapS> soren: you have to use S4 to be sure.
[16:12] <soren> SpamapS: I love S4.
[16:13] <soren> SpamapS: WEll, except that it doesn't work last I checked.
[16:13] <SpamapS> www.supersimplestorageservice.com
[16:13] <soren> SpamapS: It's a lovely idea. It's web scale.
[16:13] <SpamapS> the most secure storage platform ever... write-only :)
[16:14] <soren> I guess it might just be my SOAP skills that failed me when I tried it out.
[16:15] <soren> Or maybe the fixed it. It's been quite a while.
[16:15] <soren> *they
[16:16] <SpamapS> soren: whether it works or not, it works the same. :)
[16:17] <soren> SpamapS: Hey, if I'm a paying customer, it should at least *claim* that it has accepted my data and has... er... handled it.
[16:20] <SpamapS> if you're a paying customer of s4, I have some beachfront property for you in Arizona.. :)
[16:20] <soren> No comment.
[16:27] <pitti> stgraber: is there a documentation or the source code for the new tracker? we should rewrite publish-image-set.py for the new one
[16:27] <pitti> stgraber: and that probably should stop screenscraping, and use the API
[16:28] <stgraber> pitti: source code is at: lp:~ubuntu-qa-website-devel/ubuntu-qa-website/drupal7-rewrite/
[16:28] <cjwatson> pitti: there's already a new module in ubuntu-archive-tools for it
[16:28] <cjwatson> publish-image-set should be updated, yes
[16:29] <stgraber> pitti: the isotracker_xmlrpc.py module in ubuntu-archive-tools will just need to be extended to also fetch results, then publish-image-set can use it
[16:29] <cjwatson> 'import isotracker_xmlrpc as isotracker' and work from there; see head comments in isotracker_xmlrpc
[16:29] <pitti> cjwatson: sweet
[16:29] <cjwatson> we're using that for posting images
[16:30] <stgraber> pitti: I guess you'd need a new builds.get_list() call in the API to fetch the list of builds for a given milestoneid and status
[16:30] <stgraber> status = 0 meaning that it's currently on the tracker and not marked as disabled
[16:30] <stgraber> not sure if you also need to check the testcase coverage of the builds (not familiar with the publish script)
[16:31] <pitti> cjwatson: I see that I signed up for release engineering alpha-1, so I guess I'll have a stab at this on Mon/Tue
[16:31] <cjwatson> cool; you should have plenty of time since basically all the images are building cleanly ;-)
[16:32] <pitti> I was just going to say :)
[16:32] <pitti> some more months and we don't need REs any more
[16:32] <cjwatson> mythbuntu is the only straggler and I gather that Daviey has just uploaded a fix for that
[16:32] <ogra_> we'll all be jobless in two releases !!!
[16:32] <pitti> ah, for the mysql 5.1 vs. 5.5 battle
[16:32] <pitti> ogra_: more time to create bugs!
[16:32] <ogra_> indeed
[16:33] <ogra_> and we could hire new people to fix them !
[16:33] <Daviey> cjwatson: I may not have, but leave it with me - i'll check in a bit.. it's on me
[16:34]  * cjwatson nods
[16:35] <cjwatson> out of the CD health checks, AFAIK the only outstanding issue is size, and at least for Ubuntu that may well have been fixed today
[16:35] <pitti> yeah, with dropping mono
[16:35] <cjwatson> so it's just bugs
[16:35] <pitti> also, a tad of oversizedness is generally acceptable for A1, It hink
[16:35]  * pitti kicks that space
[16:36]  * Daviey stretches his legs
[16:38] <pitti> cjwatson: although, for some reason i386 grew to 709 MB today; /me checks
[16:38] <cjwatson> pitti: oversizedness> yeah
[16:39] <pitti> ah, older daily ISOs have gone, can't compare; well, will compare with oneiric then
[16:39] <cjwatson> you might be able to scrape info out of the build logs though
[16:39] <cjwatson> that's one reason I keep so much detail in them
[16:39] <pitti> *nod*
[16:47] <pitti> jibel: I have some trouble figuring out what actually went wrong on https://jenkins.qa.ubuntu.com/view/Precise/job/precise-desktop-i386_default/148/ (it's marked as failed)
[16:47] <pitti> d-i.syslog is empty (and that's ubiquity, so not totally unsurprising)
[16:47] <pitti> is there an ubiquity syslog somewhere?
[16:47] <pitti> or did it even fail to boot/start the live sesssion?
[16:47] <jibel> pitti, this is bug 894768,
[16:48] <cjwatson> incidentally, any ideas on that, don't be shy
[16:48] <jibel> pitti, the system doesn't install, if I run it again it passes
[16:48] <pitti> jibel: does that crash appear somewhere in the artifacts?
[16:49] <jibel> pitti, no, that's a problem with the framework I need to fix.
[16:50] <jibel> syslog is not redirected as it should be
[16:57] <pitti> cjwatson: on that actual bug, erk; would it be possible to add some logging how many blocks it already wrote? i. e. whether it fails in the middle or at the first block? that might give a hint which of teh EINVAL cases in write(2) applies here
[16:58] <pitti> it does smell like a kvm/qcow2 issue, not that this would make it any easier
[16:58] <pitti> cjwatson: or whether it fails on teh last block which isn't a full 16 KiB
[16:59] <SpamapS> cjwatson: seems your hunch was correct.. needed to break the -core- packages as well
[17:00] <pitti> jibel: would it be possible to get dmesg output after this happens? adding that to jenkins might generally be a good idea
[17:00] <pitti> jibel: it might show an error on sda/xda which coincides with this
[17:00] <cjwatson> SpamapS: ah, good
[17:01] <cjwatson> pitti: yeah, I'll see if I can reproduce it locally and then instrument; I'd rather not instrument everything
[17:01] <cjwatson> I don't think O_DIRECT is involved
[17:02] <pitti> not in the code, anyway
[17:02] <jibel> pitti, when it happened I connected to the VM and haven't found any error on /dev/sda
[17:03] <pitti> jibel: in dmesg or with fsck?
[17:03] <jibel> pitti, dmesg
[17:03] <pitti> jibel: thanks, that's an interesting data point
[17:12] <pitti> cjwatson, skaet: oh, 7 MB of oversizedness are due to LibreOffice needing a rebuild, and thus holding the old libicu44 on the CDs; so that will also go away
[17:12] <pitti> won't happen for a1, though
[17:12] <cjwatson> pitti: can we get that for alpha-1?
[17:12] <cjwatson> awwwww
[17:12]  * pitti asks Sweetshark
[17:12] <cjwatson> there are at least two other NBS libraries it's holding in place
[17:13] <pitti> I thought I overheard a conversation of uploading first 3.5 beta around December 5 or so
[17:13] <cjwatson> we should rebuild 3.4
[17:13] <cjwatson> IMO
[17:13] <pitti> asking in #u-desktop
[17:13] <cjwatson> I wouldn't do it for every single NBS library, but we've accumulated several now
[17:13] <ogra_> just let me know early enough so i can worst case mangle the seeds on arm if it ftbfs
[17:16] <pitti> good night everyone!
[17:17] <jibel> pitti, cjwatson I found also an "invalid argument" error in an alternate run yesterday, don't know if there's a link
[17:17] <jibel> Nov 24 10:01:11 in-target: dpkg: error processing /media/cdrom//pool/main/p/perl/perl-modules_5.14.2-5_all.deb (--unpack):
[17:17] <jibel> Nov 24 10:01:11 in-target:  failed in write on buffer copy for backend dpkg-deb during `./usr/share/perl/5.14.2/IO/Uncompress/Base.pm': Invalid argument
[17:17] <jibel> Nov 24 10:01:11 in-target: dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
[17:17] <pitti> it sounds likely anyway; both sound like invoking write()
[17:19]  * pitti waves good bye for real
[17:24] <cjwatson> jibel: if both ubiquity and dpkg see it, it seems improbable that it's anything but a kernel bug
[17:24] <cjwatson> well, or possibly libc I suppose
[17:24] <cjwatson> there's nothing else in common
[17:25] <jibel> cjwatson, or kvm ?
[17:27] <cjwatson> jibel: maybe; try with oneiric kvm?
[17:27] <cjwatson> or an oneiric image, if you're already using oneiric kvm
[17:27] <cjwatson> something to act as a differential
[18:22] <cjwatson> apw et al: I'm going to process linux 3.2.0-2.4 through NEW early (i.e. before armel finishes building) because I want to be able to upload d-i at a vaguely reasonable time for me
[18:22] <cjwatson> this will mean promoting crda and wireless-regdb in advance of wireless-crda being demotable (it's just a swap for the Debian packaging)
[18:22] <cjwatson> I promise to remember about this and demote wireless-crda ASAP next week
[18:23] <cjwatson> this will also mean d-i temporarily failing to build on armel
[18:23] <cjwatson> I'm hoping that won't be a big deal
[18:24] <alexbligh1> If I have a single source package that produces 2 binary packages, how do I make them each use a different debian/rules file?
[18:25] <cjwatson> you can't
[18:25] <cjwatson> debian/rules must deal with both
[18:25] <alexbligh1> cjwatson, ok :-), how does the target get passed in then?
[18:25] <cjwatson> (I mean, it can include other Makefiles if it likes, but that's only usually necessary for the very largest and most complicated packages, not for two binary packages; it must be the entry point)
[18:25] <cjwatson> it doesn't :-)
[18:26] <alexbligh1> hmm, so it only runs it once for each source package, not once for each binary...
[18:26] <cjwatson> it gets told 'build' (non-root stuff), then it gets told 'binary' (assembling the .deb, usually under fakeroot)
[18:26] <cjwatson> if you don't know the details, you should use /usr/share/doc/debhelper/examples/rules.tiny rather than trying to craft it yourself
[18:27] <alexbligh1> ok, let's put this question another way :-)
[18:27] <cjwatson> see 'man dh' for details on customising that
[18:28] <alexbligh1> I have a package building fine at the moment using a completely minimal rules file (xen-3.3.1 fwiw). I want to put two files it generates in a different package from all the rest (literally just 2 files) - these are the hypervisor boot files. What's the easiest way to do that?
[18:28] <cjwatson> debian/BINARYPACKAGENAME.install for each binary package listing what goes in each
[18:29] <cjwatson> the path of least resistance is to list everything that goes into both packages separately, but you can list directories, so that's usually not particularly hard work
[18:29] <cjwatson> (there are other ways; this is usually the simplest though)
[18:30] <cjwatson> though, in cases such as xen where there's already a package in the archive, I find it surprising that you wouldn't start from the existing package?
[18:30] <alexbligh1> ahh, I think I am beginning to understand. Could I also put an override target in for dh_install which did a -X for one package?
[18:30] <cjwatson> yes
[18:30] <cjwatson> override_dh_install:
[18:30] <cjwatson>         dh_install -Ntheunusualpackage
[18:30] <cjwatson>         dh_install -ptheunusualpackage -Xblah
[18:31] <cjwatson> or possibly the reverse.  something like that
[18:31] <Daviey> alexbligh1: What bug are you fixing?
[18:31] <alexbligh1> there isn't a xen package is there? I thought the last one in ubuntu was 3.2 or something, then a big gap, then xen4
[18:31] <cjwatson> https://launchpad.net/ubuntu/+source/xen-3.3/+publishinghistory
[18:31] <alexbligh1> Daviey, the nonexistence of a xen-3.3.2 package
[18:31] <Daviey> alexbligh1: have a bug number?
[18:31] <cjwatson> it would be much better to take the last version in the archive and update it, rather than doing it all from scratch and reinventing package bugs
[18:32] <cjwatson> *packaging bugs
[18:32] <alexbligh1> nope
[18:32] <alexbligh1> Sorry, that was Daviey, nope
[18:33] <alexbligh1> cjwatson, yep, I could look at that. We've made some patches to xen-3.3.2 to unbreak the networking interface through xend, which have changed the API, so tbh it probably doesn't have general applicability, but yes you are probably right that xen-3.3.0 packages would have been a good place to start.
[18:34] <cjwatson> apw: do you folks have a plan for when to update linux-meta?
[18:34] <infinity> @pilot in
[18:34] <alexbligh1> Daviey, out of interest, would you be interested in a "proper" xen-3.3.2 package?
[18:35] <Daviey> alexbligh1: Hmm.  Out of interest, what is wrong with xen4?
[18:36] <alexbligh1> Daviey, the main problem is lack of a modern xenlinux dom0 kernel package, and I have an Ubuntu Natty kernel with xenlinux package based on Stefano Stab's patches
[18:36] <alexbligh1> (sorry that was re xen3)
[18:36] <cjwatson> apw: accepted now
[18:36] <alexbligh1> the problem with xen4 is that piles of guest images are incompatible with it due to its different treatment of pv drivers.
[18:37] <Daviey> alexbligh1: I personally wouldn't push for a real backport of this, the ongoing support would likely be lacking, and i fear it would give people a false sense of support :/
[18:38] <Daviey> Oh wait.
[18:38] <alexbligh1> Daviey, we have images that will boot on xen3 but not on xen4. The main issue is that if you configure xen4 to support PV drivers, then any modern linux will unplug the normal disk drivers using the pic unplug stuff, but if the image doesn't happen to contain pv drivers suitable for xen4, then it will fail to boot. That, plus device renames etc. makes for a really bumpy upgrade.
[18:39] <Daviey> alexbligh1: You want to fix an issue of missing files in natty xen?
[18:39] <alexbligh1> Daviey, I think Citrix will continue to support xen3 for a while yet as cloud.com have not even launched xen4 support, and their own use for Citrix stuff is very new.
[18:39] <alexbligh1> Daviey, there is no Xen in Natty is there? I thought Oneiric was the first xen4. My missing files bug was xen4
[18:40] <alexbligh1> Daviey, (we support both - sorry for the confusion!)
[18:40] <Daviey> alexbligh1: There IS xen in natty, but only a source package :)
[18:40] <Daviey> It failed to build, and nobody quite got it fixed
[18:40] <Daviey> https://launchpad.net/ubuntu/natty/+source/xen-3.3/3.3.0-1ubuntu14
[18:41] <alexbligh1> Daviey, and we run on Lucid, but for reasons too boring to explain, we need a newer kernel, and chose the Natty kernel for xen3 as the patches aren't around to do xenlinux on kernel 3.x.
[18:42] <alexbligh1> Daviey, hmmm - perhaps using the 3.3.0 debian packaging files would NOT be a good idea then!
[18:42] <Daviey> alexbligh1: Can you raise some bugs which address the issues you are trying to resolve.  I've got one, a few files missing?.. but it's kinda getting confusing.
[18:42] <cjwatson> fixing the build failure would still be easier than starting from scratch
[18:43] <alexbligh1> oh I have it all built and it works fine, it's just we want it in 2 packages.
[18:43] <cjwatson> especially since it's a build failure in upstream code anyway, AFAICS (well, unless it's patched, but patches are easily amended)
[18:43] <alexbligh1> Daviey, I raised bugs for all the xen4 stuff you asked me to.
[18:43] <Daviey> alexbligh1: Yeah, it's really not safe for us just to throw different packages into the archive and say 'it works'.. we strive for the smallest patches possible, to the current packages
[18:44] <alexbligh1> LP #894711
[18:44] <Daviey> ah neat
[18:44] <alexbligh1> LP #894713
[18:44] <alexbligh1> (latter has a patch too :-) )
[18:45] <alexbligh1> Yeah, I sort of figured you'd be unwilling to take xen3.3 in any meaningful way into Ubuntu as to use it you need a xenlinux kernel, and there are no xenlinux kernels (to my knowledge) for the kernel versions you are targetting in Oneiric and Precise.
[18:46] <alexbligh1> (hence I just hacked a package up for myself)
[18:46] <alexbligh1> So I've only been filing xen4 problems.
[18:46] <Daviey> alexbligh1: It does still make sense to try to base it from an archive package.  Sorry it seems like we can't do more...
[18:47] <alexbligh1> Daviey, no problem at all
[18:47] <Daviey> I would suggest putting it into a PPA tho :).. but not even sure you'll be able to build that..
[18:47] <alexbligh1> Daviey, the main Xen problem we have is that no known Ubuntu operating system will boot as a Xen4 guest
[18:47] <alexbligh1> (well, none since something really really ancient - pre lucid)
[18:48] <Daviey> err, really?
[18:48] <Daviey> smb: You managed to boot ubuntu on xen4, right?
[18:48] <alexbligh1> yep, one of the modules is missing from the udeb. Let me find you the bug number.
[18:48] <Daviey> (he might be afk)
[18:48] <alexbligh1> smb agrees.
[18:49] <Daviey> alexbligh1: IIRC, I did an upload last cycle which added two kernel modules, and that seemed to be enough
[18:49] <cjwatson> there was a problem with blkfront/netfront not being loaded properly, but that was fixed
[18:50] <alexbligh1> I thnk it's pasically 804219
[18:50] <alexbligh1> LP #804219
[18:50] <alexbligh1> xen-platform-pci is missing from the udeb
[18:51] <alexbligh1> it should really be build with CONFIG_XEN_PLATFORM_PCI=y not CONFIG_XEN_PLATFORM_PCI=m
[18:51] <Daviey> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/804219/comments/15 , natty?
[18:51] <alexbligh1> So modern kernels unplug the sda device, then can't communicate with the xvda device as they have no platform PCI
[18:51] <alexbligh1> Oneiric too
[18:51] <alexbligh1> I think we filed another one, let me see...
[18:55] <alexbligh1> Problem only occurs on HVM guests, which is probably why you haven't found it
[19:02] <alexbligh1> Daviey, the problem with running Ubuntu-anything on HVM Xen4 is LP #886521
[19:04] <Daviey> alexbligh1: I'd quite like to talk this over with smb on Monday, are you going to be around (euro day) to join in?
[19:05] <alexbligh1> Daviey, possibly second half of afternoon. I have a "meeting of indeterminate length" AM (yippee)
[19:08] <Daviey> hurray!
[19:43] <mterry> jdstrand, heyo, archive-day-person.  :)  Could I impose upon you to NEW ruby-flexmock and drop libflexmock-ruby?
[19:43] <mterry> jdstrand, I filed a bug for the latter... let me dig it up
[19:43] <mterry> bug 896354
[19:50] <cjwatson> mterry,jdstrand: I've processed that through binary NEW; that needs to publish before removal, though
[19:50] <mterry> cjwatson, oh thanks
[20:39] <hallyn> Question on how to stage a package change.  Right now, kvm-pxe is provided by etherboot.  We want to switch it to being provided by ipxe.  Is it good enough to upload them at the same time, but etherboot first?  Or is there a better way to go about that without risking conflicts on dist-upgrade?
[20:40] <soren> Are you moving the files to a difference package or are you going to just build the same binary package from a different source package?
[20:41] <hallyn> soren: the latter
[20:41] <soren> What are the versions of the two source packages?
[20:42] <soren> AT any rate, you won't have problems on dist-upgrade.
[20:42] <soren> At that point, it doesn't matter which source package the binary package comes from.
[20:43] <hallyn> soren: hm, etherboot was 5.4.4-7ubuntu3, ipxe is at 1.0.0+git-2.149b50-1ubuntu2
[20:43] <soren> That's going to be a problem.
[20:43] <hallyn> yeah.  hadn't thought of that.
[20:43] <soren> By default, binary packages will have the same version as the source. They don't strictly have to, though.
[20:43] <hallyn> i suppose i could just call it 'kvm-ipxe', and deprecate kvm-pxe
[20:44] <hallyn> having different version #s for ipxe than kvm-pxe seems like it would cause gnashing of teeth at a later time.
[20:44] <soren> It's bound to cause confusion, yeah.
[20:45] <soren> I think qemu-kvm does something like that?
[20:45] <soren> Or was it the old kvm package? I forget.
[20:45] <soren> qemu-kvm does it.
[20:46] <stgraber> you may want to have something like kvm-etherboot, kvm-ipxe, kvm-gpxe, ... all of them providing kvm-pxe
[20:46] <hallyn> well the kvm package does something funky.  i try to ignore it
[20:46] <soren> It builds a kvm package that has "84+dfsg-0ubuntu16+" prepended to qemu-kvm's version.
[20:46] <hallyn> stgraber: that's voodoo i'm not familiar with.
[20:46] <soren> Anything you do is going to be awkward to some extent.
[20:46] <soren> You can either build kvm-ipxe from the ipxe package.
[20:46] <hallyn> stgraber: mind you i don't care to leave the old etherboot-based kvm-pxe around.
[20:47] <soren> To get upgrades to work, you need to replace kvm-pxe from etherboot with an empty package that depends/replaces: kvm-ipxe.
[20:47] <soren> hallyn: You'll have to.
[20:47] <stgraber> hallyn: you can have a Provide: kvm field in a binary package definition, that's what's done for things like mail-transport-agent
[20:48] <stgraber> hallyn: mail-transport-agent has a package doesn't exist, but you can depend on it and the dependency will be solved if you install postifx or exim or ...
[20:48] <soren> You could add an epoch to ipxe.
[20:48] <hallyn> stgraber: ok, that has advantages, but then someone using etherboot-based kvm-pxe won't automatically be upgraded right?
[20:48] <soren> Or just to kvm-ipxe (but that's really confusing).
[20:49] <soren> hallyn: Right.
[20:49] <stgraber> hallyn: indeed
[20:49] <RoAkSoAx> hallyn: an easier solution is to do a Conflicts/Replaces to ensure the upgrade goes clean
[20:49] <tumbleweed> urgh@epoch bumping
[20:49] <soren> hallyn: Right, but then something needs to still build kvm-pxe.
[20:49] <soren> er...
[20:49] <soren> RoAkSoAx: Right, but then something needs to still build kvm-pxe.
[20:49] <hallyn> tumbleweed: what is the downside?
[20:49] <stgraber> yeah, I strongly recommend not to bump the epoch, especially for a package that's coming from Debian, unless you want to be the one merging it for the few years to come :)
[20:49] <tumbleweed> hallyn: it'll never auto-sync again
[20:50] <tumbleweed> hallyn: the epoch is for when upstream goes crazy and decides their next version is < the current one
[20:50] <hallyn> i suspect they won't take the kvm-pxe package anyway, so i assume autosync won't work.
[20:50] <hallyn> ok, so, i think i know what i need to do.
[20:51] <micahg> hallyn: just because the current maintainer won't take it, doesn't mean in the future there wouldn't be room for consolidation
[20:52] <hallyn> ipxe will provide kvm-ipxe; etherboot will provide an empty binary package that depends on kvm-ipxe.  both will provide kvm-pxe.
[20:52] <RoAkSoAx> smoser: right, but wouldn't this work: 1. Remove binary package from etherboot 2. Add binary package to ipxe and add Conflicts/Replaces (kvm-ipxe <= 5.4.4-7ubuntu3)
[20:53] <hallyn> RoAkSoAx: i think you meant stgraber :)
[20:53] <micahg> RoAkSoAx: same problem since you're changing the versioning scheme for the binary in question
[20:53] <hallyn> uh, no you didn't
[20:54] <hallyn> all right let me go read up on how 'provides' works
[20:54] <hallyn> thanks all
[20:54] <RoAkSoAx> soren: err,  right, but wouldn't this work: 1. Remove binary package from etherboot 2. Add binary package to ipxe and add Conflicts/Replaces (kvm-ipxe <= 5.4.4-7ubuntu3)
[20:54] <soren> RoAkSoAx: No.
[20:54] <soren> RoAkSoAx: The whole problem is that ipxe's version is lower then etherboot's.
[20:54] <soren> *than
[20:54] <RoAkSoAx> soren: ahh right, didn't realize that :)
[20:54] <soren> If it weren't we'd just move the kvm-pxe package to be built by ipxe.
[20:55] <RoAkSoAx> yeah
[20:55] <soren> That's the simple solution.
[20:55] <micahg> hallyn's solution sounds sanest so as not to take over binaries from other packages
[20:56] <soren> kvm-pxe is an Ubuntu specific addition. Why wouldn't be just move it?
[20:56] <soren> micahg: ^
[20:58] <soren> Moving a binary from one source package to another is fine. We do it every single release.
[20:58] <hallyn> i'll have to check if anyone ever tried to push kvm-pxe to debian...
[20:58] <micahg> soren: oops, I forgot it's built by etherboot
[20:58] <soren> hallyn: I doubt it.
[20:58] <hallyn> sigh
[20:58] <micahg> soren: so, you're right, that would have been easiest :)
[20:58] <soren> hallyn: I only added it to avoid getting etherboot into main.
[20:59] <soren> hallyn: ..and because I didn't feel comfortable with the pxe ROMs from the kvm package.
[20:59] <soren> I also don't really see what that would solve?
[20:59] <soren> brb, coffee time.
[21:01] <hallyn> soren: what it would solve is that then presumably Debian folks would have given ipxe a higher version # :)
[21:02] <hallyn> is switching kvm-pxe from being a versioned binary package, to being a (unversioned?) virtual package ok?
[21:02] <tumbleweed> hallyn: some of the issues here are discussed in http://wiki.debian.org/Renaming_a_Package ( method 2 )
[21:02] <hallyn> thanks, reading now
[21:02] <tumbleweed> creating a dummy that depends on the new package providing these files really seems the easiest way
[21:18] <soren> hallyn: Making it a virtual package won't solve your problem.
[21:18] <hallyn> soren: yeah i'm not doing that
[21:19] <hallyn> soren: i'm just making kvm-pxe in etherboot an empty pkg depending on kvm-ipxe
[21:19] <soren> hallyn: Consider the example given: mail-transport-agent. If that worked, you'd constantly have your mta replaced with whichever one had the highest version number :)
[21:19] <hallyn> yeah, i realized that a few minutes ago - too bad though :)
[21:20] <stgraber> soren: we might be getting interesting upstream version number wars then :)
[21:20] <hallyn> soren: i'm playing in lp:~serge-hallyn/ubuntu/precise/ipxe/kvm-pxe-in-ipxe and lp:~serge-hallyn/ubuntu/precise/etherboot/kvm-pxe-notin-etherboot, fwiw
[21:21] <stgraber> we could also create a default-desktop-environment or whatever else and see upstream start bumping their version number to become the default ;)
[21:21] <tumbleweed> given that kvm-pxe only has one reverse dependency, this doesn't need to be very long-lived...
[21:23] <hallyn> tumbleweed: it has one?  in precise?
[21:23] <hallyn> qemu-kvm used to suggest it, but that switched recently to ipxe.
[21:24] <tumbleweed> hallyn: yes, testdrive-common
[21:24] <hallyn> ah
[21:25] <hallyn> oh, jikes, etherboot fails to build for me.  oh maybe i hae to be on i386?
[21:26] <mterry_> SpamapS, heyo.  did you see that libdbi-drivers failed to build?  It's internal autoconf macro is not looking in a multiarch dir for it
[21:27] <Daviey> tumbleweed: if kvm-pxe is made a metapackage which depends on a NEW binary package kvm-pxe-files (or something) built from ipxe, we a are gold.
[21:27] <Daviey> we don't NEED to use the same binary package name
[21:27] <tumbleweed> exactly, that's the best way out of this, I think
[21:27] <tumbleweed> hallyn: build deps are uninstallable for me on i386 too
[21:28] <hallyn> Daviey: yeah, i didn't want to do that (bc i figure people are used to typing 'kvm-pxe') but that's what i'll do
[21:28] <hallyn> tumbleweed, well jinkeys
[21:28] <Daviey> kvm-pxe would need to stay in universe, and kvm depends (recommends?) on kvm-pxe-fils (or whatever)
[21:28] <slangasek> cyphermox: bug #882817> what is nm-dispatcher.action?  It doesn't appear to be run here, but others are reporting it's a subprocess of NM getting killed on shutdown by sendsigs and causing problems
[21:28] <Daviey> people still have an upgrade path, and etherboot stays in universe
[21:28] <hallyn> Daviey: etherboot shoudl probably be gotten rid of actually!
[21:28] <Daviey> hallyn: If it is dropped from debian, sure
[21:29] <hallyn> Daviey: it won't build
[21:29] <Daviey> hallyn: Does it FTBFS in debian aswell?
[21:29] <hallyn> Daviey: and yes it's no longer indebian
[21:29] <hallyn> only in lenny and squeeze
[21:29] <Daviey> hallyn: well then, hell - drop it :)
[21:29] <cyphermox> slangasek: AFAIK it's supposed to be a tiny program that just runs through /etc/NetworkManager/dispatcher.d to run the scripts there
[21:29] <hallyn> Daviey: does anything dpeend on it though?
[21:30] <mterry_> SpamapS, oh I think I have a fix for it
[21:30] <Daviey> hallyn: Replace it with a meta/virtual package of the same or greater version string to give people an upgrade path until after precise.
[21:30] <hallyn> Daviey: fine for kvm-pxe, but i dunno about etherboot itself, if it has users
[21:31] <Daviey> hallyn: ipxe is a drop in replacement still, right?
[21:31] <Daviey> with added foo.
[21:31] <hallyn> Daviey: for my purposes, yes.  but i don't know about all of the roms
[21:31] <hallyn> ebox-dhcp depends on etherboot
[21:31] <Daviey> I believe it is still compatiable, including conf's
[21:31] <hallyn> ACTION checks what that is
[21:31] <slangasek> cyphermox: hmm; why would it be running at the same time as /etc/rc6.d/S20sendsigs?
[21:32] <cyphermox> slangasek: I wonder if it's a race due to something else like dbus shutting down?
[21:32] <Daviey> hallyn: I'd fire off an email to the ebox chaps and let them know that we plan to get rid of etherboot, i am certain they'd be happy to convert any code deps over.
[21:32] <cyphermox> slangasek: I'd say it gets run when NetworkManager shuts down, because some interfaces are being taken down (thus change)
[21:32] <slangasek> cyphermox: certainly not; dbus doesn't shut down until the 'deconfiguring-networking' event is received
[21:32] <cyphermox> ok
[21:32] <hallyn> Daviey: ok.  so then to drop it, do i just remove the source and make sure no files get installed by it, and tweak control to depend on ipxe?
[21:33] <slangasek> and that's emitted by /etc/rc6.d/S35networking
[21:33] <Daviey> hallyn: you need to raise a bug for an AA to remove it.
[21:33] <slangasek> and /etc/rc6.d/S20sendsigs should finish before /etc/rc6.d/S35networking is called
[21:33] <slangasek> so something's odd here - something that I can't reproduce locally
[21:33] <slangasek> but that's been reported by multiple users of NFS
[21:33] <hallyn> Daviey: i don't want to remove it yet though right?
[21:34] <Daviey> hallyn: I don't see why not?
[21:34] <cyphermox> slangasek: I have tried but failed to reproduce it as well. the thing is NetowrkManager is "stop on stopping dbus", and the only thing I can think of would be for NM to run this when it's taking down interfaces
[21:34] <slangasek> hmm
[21:34] <cyphermox> slangasek: I'll take a look at where this gets run
[21:34] <slangasek> cyphermox: ok, thanks
[21:35] <hallyn> Daviey: because etherboots and kvm-pxe, with their (bumped) verison #s, need to stick around and depend on ipxe and kvm-ipxe?
[21:35] <Daviey> hallyn: Hmm.. it might be better to replace it with the meta package, rather than processing a removal + new
[21:35] <cyphermox> (but a little later, I need to run to catch a bus now)
[21:35] <slangasek> cyphermox: if you have any questions about the rest of the shutdown sequence, just ask
[21:35] <hallyn> Daviey: hm, meta package.  new to me.
[21:35] <cyphermox> slangasek: sure
[21:35] <Daviey> hallyn: empty package, that simply Depends on something else.. aka virtual
[21:35] <Daviey> hallyn: ie, ubuntu-desktop
[21:36] <hallyn> Daviey: so how/were do I define that?
[21:36] <hallyn> oh, virtual.  but then it's not versioned.
[21:37] <Daviey> yeah, it is.
[21:37] <hallyn> Daviey: the problem with that is that users of kvm-pxe won't ever be upgraded
[21:37] <hallyn> oh?
[21:38] <tumbleweed> Daviey: meta != virtual
[21:38] <Daviey> hallyn: Yeah.. So...  we upload etherboot which is now an EMPTY package, other than a Depends on kvm-ipxe (suggestion)
[21:38] <Daviey> kvm-ipxe is built from ipxe
[21:38] <hallyn> Daviey: ok, sure, I guess that's what I was suggesting, except i was goin to just rm -rf src/ etc  :)
[21:38] <Daviey> etherboot source package provides binary package kvm-pxe
[21:38] <hallyn> Daviey: so, why would an AA need to be involved?
[21:39] <Daviey> tumbleweed: right, sorry
[21:39] <Daviey> hallyn: they don't... i was thinking procesing a removal of etherpad.. we don't want to do that
[21:39] <hallyn> Daviey: ok.  sound like we were agreed all along then :)  thanks
[21:40] <hallyn> Daviey: oh, ebox-dhcp only suggests etherboot.  so i see no problem
[21:40] <hallyn> i'll get on it
[21:41] <Daviey> hallyn: well they should still be kept in the know.
[21:41] <hallyn> Sure, but nothing should break at least
[21:44] <hallyn> Daviey: I've sent them an email fwiw
[21:51] <hallyn> Daviey: everyone seems to use 'DEBIAN' for meta packages rather than debian/.  Is that convention?
[21:53] <hallyn> ah i see now.  apparently it's required
[21:56] <infinity> hallyn: ?
[21:56] <hallyn> infinity: I'm switching etherboot into a meta package depending on ipxe.  trying to figure out the best way
[21:57] <infinity> hallyn: That ? was for the debian versus DEBIAN thing. :P
[21:57] <hallyn> oh,
[21:57] <infinity> hallyn: debian/ is the directory in a source package that contains rules, etc.
[21:57] <infinity> hallyn: DEBIAN is the control directory in a binary package's pre-pack state.
[21:57] <hallyn> http://jeffhoogland.blogspot.com/2011/08/howto-create-debian-meta-package.html  says DEBIAN is used for meta packages...

[21:58] <infinity> That tutorial is not creating a source package.
[21:58] <infinity> It's creating a raw binary package by hand.
[21:58] <SpamapS> mterry_: I have a fix
[21:59] <infinity> Just do a source package the same way as you always would (dh_make, for instance), and rejoice at the part where you have no actual source to build.
[21:59] <mterry_> SpamapS, I already uploaded one (though it failed to build for a different, temporary reason while mysql is crazy)
[21:59] <SpamapS> UGH
[21:59] <hallyn> well there is pre-existing source.  i'm trying to figure out how conservative to be with rm -rf
[21:59] <infinity> So, nothing to install, etc, etc.  Just a debian/control to fiddle with, and a rules file that does nothing in the build target.
[21:59] <SpamapS> mterry_: mysql should not be crazy anymore
[21:59] <mterry_> SpamapS, sorry, thought I said I had a fix
[22:00] <SpamapS> mterry_: you did, but while you were saying that, I was finishing my test build for my fix
[22:00] <infinity> hallyn: If there's a pre-existing source package that you want to maintain history for, deleting everything but control, rules, chagelog, and copyright, and then fixing them to do very little.
[22:00] <mterry_> SpamapS, mysql-client and mysql-server are both 5.5 now?
[22:00] <SpamapS> mterry_: yes
[22:00] <infinity> hallyn: (Though you're just as well starting from scratch and just including the old changelog)
[22:00] <SpamapS> as of a few hours ago
[22:00] <SpamapS> maybe not in arm actually
[22:01] <mterry_> SpamapS, I just uploaded a moment ago, not the case on the buildds yet
[22:01] <hallyn> infinity: no point in keeping the source?  copyright files?
[22:01] <mterry_> maybe hasn't propogated
[22:01] <infinity> hallyn: The only copyright that matters once you've switched to a pure meta source is mentioning the packaging copyright in debian/copyright.
[22:01] <SpamapS> Hmm..
[22:01] <infinity> hallyn: Since there's no other source around anymore, right?
[22:02] <hallyn> infinity: oh, right, so, i should bump the version number to get a new .orig.tar.gz then?
[22:02] <hallyn> infinity: right, no other src
[22:02] <infinity> SpamapS: Finished 16 hours ago (took 7 hours, 46 minutes, 46.7 seconds)
[22:02] <mterry_> doko, speaking of, do you have a fix for gcj-4.6's FTBFS?  I think I do
[22:02] <infinity> hallyn: There shouldn't be an orig anymore.  But yes, you'll need a higher upstream version number.
[22:02] <infinity> hallyn: And then switch to native.
[22:03] <hallyn> native?
[22:03] <mterry_> SpamapS, apt-cache show mysql-client on my machine shows 5.1
[22:03] <SpamapS> crap.. how did I miss that mysql-client needed to be a meta package too? :-P
[22:03] <infinity> As in, use a foo_1.2.3.dsc version instead of foo_1.2.3-1.dsc version.  And you'll just get a tar.gz and .dsc
[22:03] <infinity> Hard to have a Debian diff when there's no upstream source to diff against. ;)
[22:04] <hallyn> infinity: ok, thanks.
[22:04] <SpamapS> mterry_: I believe the fact that mysql-common breaks mysql-client-5.1 causes apt to choose mysql-client-5.5 instead
[22:04] <SpamapS> but I could be wrong
[22:04] <mterry_> SpamapS, the buildd didn't choose client-5.5, it just bailed
[22:05] <infinity> SpamapS: The break might force an upgrade, but the metapackages were there for that reason. :)
[22:05] <SpamapS> Ahh yeah that makes since
[22:05] <SpamapS> indeed, the meta packages are coming back, I just forgot to resurrect the mysql-client one. :-P
[22:06] <infinity> Has Christian given up Debian maintenance of MySQL?  He used to get this sort of thing right first go.
[22:07] <SpamapS> Everyone has.
[22:07] <infinity> Hrm, so I see.
[22:07] <SpamapS> Norbert has kept the flame burning..
[22:07] <infinity> Maybe I should come out of hiding sometime.
[22:07] <SpamapS> But he's had *zero* time the last year
[22:07]  * Laney sees a certain person has been maintaining -5.5 :-)
[22:07] <SpamapS> Yeah its basically just me right now.
[22:08] <infinity> Yeah.  And I don't love you half as much as ch.
[22:08] <infinity> Mostly because he buys me cookies.
[22:08] <SpamapS> I'd love *anybody* who knew all the pitfalls and trapdoors in this process and wanted to help out. :)
[22:09] <infinity> I'm hat-shuffling a lot right now, but I'd be happy to come back and help in a few weeks.  That won't help you with the current pain, though. :P
[22:09] <infinity> I wonder if I'm still in the right alioth groups and such...
[22:10] <SpamapS> I think by then I'll have found most of the sharp sticks by falling on them. :)
[22:10] <infinity> Probably.  But there are always new versions. ;)
[22:10] <SpamapS> But it would be good for you to come help in case I bleed out.
[22:10] <infinity> And bugs.
[22:10] <infinity> So many bugs.
[22:10] <SpamapS> Yeah I triaged for 4 hours last week.. barely made a dent. :-P
[22:11] <SpamapS> Hrm the test suite is broken too...
[22:11] <SpamapS> need to figure that one out.
[22:11] <infinity> Apparently, I'm a "Senior Developer" on pkg-mysql.
[22:11] <infinity> Shiny.
[22:11] <infinity> So, I assume I stil have SVN write access. :P
[22:12] <SpamapS> woot
[22:12] <SpamapS> I'd actually love to move it to bzr or even git. svn.. so.. annoying
[22:12] <infinity> I'm remarkably unpicky.
[22:13] <infinity> And back when we set up all the LAMP pkg-$foo bits, SVN was better than, well, every other option.
[22:13] <infinity> You can almost certainly blame me.
[22:13] <infinity> Especially if it has a weird branch/directory structure.
[22:13] <infinity> Apparently, no one ever saw eye-to-eye with me on my SVN workflow. :P
[22:14] <SpamapS> it works fine right now..
[22:14] <SpamapS> just not awesome
[22:19] <SpamapS> mterry_: btw, the include dir for libmysqlclient-dev isn't multi-arched
[22:20] <SpamapS> mterry_: best way to get the include and libdirs is just to run 'mysql_config --variable=pkglibdir'
[22:20] <SpamapS> mterry_: or mysql_config --variable=pkgincludedir
[22:20] <SpamapS> mterry_: I will upload a fixed libdbi-drivers once mysql-client is a meta package again
[22:28] <hallyn> Daviey: soren: here's what I've got for a new met package to replace etherboot.  http://people.canonical.com/~serge/kill-etherboot
[22:30] <hallyn> Needless to say this is not a friday-night upload kinda thing :)
[22:36] <mterry_> SpamapS, it's not multiarched now, but I've seen libraries with a header in the multiarch include directory, so it seemed harmless to include it
[22:36] <mterry_> plus, the other config flags use that idiom
[22:36] <SpamapS> mterry_: its actually not harmless tho.. it will fail to find them and abort configure. :-/
[22:37] <mterry_> SpamapS, I built with it...
[22:37] <SpamapS> mterry_: libdbi-drivers is fairly broken. :-P
[22:37] <SpamapS> mterry_: hrm.. had problems here.. but.. like I said, its just broken. :-P
[22:37] <mterry_> SpamapS, I assumed it found them because /usr/include is always in the include path
[22:38] <mterry_> SpamapS, well regardless, I could believe I screwed something up.  Please fix as you see fit  :)
[22:38] <SpamapS> mterry_: its silly in that it just does file-finds not actual compile tests.
[22:38] <soren> hallyn: 404?
[22:39] <soren> hallyn: ...but you say you're adding a new meta package? What for?
[22:40] <hallyn> soren: not a new one, replacing etherboot with a meta package
[22:40] <soren> hallyn: Oh.
[22:40] <soren> hallyn: Err..
[22:40] <soren> hallyn: Hm. Ok.
[22:40] <soren> hallyn: Why?
[22:41] <hallyn> soren: don't know wha thappened that time.  http://people.canonical.com/~serge/kill-etherboot/etherboot_5.4.5.dsc should be up now.
[22:42] <hallyn> soren: why? bc etherboot and kvm-pxe need to stick around with higher # to make ppl upgrade to ipxe and kvm-ipxe?
[22:42] <soren> hallyn: But etherboot didn't used to be a metapackage.
[22:43] <hallyn> soren: right.  why is that bad?
[22:43] <Daviey> soren: etherboot become a just a etherboot source package providing a meta binary package of kvm-pxe, which depends on kvm-ipxe, providing an upgrade path.  ipxe will now build kvm-ipxe.
[22:43] <Daviey> we are deprecating etherboot.
[22:43] <soren> What if someone still uses it?
[22:43] <soren> Not kvm-pxe. The other stuff.
[22:44] <soren> I'm assuming there's still "other stuff"?
[22:44] <Daviey> soren: to the best of our knowledge, ipxe itself is still a drop in replacement; still accespt the same config file format.
[22:44] <hallyn> soren: then they are switched over to ipxe, which is supported?
[22:44] <Daviey> the only reverse depends, hallyn is emailing.
[22:44] <Daviey> (it's a suggest)
[22:44] <hallyn> soren: etherboot won't build any more.
[22:45] <soren> What's it status in debian?
[22:45] <Daviey> Gone.
[22:45] <soren> *its
[22:45] <soren> Ah.
[22:45] <soren> Ok, then I don't care :)
[22:45] <Daviey> $ rmadison -uqa etherboot etherboot | 5.4.4-6~bpo50+1 | backports/lenny | source, all etherboot | 5.4.4-9         | squeeze         | source, all
[22:46] <soren> -uqa means "show both Debian and Ubuntu"?
[22:46] <soren> ERr..
[22:46] <Daviey> no, just debian
[22:46] <soren> No :)
[22:46] <soren> Yeah.
[22:46] <hallyn> and, fwiw, lp:~serge-hallyn/ubuntu/precise/ipxe/kvm-pxe-in-ipxe/ is the corresponding ipxe update
[22:47] <hallyn> soren: ok, cool, thx.  Daviey: obviously no hurry for today, but if you could have a look in the next few days, i'd appreciate it :)
[22:47] <soren> I didn't realise it was gone from Debian. That simplifies it quite a bit.
[22:48] <Daviey> hallyn: Yeah, i'll check it out over the weekend/monday, unless soren is keen to touch it now? :)
[22:48] <soren> Gosh no.
[22:48] <hallyn> Daviey: great, thx, ttyl
[22:48] <Daviey> o/
[22:48] <soren> I couldn't even read your rmadison output without getting confused :)