[08:34] <pitti> Good morning
[08:35] <ajmitch> morning pitti
[08:36] <sladen> morning
[08:37] <cyphermox> good morning
[08:49] <ev> hiya
[08:51] <geser> good morning
[08:55] <pitti> ev, cjwatson: I've got working GI bindings for libxklavier yesterday; I submitted them upstream, but if you want to work on it soonish, I can create a PPA for you if you want?
[08:55] <pitti> ev, cjwatson: that's for bug
[08:55] <pitti> bug 800561
[08:56] <ev> pitti: cheers! I'm happy to wait for it to land in the archive, given that we shipped 11.10 without it
[08:58] <pitti> ev: upstream already responded yesterday, I hope it'll land RSN; but in case you want to play around with it, I wanted to tell you
[09:10] <ev> thanks
[09:35] <mpt> mvo, hi, is robert_ancell around? I'd like to talk with you when you're both free, about recovering from failed upgrades
[09:44] <mvo> mpt: I check the desktop room
[09:45] <pitti> mpt: in the desktop room here
[09:49] <mpt> Hi robert_ancell, are you or mvo on Skype? Or else Mumble?
[09:49] <robert_ancell> mpt, we can mumble
[09:52] <robert_ancell> mpt, mvo is busy at the moment, do you want both of us?
[09:52] <mpt> robert_ancell, ideally.
[09:52] <robert_ancell> ok, we'll call then
[09:52] <mpt> thanks
[09:52] <robert_ancell> (in 15 mins)
[09:53] <mpt> ok
[09:57] <cjwatson> pitti: that's great, thank you - what ev said
[10:26] <mvo> mpt, robert_ancell: I'm ready now, sorry for the delay
[10:27] <mpt> mvo, robert_ancell was just on Mumble but then left
[10:32] <mpt> robert_ancell, phone call instead?
[10:36] <mpt> mvo, sorry, I'm not hearing what you're saying
[10:37] <mvo> mpt: not hearing at all or in bad quality?
[10:37] <robert_ancell> mvo, now your mic is stuck on
[10:37] <mpt> mvo, you sound like a MIDI keyboard
[10:37] <mvo> mpt: I think we need both, at startup and at the installer level
[10:37] <mpt> mvo, ok
[10:37] <mvo> mpt: as the startup maybe in susch a bad shape that it can not recover from the installed system
[10:38] <mpt> mvo, robert_ancell: So would the UI for the startup variant be inside Plymouth?
[10:38] <robert_ancell> mpt, I would have thought it would be in grub or failsafe-x
[10:39] <mvo> we have support in friendly-recovery for recovering from a broken upgrade, but the UI is certainly lacking :/
[10:39] <mpt> Is it a console UI?
[10:39] <mvo> yes
[10:39] <mvo> text ui
[10:39] <mvo> not even progress bars
[10:40] <mpt> ok
[10:41] <mpt> If they were both implemented, would the startup and installer-based recovery systems share code at all?
[10:43] <mvo> that is a interessting question, it depends on how we do it - but I would image that the installer-based on is very much apt-clone based. I haven't put much thought into how it would be done on startup, but there are certainly area where code can not be shared, like the UI in ubiquity would be different etc
[10:45] <mpt> mvo, that question was mainly about whether it should be one or two specifications :-)
[10:47] <mpt> mvo, robert_ancell: so, I'll do sketches for both a Ubiquity-based UI and a console-based UI
[10:53] <robert_ancell> mpt, ok, so mvo and I talked here and we think you probably just need an ubiquity UI and a software-center UI
[10:53] <mpt> robert_ancell, why would it go in USC?
[10:53] <mvo> mpt: and the software-center UI we have (the rapair broken catalouge)
[10:54] <robert_ancell> mpt, so ubiquity is used for severe corruption cases, and software center for minor breakages (e.g. flash)
[10:54] <robert_ancell> The stuff we covered at UDS (https://wiki.ubuntu.com/GracefulFailure) is more about detecting failure and notifying the user as opposed to necessarily fixing the problems
[10:54] <mvo> the console based one would fall right into the middle of this so its probably not worth the effort
[10:55] <mpt> ok
[10:55] <robert_ancell> and it's not clear which part of the boot would be able to detect the failure (without side effects of slowing boot) and launch such a console UI
[10:58] <mvo> for the console UI you would have to have a work kernel, python at least
[11:11] <seb128> mvo, bug #913719
[11:13] <mvo> thanks seb128
[11:13] <seb128> mvo, thank *you* ;-)
[11:28] <mpt> mvo, how long would it take to go through the available partitions on a typical PC, and detect that one of them was a broken Ubuntu installation? Seconds? Minutes?
[11:28] <mvo> mpt: ev will be able to answer this better, but I think second
[11:28] <mvo> s
[11:28] <mpt> ok
[11:31] <ev> answered out of band
[11:54] <pitti> cjwatson: are you aware of any recent changes in the live system build? desktop CDs are now 21 Mb oversized, and I think last week they were at 705 MB; but the alternates did not grow, so iso-deb-size-compare won't work
[11:56] <pitti> cjwatson: hm, then again the health check from an hour ago still says
[11:56] <pitti> ubuntu/daily-live: precise-desktop-amd64.iso oversized by 5550080 bytes (739553280)
[11:57] <pitti> so maybe I mix it up with that (wrong?) number
[12:18] <cjwatson> pitti: not that I know of
[12:38] <Riddell> pitti, cjwatson: is there a tech board meeting today?
[12:54] <cjwatson> Riddell: good question, I guess it depends on what the schedule in Budapest is like
[12:55] <pitti> I guess I can make it
[12:56] <pitti> who is chairing today?
[12:56] <pitti> ah, mdz
[13:51] <MacSlow> pitti, ping
[13:51] <pitti> MacSlow: hey
[13:52] <MacSlow> pitti, hey... I just switched to precise on my laptop and not compiling libunity it complains about missing "/usr/lib/i386-linux-gnu/libgio-2.0.la"
[13:53] <pitti> MacSlow: right, .la files are gone; we don't need them, they only cause unnecessary extra dependencies
[13:53] <MacSlow> pitti, it's form some part of the linker-work during make... I was wondering if there might be an issue with the packages on precise
[13:53] <MacSlow> pitti, so what's needed on my side now to make the "make" work again?
[13:53] <pitti> MacSlow: it might come through a library in between, though; perhaps you can pastebin the last couple of lines of build log?
[13:54] <pitti> i. e. a faulty .pc file of a library package
[13:55] <MacSlow> http://pastebin.ubuntu.com/798218/
[13:55] <pitti> MacSlow: seb128 is coming over to you
[13:55] <pitti> MacSlow: most probably you have a local broken /usr/local/lib/*.la
[13:55] <MacSlow> pitti, cool... seb128 thx :)
[14:31] <barry> ScottK: re: "port to qt" - not sure either, but mvo mentioned it when we chatted.  that was mostly just a placeholder.  if it's available upstream, pending packaging, that's much better
[14:31] <ScottK> Cool.
[14:32] <barry> thanks for following up on the blueprint
[14:32] <ScottK> I played with it a little and it's not 100% straightforward to package, but I think it's doable with a bit of fiddling.
[14:32] <barry> do you have a branch or other code i can start with?
[14:32] <ScottK> No.
[14:33] <barry> k
[14:33] <ScottK> I'd start with pykde4 in precise.
[14:33] <barry> yep
[14:34] <ScottK> barry: The one thing that's not just coercing it to build is figuring out what to do about /usr/lib/kde4/kpythonpluginfactory.so.
[14:35] <ScottK> Although with the .so name munging in python3, maybe it's OK.
[15:04] <barry> ScottK: right, it would end up being kpythonpluginfactory.cpython-32mu.so so it shouldn't conflict *although* the import machinery might get confused if they both exist
[15:05] <ScottK> That would be the tricky part.
[15:05] <ScottK> Will python3.2 prefer a munged name over an unmunged one?
[15:05] <ScottK> If it will, it should be ~fine.
[15:06] <barry> ScottK: i'm checking the source now :)
[15:06] <ScottK> Cool.
[15:15] <barry> ScottK: yep, module.soabi.so gets found before module.so, so we should be good (glad i did the right thing and/or used the time machine keys)
[15:15] <ScottK> :-)
[15:15] <ScottK> Then it's probably just a matter of build-deps and beating cmake into submission.
[15:16] <l3on> doko, I looked at libkml, but your patch introduced in bug debian #650525 does not work
[15:16] <l3on> can you help me to understand wath's wrong? :)
[15:16] <l3on> *what
[15:17] <barry> cool, now it's in the whiteboard so i'm on the hook :)
[15:17] <ScottK> Excellent.
[15:17] <tjaalton> slangasek: got a multiarch-related bug for you, not sure where to put it, bug 874143
[15:20] <tjaalton> slangasek: so apparently the non-native version of the package got installed before the native one got upgraded
[15:20] <tjaalton> see the end of apttermlog
[15:27] <doko> l3on, to reproduce it yourself, you could try to build in a oneiric or precise chroot (debootstrap sets it up for you). do you package a new upstream version?
[15:28] <l3on> doko, no. I have grabbed merge from debian
[15:29] <doko> l3on, build log?
[15:30] <l3on> lost, wait a bit, I'm going to rebuild it
[15:40] <trism> Is there a reason the debug dbus-daemon binary is installed to /bin? (in both oneiric and precise)
[15:43] <l3on> doko, http://debomatic64.debian.net/precise/pool/libkml_1.3.0~r863-3ubuntu1/libkml_1.3.0~r863-3ubuntu1.buildlog
[15:43] <l3on> the current debian package has your patch on board
[15:45] <doko> l3on,  ../../src/kml/engine/libkmlengine.la ../../src/kml/regionator/libkmlregionator.la
[15:45] <doko> exchange these two
[15:48] <slangasek> tjaalton: this is bug #835625
[15:49] <tjaalton> slangasek: cool, thanks, I'll dupe it then
[15:49] <slangasek> tjaalton: I don't think we're going to backport to 11.04 apt though, because we weren't provisioning multiarch for users in 11.04
[15:50] <slangasek> tjaalton: so you've been hit by this problem by being an early adopter only
[15:50] <tjaalton> slangasek: nah it wasn't me, just was going through the bugs against libpciaccess
[15:51] <slangasek> tjaalton: ok
[15:55] <semiosis> When/how often does Ubuntu sync from debian unstable?
[15:56] <cjwatson> This cycle we've been syncing from testing, not unstable
[15:56] <cjwatson> We just stopped doing so today
[15:56] <cjwatson> For the first half or so of a release cycle, the sync is roughly daily
[15:58] <semiosis> cjwatson: when you say stopped doing so... does that mean you've stopped debian syncs altogether or have switched to unstable?
[15:59] <semiosis> here's my issue, i work with the debian maintainer of the glusterfs project and we just committed a patch that enables the latest version to build.  i'd like to see that latest version included in 12.04.  should I now file a syncrequest?
[15:59] <ScottK> Yes.
[15:59] <cjwatson> semiosis: We stop syncs for the second half of every Ubuntu release cycle
[15:59] <cjwatson> But just the automatic ones - you can still request them
[15:59] <semiosis> ah ok.  thanks i'll do that.
[15:59] <cjwatson> So yes, file a sync request if you want it
[16:00] <semiosis> one more thing... the debian package glusterfs-server includes an initscript, but that causes a bug on ubuntu beucase of upstart/mountall.  i've contriubted an upstart job to the upstream project, but since debian doesn't use upstart, its not in the debian package.
[16:00] <semiosis> so i'd like to add a merge to ubuntu to add the upstart job to the glusterfs package in ubuntu
[16:01] <semiosis> does that sound right?
[16:01] <ScottK> Yes.
[16:02] <ScottK> Althoguh upstart is in Debian, so there's no reason it couldn't be added there too.
[16:02] <cjwatson> upstart jobs are a fairly common source of divergence at the moment though, so *shrug*
[16:02] <semiosis> afaik including an upstart job in the debian package adds a requirement on upstart-job, which causes install to break on debian boxes
[16:02] <cjwatson> you wouldn't be the first
[16:02] <cjwatson> depends on how you do it ... but yeah
[16:03] <trism> When I say debug dbus-daemon, I don't mean unstripped, I mean, has the DBUS_BUILD_TESTS sections enabled. It is copied twice in the build logs, once from build/bus and then overwritten by build-debug/bus
[16:15] <l3on__> doko, → http://debomatic64.debian.net/precise/pool/libkml_1.3.0~r863-3ubuntu1/libkml_1.3.0~r863-3ubuntu1.buildlog
[16:15] <l3on__> cp: cannot stat `debian/tmp/usr/share/java': No such file or directory
[16:16] <semiosis> cjwatson, ScottK: thanks again!
[16:20] <stokachu> slangasek: I was looking into bug #858122 comment #45 and didn't see anything related in the bazaar revisions that would relate to this. I see wfink has been doing most of the commits would he be able to provide some status on that bug?
[16:20] <stokachu> slangasek: if nothing has been done I dont mind picking it up and looking into i
[16:20] <stokachu> it*
[16:22] <slangasek> stokachu: wfink is upstream for insserv, he wouldn't have any input on this as it's entirely a distro integration question
[16:22] <stokachu> ah
[16:23] <stokachu> i may be looking at wrong package in launchpad then
[16:23] <slangasek> stokachu: the main thing to do be done is to move insserv off the system path, I believe
[16:23] <slangasek> stokachu: I think you're looking at an import of the upstream source rather than at the package
[16:23] <stokachu> ok, so we are thinking move it off system path then help pkg maintainers to fix their packages?
[16:24] <stokachu> or just provide a technical release note of some sort
[16:24] <slangasek> which package maintainers do you mean?
[16:24] <stokachu> these would be 3rd party like turboprint who calls insserv directly
[16:24] <slangasek> does turboprint call insserv unconditionally, or only if detected?
[16:25] <stokachu> good question I'd need to get their source packages and look into it
[16:25] <slangasek> FWIW I wasn't planning on doing any work to fix third-party packages; they're using a non-standard interface, and stopping that interface from being available fixes the critical bug
[16:26] <stokachu> ok sounds good
[16:40] <stokachu> slangasek: would I be wrong in suggesting upstart replace/conflict: chkconfig, insserv?
[16:40] <stokachu> upstart already replaces sysvinit so why not go a bit further
[16:48] <slangasek> stokachu: I don't know that the chkconfig package is incompatible, is it?  And as for insserv, upstart itself doesn't conflict with insserv at all, and in the long term I actually think we will be using insserv for bridging upstart and sysvinit dependency information
[16:48] <slangasek> stokachu: so I'd really prefer that we just shunt insserv to a different directory and not diverge from Debian's initscripts package for this
[16:48] <stokachu> ok
[16:49] <stokachu> ah yea so update.rc-d uses insserv... i think chkconfig calls insserv directly though, i need to research that more
[16:56] <cjwatson> mvo: so for https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-lts-upgrades, the way I did this for previous releases was to copy .debs into dists/$CODENAME/main/dist-upgrader/binary-$ARCH/ on the CD - will that still work?
[16:56] <mvo> cjwatson: it should, yes
[16:58] <cjwatson> cool, that should be easy then
[17:05] <mvo> cjwatson: let me know once its there and I will a) re-enable my old code b) test ;)
[17:17] <Riddell> mdz, pitti, cjwatson: well I need to go out, if there is a tech board meeting I can get home for it fine but please text message me 20 mins before
[17:18] <Riddell> jriddell.org/contact.html
[17:30] <mdz> Riddell, I'm expecting to have a meeting; is there talk of canceling it?
[17:30] <mdz> there is content on the agenda
[17:32] <ScottK> mdz: It looks like last meeting's content though. I think PAE kernel is done.
[17:34] <ScottK> PAE/non-PAE
[17:34] <Riddell> mdz: there's no agenda made and pitti and cjwatson weren't sure if it was happening
[17:44] <mdz> ScottK, Riddell, two items were just added today
[17:45] <Riddell> ok I'll assume Kubuntu LTS is being discussed and be back in time for it
[17:47] <arges> broder, hello. does your backportpackage script allow for first backporting a dependency and then feeding that to backport the original package? or is this something I need to set up in pbuilder? thanks
[19:43] <psusi> cjwatson: since partman makes an extended partition for you anyhow, why doesn't it just put the root filesystem inside it as well, instead of only the swap partition?
[19:45] <cjwatson> psusi: Because many BIOSes will refuse to boot if you have no primary partitions at all.
[19:45] <funkyHat> re. the new version of gnutls (https://lists.ubuntu.com/archives/ubuntu-devel/2012-January/034629.html)... surely LGPLv3+ allows use in GPL2 projects? Surely that's the point of the LGPL (well not specifically GPL, but other licenses, including closed source ones)
[19:47] <psusi> cjwatson: ahh, so makes sense if you chose the option to use the whole drive, but when installing along side windows...
[19:47] <cjwatson> psusi: Then it will use logical partitions for both.
[19:48] <psusi> cjwatson: hrm... from what I've seen it still puts the root in a primary and only swap in logical
[19:49] <cjwatson> psusi: Happy to look at a partman log, but it's not supposed to do that in general.
[19:49] <cjwatson> funkyHat: I'm afraid that's not the way it works
[19:49] <psusi> cjwatson: good to know... will file a bug report with the logs if I see it again
[19:50] <cjwatson> funkyHat: you can google for "lgplv3 gplv2 compatibility" for instance ...
[19:51] <cjwatson> funkyHat: http://gplv3.fsf.org/dd3-faq has a compatibility matrix
[19:53] <funkyHat> cjwatson: thanks. I'll have to re-read the licenses to try to understand why...
[20:03] <cjwatson> funkyHat: if it helps, the reason for the incompatibility is in the terms of the GPLv2, not in the terms of the LGPLv3
[20:04] <funkyHat> cjwatson: yeah I found a couple of bits relating to samba that said that. I didn't realise GPLv2 was that restrictive
[20:04] <cjwatson> funkyHat: GPLv2 says "must distribute under terms of GPLv2 with no additional restrictions" and LGPLv3 has a couple of additional restrictions over GPLv2
[20:04] <cjwatson> IIRC
[20:05] <cjwatson> there's the system libraries exception, but we don't get to use that when we're distributing both library and thing-that-uses-library
[20:05] <funkyHat> So GPLv2 software can't link with libraries under *any* license that is more restrictive than the GPLv2 (with the exception of standard system libraries, apparently)
[20:07] <cjwatson> right (and even then only if distributed separately from those system libraries)
[20:07] <funkyHat> I suppose because I've seen GPL software released for Windows I assumed it was ok to link with anything, where in fact it's only ok because of the system libraries exception
[20:07] <cjwatson> this is also the reason the GPL is incompatible with the OpenSSL licence
[20:07] <cjwatson> funkyHat: yes
[20:08] <cjwatson> my understanding is that Microsoft would not be permitted to distribute GPLv2 software together with Windows, although I haven't previously thought about this :)
[20:09] <cjwatson> I understand that the GPLv3's system libraries exception is broader; I haven't checked how it would work in such a hypothetical situation
[20:10] <cjwatson> GnuTLS could solve this using an LGPLv3/GPLv2 dual licence, if they wanted to: http://www.gnu.org/prep/maintain/maintain.html#Licensing-of-GNU-Packages
[20:43] <pitti> nnnn
[20:43] <StevenK> mmmm
[20:43] <pitti> oops, sorry
[20:43]  * ScottK thought bug numbers were up to nnnnnn.
[20:44] <StevenK> Soon it will be nnnnnnn. :-(
[20:44] <ScottK> Yep.
[20:44] <pitti> is there a prize for filing bug #1e6?
[20:45] <ScottK> That should be "on desktops"
[20:45] <ScottK> They've got ~5% on smartphones.
[20:50] <trism> pitti: I think the --exec-prefix=/ is in the wrong spot in the dbus package rules, it is overriding the --prefix flag on the test build, so those binaries are overwriting the main ones (sorry if you're the wrong one to poke, I just notice you did the merges)
[20:52] <pitti> trism: not sure that I follow -- the package seems to be fine, it ships dbus-daemon and some tools in /bin, as it should?
[20:53] <pitti> --prefix /usr is actually intended, as we want manpages, pkgconfig, include files and whatnot in /usr
[20:54] <cjwatson> the claim earlier today was that /bin/dbus-daemon (IIRC) was from the debug build pass rather than the regular one
[20:55] <stgraber> pitti: around?
[20:56] <trism> pitti: if you look at the build log, the dbus-daemon is copied twice to debian/tmp/bin, once from build/bus and again from build-debug/bus
[20:57] <mdz> stgraber, kees, pitti, cjwatson, soren, TB in 5
[20:57] <trism> pitti: so we get the one with all the DBUS_BUILD_TESTS sections enabled (the binary is twice the size of the one in debian)
[20:57] <mdz> ish
[20:57] <cjwatson> yep
[20:57] <pitti> mdz: o/
[20:58] <pitti> trism: ah, I see
[20:58] <pitti> trism: have a meeting now, would you mind filing a bug about it? (or just mail me, but bug is nicer for tracking)
[20:58] <trism> pitti: sure, I'll file a bug
[20:59] <pitti> trism: thanks!
[22:43] <broder> arges: backportpackage can't do that for local builds, but you could upload to a ppa - packages in a ppa can depend on other packages in a ppa
[23:04] <arges> broder, awesome., i'll give that a try then