[00:08] <doko> cjwatson, just sync libffi from experimental
[00:09] <doko> now synced
[00:10] <lifeless> infinity: you missed 'sbuild' for Ubuntu :P
[00:17] <infinity> lifeless: In intentionally didn't mention it, since it's not a sparate piece of software in the LP case, but a forked and embedded copy.
[00:18] <lifeless> infinity: ah, I thought you were listing the toolchains, not the things they develop
[00:18] <lifeless> LP doesn't want it to be a fork :) it just sucks at fixing that
[00:19] <infinity> It's on my TODO.  There are some things I want to address before I can do that.
[00:20] <infinity> (And, like Debian, it'll probably always have to be a fork, to a certain degree, but a lightly-modified branch, rather than a decade-old fork)
[00:20] <infinity> As in, Debian's buildd tools (buildd and sbuild) have infrastucture branches that are slightly different from the packaged versions, but merged into on a regular basis.
[00:22] <cjwatson> doko: ah, didn't notice, sorry.  thanks
[00:36] <Chipzz> infinity: what do you mean for "small local archive"? Lets say I have a big number of servers runnig debian/ubuntu, and I want to rebuild a certain number of debs for internal usage; would your definition apply?
[00:36] <Chipzz> infinity: also, what would you suggest in such a case?
[00:37] <infinity> Chipzz: Well, if it's a really small number of debs, just doing the builds by hand (or marginally scripted) with sbuild and then building a flat archive with dpkg-scanpackages or apt-ftparchive works fine.
[00:37] <infinity> Chipzz: You don't really need autobuildy infrastructure until you either have lots of arches or lots of packages (or both).
[00:38] <infinity> Chipzz: At which point, there are mid-range solutions out there like reprepro and mini-dinstall and such (which, admittedly, I have no experience with, but I hear they're simple enough).
[00:38] <Chipzz> it might be more convenient though (hack on the deb in your homedir, once done, upload to a server and have it built/being able to be deployed automagically)
[00:39] <infinity> Chipzz: And then if you're doing something nearly distro-sized, dak itself is likely the best bet, unless you're really comfy with doing local launchpad setups.
[00:39] <infinity> (Though, dak has gotten vaguely user-hostile lately too, I hear)
[00:40] <infinity> To each their own, mind you.  *shrug*
[00:40] <Chipzz> yea
[00:40] <Chipzz> I never got to the point of automating stuff on my last job
[00:40] <Chipzz> "Not their core business blablabla spend your time on sth more useful blablabla..." ;)
[00:41] <Chipzz> but it was something I was thinking about
[00:41] <Chipzz> one use case was to be able to keep providing php4 on newer distro's (dont ask :( )
[00:42] <infinity> Ew.
[00:42] <Chipzz> that's what you get when your colleague webmasters have an "It works now, so why would I change?" attitude :/
[00:43] <Chipzz> and management thinks "It works, why invest time and money that works now?"
[00:43] <Chipzz> +in something
[00:44] <Chipzz> with that attitude I didn't even bother trying to tell them about supportability etc, they just didn't see the value :(
[00:44] <infinity>  php5 (5.0.4-1) unstable; urgency=low
[00:44] <infinity>    * Initial PHP5 release; packaging forked from php4 4:4.3.11-1.
[00:44] <infinity>  -- Adam Conrad <adconrad@0c3.net>  Sat, 16 Jul 2005 23:42:36 +1000
[00:44] <infinity> So, uhm.  They really like to live in the past, I take it?
[00:45] <Chipzz> "We're a publishing company, not an IT company. Updating our sites is a waste of time and money when there are some many other things to build"
[00:45] <Chipzz> at which point I didn't even bother...
[00:46] <Chipzz> and the attitude of my colleagus being very similar, well..
[00:46] <Chipzz> good thing I'm gone there now, SEP
[00:47] <Chipzz> first thing my successor did when he started there was upgrading php, beside me having it pinned in preferences. Hilarity ensues :)
[00:47] <Chipzz> but "Not my problem anymore now" :)
[07:03] <pitti> Good morning
[07:07] <Dedunu1> good morning
[07:46] <dholbach> good morning
=== smb` is now known as smb
[09:32] <captainlinux> Guys how do you think, is it better to kind of merge webapp icons with applications which are calling them? I mean - the more tabs I open in my firefox the more webapps get called and at the end my dash is full of useless icons which I don't even touch. Wouldn't it be better just to change the Icon of Firefox according to the active webapp and to change the icon every time you change the tab calling another webapp?
[09:32] <ogra_> captainlinux, try #ubuntu-app-devel
[09:32] <ogra_> (see topic)
[09:33] <captainlinux> Oh, thanks!
=== yofel_ is now known as yofel
=== henrix_ is now known as henrix
=== zz_jackyalcine is now known as jackyalcine
=== jackyalcine is now known as jackyalcine_
=== jackyalcine_ is now known as zz_jackyalcine
[11:29] <pete-woods> has anyone got a nice link to how you're supposed to implement cancellable dbus methods serverside?
[11:29] <pete-woods> basically I have a compiled dbus interface (where it emits signals in response to client-side method calls)
[11:30] <pete-woods> and I can't see where you connect to the gcancellable
[11:35] <xnox> pete-woods: this is not really relevant for this channel, as we develop ubuntu itself here. Not general programming for/on ubuntu. But it'd recommend to look into udisks2 which implements that in it's API.
[11:35] <xnox> (over dbus)
[11:35] <pete-woods> xnox: thanks for the info (again) :)
=== zz_jackyalcine is now known as jackyalcine
[11:51] <mlankhorst> cjwatson: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1121179 ?
[11:51] <ubottu> Ubuntu bug 1121179 in mesa (Ubuntu) "Ubuntu 12.04.2 alternate AMD 64 ISO image Feb 10 installing mesa 8.0.4 not 9.0.0 - LTS quantal" [Undecided,New]
[11:56] <infinity> mlankhorst: Fun.  We may have missed some seed changes that affect how alternates are built.
[11:57] <mlankhorst> seems so
[11:58] <infinity> And by "might have missed", I mean "may not have done at all"... Hrm.
[11:59] <infinity> How the heck is the new ubuntu-meta being built correctly?
[12:02] <ogra_> infinity, hmm ? did it change ?
[12:02] <infinity> Oh, crap.  We did it all in livecd-rootfs, and skipped updating seeds.
[12:02] <ogra_> oh, thats 12.04.2
[12:03] <xnox> well Feb10 image - is it .2 or candidate?!
[12:03] <infinity> xnox: Yes.
[12:05] <infinity> cjwatson: Your clever plan to do xserver-xorg-lts-quantal entirely in livecd-rootfs and skip making seed changes makes alternates sad.
[12:11] <infinity> cjwatson: Perhaps a debian-cd hack to s,tasksel/first,pksel/install-pattern, and use "*buntu-desktop xserver-xorg-lts-quantal"... That would sort of match the livecd-rootfs change.  Though, we might need to be more clever to get the right packages on the CD in the first place.
[12:14] <cjwatson> I probably forgot about alternates because we've stopped building them elsewhere ...
[12:14] <infinity> Well, stopping building them is also an option. :P
[12:14] <cjwatson> And it's not so much that we skipped updating seeds as that we determined we *couldn't* do it that way
[12:14] <cjwatson> Not for 12.04
[12:15] <infinity> Well, seed updates would have no effect on the archive, but they WOULD affect CDs, since CDs are based on fresh germinate runs, no?
[12:15] <cjwatson> TBH: I'm at least half-tempted to just release-note that the alternates get you the old stack
[12:15] <cjwatson> Oh, true
[12:15] <cjwatson> Well, I'm on leave today: if you want to give it a try and respin then be my guest :)
[12:16] <infinity> I'm guessing it might be as simple as just adding xserver-xorg-lts-quantal to the appropriate desktop seeds and praying germinate does the right substitution and culling.
[12:16] <infinity> But it's never that simple.
[12:17] <cjwatson> I think that should be all you need
[12:17] <infinity> I'll give it a whirl.  Easy enough to back out and release note if it ends up a tangled mess.
[12:17] <cjwatson> Since germinate marks everything in the seeds as installed before attempting to resolve broken dependencies
[12:18] <cjwatson> (Much like apt)
[12:18] <infinity> Enjoy your leave.  Thanks for popping in to be a sounding board.  Shoo.
[12:33] <yofel> cjwatson, infinity: question about the new LTS stack: yesterday we were wondering in #kubuntu-devel how the hell that's supposed to work. Are the changes in livecd-rootfs also applied to the flavour images or what do we need to do to get the new stack?
[12:33] <yofel> currently we only have the kernel change in the seed
[12:34] <cjwatson> you need to have asked for it a couple of weeks ago if you want it for a given flavour for .2
[12:34] <yofel> that was documented... where?
[12:34] <cjwatson> it'll need a livecd-rootfs SRU and er I think something else
[12:34] <cjwatson> probably wasn't, sorry
[12:34] <yofel> *sigh*
[12:34] <yofel> nevermind
[12:34] <yofel> we'll rever the kernel then
[12:34] <cjwatson> because this all got dumped on *me* rather too late to coordinate anything properly
[12:34] <yofel> *revert
[12:34] <cjwatson> eh
[12:34] <yofel> heh
[12:34] <cjwatson> how do you already have an updated kernel?
[12:35] <cjwatson> because that's handled in the same place ...
[12:35] <yofel> cjwatson: we changed the seed, so our current test image has kernel 3.5 + mesa 8
[12:35] <cjwatson> that was silly :)
[12:35] <cjwatson> yeah, revert that and ask for a respin please
[12:35] <yofel> well... yeah
[12:35] <yofel> Riddell, ScottK ^
[12:35] <Riddell> yofel: currently talking in #ubuntu-release
[12:35] <cjwatson> seriously, major structural changes like that it's best to consult with the person coordinating the point release ...
[12:36] <yofel> ah, good
[12:36] <Laney> what is guanabana?
[12:37] <marga> Does anyone here understand the interaction between dconf and gsettings?
[12:38] <marga> Supposedly, dconf is a backend for gsettings
[12:38] <marga> But I'm seeing a bug where something set with gsettings does not match the value set with dconf.
[13:03] <Riddell> didrocks: bonjour, kde 4.10 est tout bon en raring, ou somme-nous avec qt 5?
=== Zic is now known as Guest90771
=== Guest90771 is now known as Zic
[13:04] <didrocks> Riddell: salut! I uploaded the qt4-compatible with qt5, we'll get a quick review of qtchooser. Qt5 itself is in the pipe, but still polishing the packaging with review and rereview :-)
[13:05] <Riddell> didrocks: qtchooser looks like it's in
[13:05] <didrocks> Riddell: yeah, we need a post-MIR though
[13:06] <Riddell> didrocks: who needs it in main?
[13:06] <Riddell> oh for qt
[13:06] <Riddell> of course
[13:06] <didrocks> yep :)
[13:06] <Riddell> didrocks: I see qtbase-opensource-src  and qtscript-opensource-src in New, shall I review?
[13:07] <didrocks> Riddell: seb128 is doing the first review pass, but maybe he could use some help :-)
[13:08] <didrocks> qtscript is already under way and there are some copyright issues, so refixing soon
[13:08] <seb128> Riddell, I found copyright issues with qtscript, if you want to review qtbase or start on it please do, there is lot to review there
[13:09] <Riddell> seb128: I'll take a look, what was up with qtscript?
[13:10] <seb128> Riddell, debian/copyright is incomplete, e.g src/3rdparty/javascriptcore/JavaScriptCore/profiler/ProfileGenerator.cpp is copyright apple and under BSD and the debian/copyright doesn't list apple at all and has this one under LGPL
[13:11] <dhanasekaran> Guys Where i can find, kernel related release notice please guide me
[13:12] <ogra_> on launchpad or in /usr/share/doc/<packagename>/changelog.gz
[13:13] <ogra_> (also probably more appropriate for #ubuntu-kernel)
[13:13] <Riddell> seb128: oh I see packaging issues rather than upstream
[13:14] <Riddell> it's only 45MB, should be a quick review :)
[13:24] <Daviey> xnox: no smart proxy :(
[13:25] <xnox> Daviey: I am working on it as a hobby project =) but it's not a work priority for me.
[13:25]  * xnox wishes for xnox-personal work items
[13:25] <xnox> Daviey: currently still prototyping. Hoping to have something working in a few weeks.
[13:26] <xnox> well 3-4 evenings of working on it.
[13:26] <Daviey> xnox: that is wonderful!
[13:31] <bdrung> Sweetshark: should i upload 4.0 beta2 today or do you want to merge the 4.0 final first?
[13:35] <infinity> seb128: If single files are BSD, the entire source can be GPL, that's not a conflict at all.
[13:36] <seb128> infinity, right, be shouldn't debian/copyright list those are BSD sources? in any case that's not the only issues, some files were listed under a wrong license in there and some copyright holders are missing
[13:36] <infinity> seb128: And if individuals files carry different copyright owners, that also doesn't necessarily need to be shown (see the kernel as a prime example).
[13:36] <infinity> seb128: "Linus Torvalds and others", we don't list every single copyright header.
[13:37] <infinity> seb128: And we list the kernel as being GPL, despite plenty of individual files being BSD or other free licenses that have no conflict with being relicensed as GPL.
[13:37] <seb128> bdrung, thanks for the libreoffice review, it seems that you found mostly small problems ... does it raise your confidence for Sweetshark ppu application? ;-)
[13:38] <seb128> infinity, ok, well it seems weird that if apple contributed a good part of the code in there to not have it listed in the copyright holders list
[13:38] <seb128> infinity, if that list is incomplete and lack some of the major contributors and that's ok what's the point of having it at all?
[13:39] <infinity> seb128: We don't list Freescale, Marvell, Intel, etc as copyright holders to the kernel.
[13:39] <seb128> infinity, note that I would be happy to just see debian/copyright being optional :p
[13:39] <seb128> infinity, well my german mind says either we care about copyright and it should be right or we don't care and why bother :p
[13:40] <Sweetshark> bdrung: I would go for uploading 4.0 beta2. Im back to work today and wading through a 4300 email backlog from the last two weeks. I will bump to 4.0 soonish then.
[13:40] <infinity> seb128: I dunno.  Others would disagree with me and want copyright to be nit-pickingly complete, but if it covers the license of the project as a whole, and no individual files stand out as contradicting that, it doesn't need to note everything that's more relaxed.
[13:40] <bdrung> seb128: ping me after the dmb meeting.
[13:40] <infinity> seb128: The "and others" bit is important if you're just listing one upstream copyright contact, mind you.
[13:40] <seb128> bdrung, ok
[13:41] <bdrung> Sweetshark: will you apply the patches i sent you and regenerate the source?
[13:41] <infinity> seb128: And I haven't looked at the one you rejected in particular, if it literally has two copyright holders, listing the two is easy.  But if it has hundreds (which is true of most OSS projects), why single out the "major contributors" as different from the guy who has copyright on one file?
[13:43] <seb128> infinity, well, I learnt to be picky and I usually list all the copyright holders because I though it was the way it should be done
[13:43] <seb128> infinity, e.g I would list 100 lines if there is 100 of those to list :p
[13:43] <seb128> infinity, but I never understood the point of listing copyright holders in debian/copyright to start with
[13:43] <infinity> seb128: It's certainly not wrong to list them all.
[13:44] <seb128> infinity, if the list can be incomplete then it could as well go missing...
[13:44] <infinity> seb128: I think it's mostly a fiction that copyright holders are useful in debian/copyright, I agree with you.  What matters is the licenses, the source files themselves list the copyright holder.  But not an argument I'd want to get into.
[13:44] <seb128> hehe, same here ;-)
[13:45] <infinity> seb128: (Now, in the case when the source DOESN'T list the copyright holders, then having it in debian/copyright is important, as is often the case with the entirety of debian/* for instance)
[13:45] <infinity> Because a license means nothing without a copyright holder granting it.
[13:46] <Sweetshark> bdrung: I will try to apply the patches and push them to the repo and regenerate the source today still.
[13:46] <bdrung> Sweetshark: thanks. ping me when done and i will do the upload.
[13:46] <Daviey> infinity: The real inconsistency is that once accepted, debian/copyright is rarely/never updated to reflect new AUTHORS.
[13:47] <Sweetshark> bdrung: willdo. thanks for the review work!
[13:47] <infinity> seb128: I dunno.  I just probably wouldn't reject on an "and others." copyright statement is all I'm saying.  Others might.  And maybe it would be good to have the kernel list every single copyright holder in debian/copyright to appease some people's sensibilities.
[13:47] <bdrung> Sweetshark: you're welcome.
[13:48]  * infinity is somewhat glad his major package is an FSF one that has a single copyright holder, and he can pretend not to care.
[13:48] <seb128> infinity, thanks for the input, I will be a bit more relaxed on NEW review and copyright holders after that discussion ;-)
[13:49] <infinity> seb128: Licenses, on the other hand, are much more meaningful.  You need to make sure nothing conflicts with the overall project license (if it's GPL/LGPL/MPL/etc).
[13:50] <infinity> seb128: Luckily, people mixing BSD/MIT/expat code into GPL projects is pretty much a non-issue, so you get to gloss over it.  We can just distribute the project as a whole as "GPL" and be done with it.
[13:50] <davmor2> n
[13:51] <infinity> seb128: (Not that it's wrong to list each individual license, but I'd contend that any user who wants to know that src/lib/function.c is BSD is going to be reading the source anyway, cause he wants to use the file, and he'll find out then)
[13:51] <seb128> infinity, right, that's not the case there, the sources are Qt style: e.g LGPL-2.1 with qt exception or GPL-3 and there are a bunch of BSD files in the middle of the tree
[13:52] <infinity> Again, some people will argue that you should list the license for every file.  And totally not wrong to do so.  Just also not a legal issue if you don't, as long as the project license as a whole isn't incorrect because of those files.
[13:53] <infinity> seb128: The kernel again being a canonical example here, distributed as GPL-2, but a ton of the code in there is actually MIT/BSD/expat.
[13:53] <seb128> infinity, right, I got it, thanks for the details ;-)
[13:54] <infinity> (Same story with glibc, actually, which actually has a TON of 4.4BSD-derived code that was donated by UCB and they even kindly dropped the advertising clause to avoid license conflicts)
[13:54] <infinity> Very entertaining headers.  The licenses have clause 1, 2, 4.  3 just mysteriously went missing.
=== Ursinha-afk is now known as Ursinha
[14:00] <mdeslaur> Sweetshark: mind if I merge boost1.49?
[14:01] <infinity> mdeslaur: I don't think anyone wants TIL on boost.
[14:01] <infinity> mdeslaur: But if you take it, remember to do boost-mpi to match, or the world explodes.
[14:03] <mdeslaur> infinity: oh! thanks for the hint
=== jackyalcine is now known as zz_jackyalcine
[14:19] <marga> This is the bug I was mentioning earlier: https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/1122028
[14:19] <ubottu> Ubuntu bug 1122028 in glib2.0 (Ubuntu) "gsettings does not respect dconf locks" [Undecided,Confirmed]
[14:20] <marga> In certain situations, gsettings and dconf values differ.
[14:20] <marga> I'm trying to chase this, but it's a big monster, I'd appreciate any pointers.
[14:22] <seb128> marga, hey, can you try pinging desrt on #ubuntu-desktop about it? he wrote gsettings/dconf and is maintaining those for us
[14:23] <marga> oh, I looked for him here.
[14:23] <marga> Sure
[14:25] <vibhav> Is there any documentation on adding Multi-Arch support for packages?
[14:26] <dobey> seb128: btw, did you not upload with my patch for bug #859600 ? :)
[14:26] <ubottu> bug 859600 in gnome-keyring (Ubuntu Precise) "Please convert gnome-keyring to multiarch" [High,In progress] https://launchpad.net/bugs/859600
[14:26] <stgraber> ScottK: congrats!
[14:27] <ScottK> Thanks.
[14:27] <seb128> dobey, doh, will do today!
[14:29] <dobey> seb128: thanks :)
=== wedgwood_away is now known as wedgwood
[14:42] <Sweetshark> mdeslaur: sounds good to me, and yeah: infinitys hint is well worth its bits and bytes ...
[14:45] <mdeslaur> Sweetshark: thanks
=== pinky is now known as brianchid
=== Quintasan_ is now known as Quintasan
[15:32] <cjwatson> vibhav: http://wiki.debian.org/Multiarch/Implementation
=== henrix is now known as henrix_
[15:38] <vibhav> cjwatson: thanks!
=== henrix_ is now known as henrix
=== sil2100_ is now known as sil2100
[16:01] <mlankhorst> is it just me or is there no xorg package set for quantal?
[16:01] <Laney> seems likely
[16:01] <Laney> they are per-series
[16:02] <Laney> stgraber: ^- care to copy?
[16:04] <stgraber> I can do that yes
[16:04] <stgraber> mlankhorst: do you need something else than quantal too? (I try to avoid unnecessary copies as keeping them all in sync is a pain)
[16:05] <stgraber> (done for quantal)
[16:06] <vibhav> hmm, The wayland ABI/API are still not fixed, right?
[16:09] <Laney> stgraber: I could imagine a -S all that does the smarts to apply packageset operations uniformly
[16:10] <stgraber> Laney: well, you're assuming we have the same source packages everywhere ;) we don't, especially for xorg where they have a bunch of special ones for LTS
[16:10] <stgraber> and sometimes things end up moving between packagesets between releases too (thinking of the desktop one)
[16:11] <stgraber> so yeah, we probably could make the scripts a bit less painful, but covering all the weird cases will be tricky
[16:11] <Laney> Well I don't believe that they have to exist in that series, merely to have an SPPH at all.
[16:11] <Laney> That's how you can get packagesets out of sync with the archive in the case of removed packages, for example
[16:11] <stgraber> yeah, I try to avoid that though as it makes pretty confusing reports ;)
[16:14] <Laney> It could also do the conservative thing and check which series the package exists in
[16:21] <SpamapS> Hrm, something with X in raring is making synergy do weird things
[16:21] <SpamapS> keyboard presses are held too long often... so I get lots of ..............'s or aaaaaaaaa's
[16:22] <SpamapS> modprobe: ../tools/modprobe.c:550: print_action: Assertion `kmod_module_get_initstate(m) == KMOD_MODULE_BUILTIN' failed.
[16:22] <SpamapS> Aborted (core dumped)
[16:22] <SpamapS> doh, and there's this
[16:23] <SpamapS> weird why isn't apport pppppppppppppppicking that uuuuuuuuuuuuuup?
[16:23] <SpamapS> ^^ argh
[16:24] <hyperair> eh whenever synergy times out or gets interrupted in mid-keystroke that happens
[16:24] <Laney> SpamapS: https://bugs.launchpad.net/ubuntu/+source/kmod/+bug/1073062
[16:24] <ubottu> Ubuntu bug 1073062 in kmod (Ubuntu) "modprobe: Assertion `kmod_module_get_initstate(m) == KMOD_MODULE_BUILTIN' failed" [Undecided,Confirmed]
[16:28] <SpamapS> Laney: cool, +1'd
=== Mirv_ is now known as Mirv
=== henrix is now known as henrix_
=== henrix_ is now known as henrix
=== deryck is now known as deryck[lunch]
=== zz_jackyalcine is now known as jackyalcine
=== jackyalcine is now known as jackyalcine_
=== Ursinha is now known as Ursinha-afk
=== jackyalcine_ is now known as zz_jackyalcine
=== Ursinha-afk is now known as Ursinha
=== zz_jackyalcine is now known as jackyalcine
[17:47] <seb128> Riddell, thanks for qtbase review, do you think you have any time for qtdeclarative as well? ;-) (I'm reviewing qtscript and qtmultimedia)
[17:49] <Riddell> seb128: QtQuick?  it'll be a quick one!
[17:49] <Riddell> I'll take a look
[17:52] <seb128> Riddell, thanks ;-)
[18:22] <alexlist> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1122278
[18:22] <ubottu> Ubuntu bug 1122278 in ubiquity (Ubuntu) "ubiquity hangs when existing LVM volumes are present" [Undecided,New]
[18:24] <xnox> alexlist: thanks. it is probably a dupe of existing hang, but your steps to reproduce it are much easier for me to follow.
[18:24] <xnox> i'll see if i can strace it and hopefully fix it for good.
=== deryck[lunch] is now known as deryck
[18:43] <mjt> how bad is to have a package in Suggests: whcih is not in ubuntu but is available in debian?
[18:51] <alexlist> xnox: you're welcome. For the time being, I wiped the disks and just installed on 1 disk, will ad SW raid later. But I guess there are many users out there who want RAID1 on two disks in a workstation  ....
[18:52] <JontheEchidna> mjt: usually it's not considered worth making a delta between debian/ubuntu, especially if that would be the only difference (iirc)
[18:52] <xnox> mjt: happens all the time =) it's totally fine.
[18:53] <mjt> heh ok
[18:55] <infinity> mjt: Which package is that?
[18:55] <mjt> qemu
[18:55] <mjt> suggests vde2
[18:55] <infinity> mjt: I meant the suggests.
[18:55] <mjt> which has been rejected by the security team iirc
[18:56] <hallyn> looks like i was wrong then - excellent
[18:56] <infinity> mjt: It's in Ubuntu.
[18:56] <mjt> hallyn: ^^ ;)
[18:56] <mjt> heh. so much fuzz... ;)
[18:57] <mjt> or buzz
[18:57] <infinity> It's in universe, not main, but that's not a problem.  We only follow recommends for component promotions, not suggests.
[19:02] <jbicha_> happyaron: can I lower the ibus-table dependency in Ubuntu on ibus to 1.4.2?
[19:13] <happyaron> jbicha_: let me check
[19:14] <jbicha_> happyaron: or we should have you do it to exercise your new upload powers? :)
[19:15] <happyaron> jbicha_: that could be a good idea, :)
[19:16] <happyaron> but please bear me a bit more time to learn about the difference between upload queues of ubuntu and debian.
[19:17] <jbicha_> happyaron: sure, feel free to ask questions if you need help too
[19:20] <jbicha_> (I'm thinking it's probably too late in the raring cycle for ibus 1.5 as it's a bit disruptive :) )
[19:21] <happyaron> jbicha_: for 1.5, see my short discussion in -desktop with seb128
[19:22] <happyaron> jbicha_: I think ibus-table 1.5 is okay for ibus 1.4.2, but if you don't have a good reason then there's no need to take the potential risk.
[19:23] <jbicha_> happyaron: thanks for the pointer, we're definitely interested in ibus 1.5, we just don't want to pass breakage along to our users
[19:23] <happyaron> I see. Unfortunately 1.5.1 brings more breakges, :(
[19:24] <jbicha_> we already have ibus-table 1.4.99 in raring, and 1.5.0-1 is in raring-proposed (but can't auto-migrate to raring because of the unsatisfiable dependency)
[19:24] <jbicha_> https://launchpad.net/ubuntu/+source/ibus-table
[19:24] <jbicha_> autosync from Debian unstable hasn't been turned off yet
[19:24] <happyaron> I see.
[19:25] <happyaron> then lower the dependency is okay.
[19:25] <jbicha_> if that version has issues, we could do a 1.5.0+really1.4 or whatever if needed...
[19:25] <jbicha_> happyaron: ok I'll let you try to handle that upload then?
[19:26] <happyaron> ok
[19:26] <happyaron> so the only differece here is ubuntu needs a source-only upload, I think?
[19:28] <barry> dobey: how goes those u1 oauth branches?
[19:29] <jbicha_> happyaron: yes that's the biggest difference from uploading to Debian
[19:31] <happyaron> jbicha_: debdiff http://paste.ubuntu.com/1637302/
[19:32] <jbicha_> happyaron: that looks perfect to me :)
[19:33] <happyaron> ok, signing and uploading
[19:36] <happyaron> jbicha_: done, got the email, :)
[19:38] <dobey> barry: working on it
[19:44] <barry> dobey: thanks
=== scott-work_ is now known as scott-work
=== jbicha_ is now known as jbicha
[20:05] <catbus1> smoser: ping
[20:06] <smoser> catbus1, hey
[20:07] <catbus1> smoser: about bug 1115710, do we still need to have /etc/modprobe.d/mlx4.conf if mlx4_en specifies PCI IDs?
[20:07] <ubottu> bug 1115710 in module-init-tools (Ubuntu Quantal) "Mellanox mlx4_en network driver is not automatically loaded" [Medium,Triaged] https://launchpad.net/bugs/1115710
[20:07] <smoser> catbus1, no.
[20:08] <smoser> catbus1, are you implying that mlx4_en might have/get pci-ids ?
[20:08] <smoser> this was/is the upstream decision to load that _core module on pci-id. and then basically require user-configuration for loading other stuff.
[20:10] <catbus1> smoser: no, I am not implying they will. if mlx4_en is important to be loaded in the boot path, maybe it should specify so it gets auto loaded.
[20:12] <smoser> catbus1, you're right that that is probably ultimately the right place for the fix.
[20:13] <smoser> i was surprised, though, that upstream kernel had this as it is for so long. as if it is working as expected.
[20:20] <catbus1> dduffey: ^^^
=== Nigel_ is now known as G
=== ximion is now known as ximion-afk
[20:58] <barry> dobey: looks like a linting is not so smart, unless there's some other reason why 10 skips and 766 successes still causes the merge tests to fail. :/
[21:01] <dobey> barry: pep8 complained about your indentation change of a closing paren in the imports line. reverting the change will fix it (i added comments to the MP about it)
[21:02] <LantzR> Hiya. I created a new ppa:  bzr push  lp:~lantzr/+junk/cup-pdf-zel which was ok. What I do not understand is why it moved to lp:~Ubuntu-Etherpad/+junk/cup-pdf-zel
[21:02] <barry> dobey: oops, sorry about that.  (i try not to fix whitespace even when it's wrong <wink>, but i hit tab on that line or something.)
=== henrix is now known as henrix_
[21:05] <dobey> LantzR: you probably want #launchpad or #bzr for help with that. i don'tk now why that would happen outside of you typing the wrong thing or something, though
[21:08] <LantzR> Thx dobey. It was under me most of last night ... then moved
[21:09] <dobey> LantzR: https://answers.launchpad.net/launchpad and ask a question about it, and someone will look into it
[21:10] <barry> dobey: revert pushed
[21:11] <dobey> thanks
=== doko_ is now known as doko
[21:42] <dobey> barry: doh; i didn't notice this before your branch landed (which i am surprised it did), but ubuntu_sso/utils/webclient/tests/test_webclient.py still has "from oauth import oauth" and doesn't import oauthlib
[21:43] <barry> dobey: oh crap
[21:43] <barry> dobey: yeah,that will break test_iri_parameters_used_in_oauth_signature() :(
[21:43] <barry> dobey: let me work on a branch for that
[21:44] <dobey> well, it didn't break is the thing. the branch landed :-/
[21:44] <dobey> thanks
[21:44] <barry> dobey: right, removing the import will though ;)  my grep just missed it :(
[21:47] <barry> dobey: actually, i think that test can be removed, but please double check me.  all it's doing is ensuring that 'fake_param' is in the parameters when the low-level oauth.OAuthRequest.from_consumer_and_token() is called.  but that will never be called, so who cares?  it's kind of a silly test ;)
[21:49] <dobey> barry: hrmm, yeah. i don't see that being used in software-center or ubuntuone-client either
[21:50] <dobey> there's something in ./ubuntu_sso/utils/tests/test_common.py that does something with from_consumer_and_token though; which should probably get axed as well
=== jackyalcine is now known as zz_jackyalcine
[21:51] <barry> dobey: should i just kill the whole FakedOAuthRequest class?  doesn't seem to be used anywhere
[21:52] <barry> dobey: tests pass, so "yes" i guess ;)
[21:52] <barry> https://code.launchpad.net/~barry/ubuntu-sso-client/no-mo-o-oauth/+merge/147781
[21:53] <dobey> barry: if it's not used and doesn't break tests, i'd say sure
[21:54] <barry> dobey: cool.  mp all up2date-y
=== StevenK_ is now known as StevenK
[22:23] <bdrung> Sweetshark: i am doing the final test build, which probably will end when i sleep and i will do the upload tomorrow.
[22:41] <dobey> barry: mmcc posted a needs-fixing. looks like the test is useful, so probably should stay, but the use of oauth directly can go away
[22:41] <barry> dobey: looking
[22:46] <Sweetshark> bdrung: I did a test-build with your patches here and it completed and passed the tests. I only wanted to review the debdiff to the last version I put on people.canonical.com once more (and punted that for tommorrow morning).
[22:47] <bdrung> Sweetshark: have you seen the mail to rene and you with six additional patches?
[22:48] <bdrung> Sweetshark: one thing to do before the upload is to update the date in the changelog stanza
[22:51] <Sweetshark> bdrung: hmm, I seem to have missed that one.
[22:51] <bdrung> Sweetshark: sent 20 minutes ago
[22:51] <Sweetshark> bdrung: have some mercy with me, wrangling down a 4300 msg inbox today.
[22:51] <bdrung> Sweetshark: i know that feeling. :)
[22:54] <Sweetshark> bdrung: found it, will sync with rene about it tomorrow to move them to the debian branch ASAP.
[22:56] <bdrung> thanks.
[22:56] <bdrung> Sweetshark: after looking closer at the packaging, i am all in for rebooting the packaging.
[23:00] <barry> dobey: updated
[23:01] <dobey> thanks
[23:03] <Sweetshark> bdrung: yep. IMHO that has to start upstream. The .deb packages created by the upstream packaging at LibreOffice (using the desaster of the old OOo packaging system) are that broken that there is luckily not much one can break by touching them (except that debian/ubuntu packaging is build on top of it via this gid2pkgdirs.sh voodoo).
[23:04]  * bdrung nods.
[23:04] <bdrung> packaging should only be i tiny wrapper around the upstream build system.
=== kentb is now known as kentb-out
[23:04] <Sweetshark> bdrung: moving the packaging logic there proper (instead of using half of it and then moving and splitting stuff around later) would be a huge win.
=== robbiew is now known as robbiew-afk
[23:05] <bdrung> yes
[23:05] <dobey> barry: hrmm, that doesn't seem right. body would be text, not a dict, no?
[23:05] <bdrung> that's what a build system is for
[23:06] <dobey> barry: and headers should have more in it than just the params
[23:07] <barry> dobey: in oauthlib i think body can be either text or a dict.  in this case because the parameters are being passed in as a dict (and auto-converted internally due to Content-Type: application/x-www-form-urlencoded), then the come out as dict from oauth_client.sign()
[23:08] <barry> dobey: but it's possible that i don't fully understand how build_oauth_request() is supposed to be used
[23:09] <dobey> barry: hrmm, if that's true, i think that's a bug in oauthlib then. body should always be text
[23:09] <Sweetshark> bdrung: the build system itself has mostly finished the migration to sane gbuild (which is essentially plain GNU make), but the upstream packaging is still quite messy: perl and C preprocessor macro madness (hmm, at least m4 seems to be dead and gone there now ... \o/)
[23:09] <Sweetshark> anyway ...
[23:09]  * Sweetshark is gone for the night.
[23:09] <bdrung> Sweetshark: why care about upstream packaging?
[23:10] <barry> dobey: the api for Client.sign() says it can be a "dict, a list of 2-tuples, or a formencoded string"
[23:10] <bdrung> packaging should be done by the distribution and upstream can use that packaging.
[23:10] <bdrung> Sweetshark: does upstream generate the debian/ files via a script?
[23:11] <dobey> barry: i don't understand why body would ever be anything other than None, or a form encoded string. anything else just doesn't make sense in the context of what a body is
[23:12] <barry> dobey: i think the motivation is that if the client got form data as a dict, it wouldn't have to formencode it itself, the oauthlib library would do that as a convenience.
[23:12] <barry> (list-o-2-tuples and dicts being essentially equivalent)
[23:13] <barry> s/client/user of the library/
[23:13] <Sweetshark> bdrung: I never looked closely at that, but IIRC the upstream packages are just created using some cruel hacks around epm.
[23:13] <dobey> barry: i think everything using this api, expects it to be a string, as it's going directly to the web
[23:14] <bdrung> Sweetshark: then let's don't care about it. rebooting the packaging can start (as gbuild should be there)
=== matttbe_ is now known as matttbe
[23:15] <bdrung> Sweetshark: starting with it now has the advantage of safely landing in raring+1
[23:15] <dobey> barry: on the other hand, i can't find any external users of that API either
[23:15] <dobey> barry: it just seems very odd to me for an api to do that
[23:16] <barry> dobey: could be yeah, but i guess upstream has its reasons ;)
[23:17] <barry> dobey: otoh, build_oauth_request() could *not* convert the query params into a dict, then it would just send them into .sign() as formencoded.  that might make sense as it saves a roundtrip from formencoded->dict->formencoded
[23:18] <barry> dobey: it wouldn't change this test though because Client.sign() would still return a dict (i think, would have to try it)
[23:19] <Sweetshark> bdrung: the package split is used on all platforms in some form (e.g. for the msi splits on windows and for the way the rpms are split).
[23:19] <Sweetshark> bdrung: and we are still depending on in multiple ways: This stuff is a/ also used in 'make install' and 'make dev-install' (which are essentially 'package to directory' targets) and in the current debian/ubuntu packaging via the gid2pkgdirs.sh script, which extracts the upstream packaging split for debian/ubuntu as a base and then modifies and tweaks some of it.
[23:19] <barry> dobey: anyway, i'm certainly willing to do what you think is right, given upstream's api
=== maco_ is now known as maco
[23:20] <dobey> barry: query parameters aren't formencoded though. that's the whole point :)
[23:20] <Sweetshark> bdrung: What I would love to have would be something like 'make install PKG=libreoffice-core' or somesuch upstream to install each package in a debian/ package dir.
[23:21] <dobey> barry: and given the description of upstream's api, i can't easily predict what will happen :-/
[23:21] <bdrung> Sweetshark: isn't it possible to install everything in debian/tmp and then split by directory and * wildcard?
[23:22] <bdrung> that's what smaller packages do
[23:24] <Sweetshark> bdrung: nah, that wouldnt work too well. The LibreOffice install layout is vastly different from what you want in a debian/ubuntu system.
[23:25] <barry> dobey: probably best not to guess then!  which i think means build_oauth_request() not passing in a dict, but encoding the parameters itself, do you think?
[23:25] <Sweetshark> bdrung: as for getting this done for raring+1: that depends on priority and thus is not my call -- I have some other things raised on my list of TODO that have priority for Canonical.
[23:25] <bdrung> Sweetshark: maybe it's time to get upstream follow the FHS
[23:26] <bdrung> pictures should go to /usr/share
[23:26] <dobey> barry: i think i need to read the oauthlib code for that call, because their API design is rather unfortunate since I have no idea why you're passing the Content-Type header in at all, and your description of the API worries me
[23:26] <bdrung> Sweetshark: whom could i talk to to get it raised?
[23:27] <Sweetshark> bdrung: libreoffice@lists.freedesktop.org patches welcome ;)
[23:28] <barry> dobey: okay.  it's entirely possible i'm smoking something ;)  do take a look and let me know what you think.  i'm going afk now, but let's touch base tomorrow (or just update the m-p).  also, upstream is very friendly, so if you think their api is whack, please file a bug at https://github.com/idan/oauthlib
[23:28] <bdrung> -ENOTIME
[23:29] <Sweetshark> bdrung: the tricky part is when touching URE etc. one has to be careful not to break the stable ABI promise.
[23:30] <Sweetshark> bdrung: ;)
[23:30] <Sweetshark> anyway ... really gotta go, n8
[23:30] <bdrung> good night
[23:40] <dobey> need to go as well