[01:11] <aljosa_> i'm looking for a technical mailing list where i can ask questions about rpm/deb formats and similar topics. is there some place where rpm/deb developers communicate?
[01:13] <Keybuk> aljosa_: to my knowledge, rpm and deb developers do not communicate with each other
[01:16] <aljosa_> Keybuk: really? do you know why?
[01:17] <Keybuk> aljosa_: because they have nothing to talk about, I guess
[01:29] <RAOF> Anyone available to sponsor a quick xserver-xorg-video-intel upload?
[01:29] <StevenK> I might be
[01:30] <RAOF> http://cooperteam.net/Packages contains the relevant source.
[01:31] <StevenK> RAOF: 2.14.0-1ubuntu2 ?
[01:31] <RAOF> StevenK: Indeed.
[01:31] <RAOF> I can throw you up a debdiff if you'd like, too.
[01:33] <StevenK> RAOF: Uploaded.
[01:33] <RAOF> StevenK: Thanks muchly!
[01:34] <RAOF> In case I haven't pointed you at it, https://wiki.ubuntu.com/ChrisHalseRogers/CoreDevApplication
[01:34] <RAOF> :)
[01:35] <StevenK> RAOF: Ah, let me scribble over that for you
[01:38] <ari-tczew> RAOF: I guess that DMB will tell on meeting that you have endorsements only from Canonical friends :P
[01:38] <broder> hmm...i would have sworn i sponsored something for RAOF...
[01:39] <StevenK> ari-tczew: I've known and sponsored stuff for RAOF before we both worked on Canonical, so ...
[01:39] <StevenK> s/on/at/
[01:40] <StevenK> RAOF: Application endorsed.
[01:40] <RAOF> StevenK: Thanks.
[01:42] <ari-tczew> StevenK: Don't get me wrong. DMB just making sure that there is no favoritism.
[01:43] <StevenK> ari-tczew: I think it's bunk. People that he commonly works with are commenting on his work. If RAOF just got given core-dev, *then* there would clearly be favoritism.
[01:43] <persia> ari-tczew, Don't fuss about it too much.  Most DMB members have been around a long time, and tend to know who folk are to some degree.
[01:44] <ari-tczew> :):)
[01:53] <ari-tczew> !ftbfs | ari-tczew
[01:53] <ari-tczew> [01:53] <ari-tczew> not good
[01:54] <persia> Why?
[01:54] <ari-tczew> persia: ftbfs should be famous phrase :)
[01:54]  * ari-tczew is checking whether there is FTBFS page on wiki.u.c.
[01:54] <persia> It is.  It's so famous nobody needs the bot to remind them :)
[01:56] <ari-tczew> persia: but would be nice if bot could reply like: FTBFS - Failed To Build From Source. Read more on https://wiki.ubuntu.com/PackagingGuide/FTBFS
[01:56] <ari-tczew> above page seems to be very poor
[01:57] <ari-tczew> could anyone with good english improve it?
[01:57] <persia> The language isn't the issue: the issue is that there are so very many causes that it's hard to have good examples, except for specific things (like the recent linker issues, or API transitions, or similar)
[01:58] <persia> Aside from that, I'm unsure who would benefit from the factoid.  It's not hard to add, but every factoid makes the bot a bit slower.
[01:59] <ari-tczew> persia: every data is important :) so let's complete it instead fruitless debating
[06:24] <nigelbabu> persia: lovely mail :)
[06:24] <persia> Thanks.
[06:25] <nigelbabu> I guess I should poke someone to get that on the fridge
[06:25] <nigelbabu> and probably the wiki
[06:25] <persia> There are, of course, lots of other ways to become a developer, but I hope that path is one people can follow without being confused by all the complexity.
[06:25] <nigelbabu> Yeah, the various choices are probably very confusing for a new comer.
[06:30] <persia> Feel free to repost that anywhere, but please include the mention from the first paragraph that this is but one path of many, so people doing it other ways aren't necessarily doing it wrong (although they may find parts of the mail helpful in any case)
[06:32] <nigelbabu> I think the whole mail would go into a blog post.  But I'm pretty sure most fridge folks are asleep.
[06:32] <nigelbabu> And I'm at the Ubuntu Developer Day listening to Chase talk about touch interfaces
[06:33] <persia> No huge rush or anything.  I heard people complaining about complexity and bureaucracy for months before I wrote that: most folk won't notice waiting even a week or so.
[06:37] <kklimonda> masters of the unseeded? really? that sound so dirty ;)
[06:37] <kklimonda> good morning
[06:38] <broder> i kind of hope we can stick with masters of the universe even when universe goes away. it's just got a fantastic ring to it :)
[06:42] <nigelbabu> kklimonda: lol
[06:47] <persia> broder, For the next few cycles, I prefer "unseeded", if only to avoid confusion with the "universe" component.  Once we can drop the component (and there are lots of outstanding blockers), then reclaiming "universe" is very tempting.
[06:47] <broder> persia: ok, i can settle for a temporary loss of awesome
[06:49] <persia> broder, If you're interested in making the "temporary" shorter, try to identify one of the semantic applications of "main" vs. "universe", and then work on the necessary changes to policy, code, etc. in order to replace it with something else.
[06:50] <persia> An example I haven't even begun to think about much would be translations: currently stuff in main gets translated, and stuff in universe doesn't, with exception lists both ways.  That probably needs a heap of changes in Rosetta, in the langpack mechanisms, in how translations are delivered to users, etc.
[06:50] <persia> But there's lots of other things :)
[06:55] <nigelbabu> the scale of the changes is um scary (sort of)
[06:57] <persia> Kinda, yeah.  The initial model made sense, but it started to get fuzzy for Hoary, and we didn't start thinking about how to fix it until Intrepid, and a lot of things turned out to have been set up to use components for convenience in the meantime.
[06:57] <\sh> moins
[07:08] <evilvish> persia: nice mail(devel-list).. you should consider making a wiki out of it.. so that it is more permanent :)
[07:09] <evilvish> .. since it is very common Q , maybe we could move it to a wiki page and link to it from https://wiki.ubuntu.com/UbuntuDevelopment#Overview%20of%20Development or similar..
[07:11] <persia> evilvish, The main issue is that it's not complete: there's other ways to become a developer (although I think that one is the easiest).
[07:12] <evilvish> yup.. and a wiki is way we could add upon(in future)
[07:13] <persia> I guess.  My experience with the wiki is often that something there ends up being "official" in some way, and thereby sacrosanct.  Your experience may vary.
[07:15] <evilvish> persia: yea.. but, you do sit on both the DMB and the regional councils ;) , though not 'officially sanctified' yet.. it is like an insider's take :)
[07:16] <evilvish>  or we could get dholbach to re-blog it..
[07:17] <evilvish> i usually ask new-comers to go through his blog, has some interesting posts for new folk..
[07:18] <persia> If someone else wants to blog about it, I'd rather they blog about their view of a good path, rather than just reposting mine.  Something like the fridge (as suggested earlier), which regularly republishes is one thing, but blog posts ought be personal.
[07:19] <evilvish> yea, but you dont blog :)
[07:19] <evilvish> not sure, fridge is the right place for this though, it aint news
[07:20] <evilvish> hence wiki was the closest, i could think of..
[07:21] <pitti> Good morning
[07:21] <persia> It's in mail archives.  With luck, it will result in a bundle of new developer applications from previously frustrated folk over the next 3-6 months.
[07:21] <persia> After that, something else can happen.
[07:23] <pitti> ion: typo and incomplete sentence fixed, thanks!
[07:45] <m4rtin> if I install the Natty alpha to a new partition, will the update-grub script within that pick up and list my maverick partition?
[08:01] <dholbach> good morning
[08:04] <pitti> hey dholbach
[08:04] <dholbach> hey pitti
[08:09] <didrocks> good morning
[08:26] <cjwatson> m4rtin: it ought to, yes
[08:26] <m4rtin> thank you :)
[08:27] <cjwatson> (there are some cases where it might not, for example if the maverick root filesystem wasn't unmounted cleanly for some reason)
[08:54] <pitti> zul: do you still actually support nut? it's one of the few packages which still pulls in hal, which is totally unsupported these days
[08:57] <ion> Also, do nut users actually use nut-hal-drivers? :-)
[08:57] <pitti> it's not seeded on the server CDs
[08:57] <pitti> you can build it without hal support, too
[08:58] <pitti> "it's" -> nut-hal-drivers
[08:59] <pitti> heh, and it even conflicts to nut
[09:38] <smb> pitti, Hi Martin, do you know who would be the person to ask about cdimage.ubuntu.com? Just was asked by someone where to find the maverick server images and those seem to be strangely missing.
[09:38] <pitti> smb: they are on releases.ubuntu.com
[09:39] <smb> pitti, Ah ok
[09:39] <pitti> cdimage only has the less used ones, such as DVDs and some derivatives
[09:39] <pitti> or alphas
[09:45] <pitti> mr_pouit: do you know what should happen with xfce4-volstatus-icon, xfce4-governor-plugin, xfce4-cddrive-plugin? these still use exo 0.3 and HAL, and I think someone said they should just be dropped from the archive?
[09:47] <mr_pouit> pitti: for xfce4-volstatus-icon and xfce4-cddrive-plugin, it's unsure. I've written that I'll drop them from the archive after FF if nobody worked to save them
[09:47] <pitti> mr_pouit: ah, good
[09:47] <mr_pouit> pitti: xfce4-governor-plugin doesn't use exo-0.3 though iirc
[09:51] <Riddell> persia: do you or your mobile friends have an opinion on bug 708519 ?
[10:05] <tkamppeter> pitti, hi
[10:16] <pitti> hello tkamppeter
[10:18] <tkamppeter> pitti, did you start on the proxy issue of Jockey and s-c-p?
[10:18] <pitti> not yet
[10:19] <tkamppeter> pitti, another question, I need a new monitor for my PC, do you have an yrecommendation? Or a recommendation for a good review site?
[10:20] <pitti> tkamppeter: last time I bought one I looked in c't
[10:20] <pitti> they do quite thorough reviews
[10:20] <pitti> otherwise I don't know a good site, I'm afraid
[10:31] <jkakar> pitti: Hi!
[10:31] <pitti> hey jkakar, how are you?
[10:31] <jkakar> pitti: I'm doing great, thanks!  How about you? :)
[10:32] <pitti> jkakar: I'm great, thanks
[10:32] <pitti> having fun in Natty :)
[10:32] <jkakar> pitti: Awesome. :)
[10:32] <jkakar> pitti: We're just talking about what to do about the HAL dependency in landscape-client.
[10:32] <jkakar> Re: bug #708502
[10:32] <jkakar> pitti: We don't really have the time/capacity to migrate to udev right now.
[10:33] <jkakar> pitti: We're wondering about making hal a 'Suggests', so that the client can be installed without it, and making some tweaks to the code so it won't blow up if HAL isn't there.
[10:33] <jkakar> pitti: The question is, will the hal package be moving to universe?
[10:34] <pitti> jkakar: I was actually quite surprised that it still used it; I thought we already talked about it many years ago
[10:34] <pitti> jkakar: I hope that we can move it to universe in natty or n+1
[10:34] <jkakar> pitti: We did, we just haven't made time for it... too many bigger fires to deal with. :(
[10:34] <persia> Riddell, Looks like upstream 1.1 is out, but still has the dependency on HAL, and I don't see any halsectomy related items on the 1.2 roadmap.  qtmobility can be compiled to not use HAL, with "reduced functionality".  I don't know of anyone actively using these APIs though, so I'd be tempted to compile with the reduced functionality (unless you know a user my apt-cache isn't finding).
[10:34] <jkakar> pitti: Okay, so there's a chance it won't make it for natty.
[10:34] <pitti> persia: it's not a compile-time thing; it only talks to the dbus interface
[10:34] <persia> pitti, Is there a reason to move to universe, or can we just drop it?
[10:34] <jkakar> pitti: I guess very few packages actually use it, right?
[10:35] <pitti> persia: i. e. simply runtime
[10:35] <persia> pitti, There's a compile-time option to tell it not to ask DBus about HAL.
[10:35] <persia> (or else I'm reading the docs wrong)
[10:35] <pitti> jkakar: it's qtmobility and landscape-client, the rest was fixed or will be in the next days
[10:35] <pitti> persia: right, but ideally it would just fail gracefully if hal isn't running (I haven't checked)
[10:36] <pitti> jkakar: out of interest, what do you use it for?
[10:36] <jkakar> I suppose one option for us is to make hal a Suggests and do a conditional import... if hal is unavailable (because the package is gone entirely) the hardware inventory will be simply unavailable.
[10:36] <jkakar> pitti: We pull the entire HAL device tree and send it to the server.  We provide a view of that data to our users.
[10:36] <pitti> jkakar: is that merely for display purposes, or do you actually do something with the data?
[10:36] <jkakar> pitti: Honestly, the functionality we have isn't so useful.
[10:37] <jkakar> pitti: Merely for display purposes.
[10:37] <jkakar> pitti: But we don't have the time to replace it with something better right now, so we're trying to figure out how to keep it working if possible.
[10:37] <pitti> jkakar: the hal tree is by and large the sysfs tree
[10:37] <jkakar> pitti: True.
[10:38] <pitti> an udevadm info --export-db usually gives enough info about the hardware, at least in the bugs that I am looking into
[10:38] <jkakar> pitti: One issue is that udev provides really crappy data on <lucid.
[10:38] <pitti> and given that hal likes to break stuff, and at least slows things down (double-probing), I'd rather not force it on our users any more
[10:38] <jkakar> pitti: We need to support dapper for a few more months, but more importantly, we have a number of hardy users and we want to provide a good experience for them if possible.
[10:39] <pitti> jkakar: sysfs/udev on hardy should work just fine
[10:39] <jkakar> pitti: Yep, agreed, getting rid of hal is the right thing to do.  We don't want to block that.  We just want to figure out if hal will be moving somewhere else (universe).
[10:39] <pitti> jkakar: yes, to universe
[10:39] <jkakar> pitti: It works fine, but the data it exposes is missing lots of interesting things.  The data for lucid and newer is much better/richer.
[10:39] <Riddell> persia: where is the 1.2 roadmap?
[10:39] <persia> pitti, qtmobility does appear to fail gracefully, from a quick look at ./src/systeminfo/qsysteminfo_linux_common.cpp
[10:40] <pitti> jkakar: but the more important thing than the component is that we don't really want to force users to get hal if they install landscape, as it changes the system behaviour
[10:40] <jkakar> pitti: Cool.  In that case I think what we'll do is make hal a 'Suggests' and, if people want it, they can install it from universe.  We'll do a conditional import and disable the hardware plugin if hal isn't installed.
[10:40] <persia> Riddell, http://bugreports.qt.nokia.com/secure/IssueNavigator.jspa?reset=true&jqlQuery=labels+%3D+mobility_roadmap+ORDER+BY+component+ASC,+key+DESC
[10:40] <pitti> jkakar: that sounds great
[10:40] <jkakar> pitti: Cool, thanks.
[10:42] <Riddell> persia, pitti: I think I'll move hal to a Suggests then and file a bug with upstream
[10:43] <persia> Riddell, Sounds reasonable.  Do you think it's worth compiling QtMobility to not use HAL at all, or just have it be optional?
[10:43] <pitti> Riddell: sounds great, thanks
[10:43] <pitti> persia: I think leaving the optional support in doesn't hurt
[10:43] <pitti> I don't think that anyone actually wants to install hal on mobile devices, given it's boot speed penalty and extra power drain
[10:43] <jkakar> Thanks guy!
[10:43] <pitti> but if they really want to..
[10:44] <persia> pitti, My fear is an unmaintained HAL in universe with N tools providing slightly different functionality if it happens to be installed.
[10:44] <persia> And I think most users are likely to install random things found from a web search about their problem, rather than think about the implications carefully.
[10:44] <Riddell> I don't think there actually is a compile option to not use hal, it's all runtime
[10:44] <pitti> persia: right, that's why I'd like to drop the dependencies and kick it into universe (as it also changes system behaviour under GNOME/KDE)
[10:45] <persia> How does that help?  Universe is available by default.
[10:45] <persia> (and if I ever succeed in getting rid of universe, it comes back :) )
[10:45] <pitti> persia: right, but at least not installed automatically via depends
[10:45] <pitti> which is my main gripe with landscape-client
[10:48] <persia> Riddell, Indeed.  I read that wrong: the compile-time switch turns off DBus support entirely, which is undesired.
[10:49] <persia> pitti, Is there a case for keeping HAL in the archives at all, or is it just a matter of the volume of work to eject it?
[10:49] <pitti> persia: universe still has a fair bunch of rdepends
[10:49] <pitti> some of them can probably be dealt with by package removals
[10:50] <pitti> such as gnome-device-manager
[10:50] <persia> Heh, yeah, that's just a GUI for HAL.
[10:50] <pitti> or ivman/mountmanager
[10:50] <persia> But to ask the question differently: does HAL provide any functionality that we expect users to want to optionally install sometimes, beyond rdepends?
[10:50] <pitti> there's always udisks-automounter for those who don't want to use gnome/kde/xfce
[10:50] <Laney> is debian deprecating hal too?
[10:50] <pitti> persia: no
[10:50] <pitti> Laney: yes, they do
[10:50] <Riddell> http://bugreports.qt.nokia.com/browse/QTMOBILITY-1057 filed
[10:51] <pitti> http://wiki.debian.org/HALRemoval
[10:51] <pitti> Laney: ^
[10:51] <persia> Ah, then I think we ought plan to drop HAL entirely, including from universe (although this may take longer than dropping from main)
[10:51] <persia> Riddell, Thank you :)
[10:51] <Laney> *verse can probably be done as an initiative in coordination with Debian maintainers then
[11:03] <Riddell> doko: I uploaded qt3 for the GCC 4.6 include issue
[11:59] <JamesPage> Hi - would it be possible to get irqbalance manually imported (its currently failing due to utf-8 characters in the changelog - http://package-import.ubuntu.com/status/irqbalance.html)
[12:11] <doko_> Riddell: cool, thanks
[12:33] <ari-tczew> kees: I guess you might would like have a look on bug 708607 :)
[12:43] <ari-tczew> cjwatson: how Merge-o-Matic gets tarball from Debian if there is no this version on ftp?
[12:45] <cjwatson> ari-tczew: can I have an example?
[12:45] <cjwatson> it gets all its tarballs from Debian's FTP server
[12:45] <cjwatson> whether it keeps them for the same period of time as Debian does is a different matter :-)
[13:14] <mdeslaur> good morning
[13:14] <mdeslaur> @pilot in
[13:33] <SpamapS> jhunt_: 'morning!
[13:35] <zul> pitti: er hal is gone?
[13:35] <pitti> zul: it got deprecated years ago, and now it's going to universe
[13:37] <zul> pitti: ah ok...ill talk to arnaud then
[13:38] <zul> pitti: thanks for the heads up
[13:38] <pitti> thanks
[13:52] <soren> pitti: Years? Wow, time flies. It feels recent.
[13:54] <pitti> soren: deprecation started in May 08
[13:54] <tkamppeter> pitti, I found my new monitor now, thanks to http://www.trustedreviews.com/.
[13:54] <soren> pitti: Intrepid still had it installed by default, didn't it?
[13:54]  * soren reminisces
[13:55] <pitti> soren: yes, it took us a while to remove all the reverse deps
[13:56] <soren> Ah... Great days.
[13:57] <ari-tczew> cjwatson: bluez, need merge from experimental
[14:04] <cjwatson> ari-tczew: MoM doesn't show bluez at all, so I don't understand what tarball you're talking about (assuming this is a followup to your earlier question).  URL please?
[14:05] <ari-tczew> cjwatson: as I wrote, experimental - MoM looks on unstable.
[14:05] <cjwatson> I know.  But what tarball are you talking about?
[14:05] <cjwatson> 12:43 <ari-tczew> cjwatson: how Merge-o-Matic gets tarball from Debian if there is no this version on ftp?
[14:05] <cjwatson> I simply do not understand this question
[14:05] <cjwatson> what missing version are you talking about?
[14:06] <ari-tczew> cjwatson: MoM creates patches on: old debian version -> current ubuntu and old debian version > new debian version
[14:06] <cjwatson> rmadison says experimental currently has bluez 4.87-1, and the source for that is on http://ftp.debian.org/debian/pool/main/b/bluez/ where I'd expect it to be
[14:07] <ari-tczew> and I want to get source of old debian version
[14:07] <cjwatson> MoM keeps the base version around in a local cache until it doesn't need it any more
[14:07] <cjwatson> try snapshot.debian.org
[14:07] <cjwatson> (ok, thanks, I understand your question now)
[14:08] <ari-tczew> cjwatson: thanks, that's what I'm looking for ;)
[14:08] <ari-tczew> I was looking *
[14:08] <cjwatson> http://snapshot.debian.org/package/bluez/4.81-1/
[14:08] <cjwatson> would be the base version in this case
[14:08] <ari-tczew> yea I found now ;-
[14:08] <ari-tczew> ;-)
[14:09] <ari-tczew> dget mode on
[14:58] <SpamapS> jhunt_: when you're around.. wondering in what state your upstart intro man page is, and whether it satisfies my workitem to document all of the events.
[15:02] <pitti> zul: do you guys care much about nut-hal-drivers? (it conflicts with "nut"); if not, we could disable the hal part entirely
[15:02] <pitti> zul: n-hal-drivers is in universe
[15:02] <jhunt_> SpamapS: the intro page is very much in a state of flux right now. I'm reworking the events summary (a separate man page) to include event type. this is almost complete. The problem is keeping the table within 80 cols! :)
[15:02] <zul> pitti: no we dont
[15:02] <zul> i was thinking of removing it entirely
[15:03] <pitti> zul: from server-ship, you mean?
[15:03] <zul> pitti: yes
[15:04] <jhunt_> SpamapS: you on mumble?
[15:05] <pitti> zul: no objection here :)
[15:05] <zul> pitti: nut-hal-drivers have already been dropped in the seeds almost a year ago
[15:10] <pitti> zul: right, but the package still needs libhal-dev as build dep
[15:10] <pitti> and thus keeps the source in main
[15:12] <zul> pitti: ill drop the hal stuff from nut today
[15:12] <pitti> zul: thanks
[15:12] <quadrispro> pitti XOR cjwatson: have you a bit of time to take a look at bug #708008?
[15:13] <pitti> quadrispro: can do
[15:15] <SpamapS> jhunt_: I am but everybody's asleep here. :-P
[15:15] <SpamapS> jhunt_: and the walls are very thin.
[15:17] <SpamapS> jhunt_: will you be on in an hour? then everybody will be up and gone
[15:18] <jhunt_> SpamapS: funny, I'm actually working in exactly the same conditions right now too :) Yes, I'll be around then.
[15:19] <Vonor> hi
[15:20] <Vonor> is this the right channel to ask for help regarding compiling a package on a non-ubuntu distribution? (I'm trying to port an ubuntu package to gentoo)
[15:20] <quadrispro> thanks pitti !
[15:23] <SpamapS> jhunt_: ack
[15:24] <Vonor> just in case someone can help. I'm trying to build the netbook-launcher application. configure complains about some package dependencies not met and I'm currently trying to fix them one by one. as seen in the build.log ( http://paste.pocoo.org/show/327822/ ) the first package is clutk, of which i just successfully installed the latest version (0.3.60) but configure still says it's not there
[15:27] <Vonor> searching for clutk:
[15:27] <Vonor> # find /usr -iname "*clutk*" | wgetpaste
[15:27] <Vonor> Your paste can be seen here: http://paste.pocoo.org/show/327828/
[15:32] <JamesPage> james_w: any chance you could manually import irqbalance for me? its currently stuck (http://package-import.ubuntu.com/status/irqbalance.html)
[15:36] <Vonor> i figure that netbook-launcher explicity asks for the old clutk-0.2 is there any reason why it doesn't make use of clutk-0.3.x?
[15:38] <james_w> JamesPage, it's started
[15:39] <JamesPage> james_w: thankyou :-)
[15:53] <cjwatson> JamesPage: bug 708537 - debconf is pure perl, there should be no way for it to crash the perl interpreter without perl being buggy
[15:53] <cjwatson> JamesPage: (or without one of the C extensions that some of the frontends use being buggy)
[16:02] <james_w> JamesPage, done
[16:03] <Riddell> rsalveti: what changes are needed to qt as part of multimedia-arm-gles-in-ubuntu ?
[16:04] <rsalveti> Riddell: bug 707794
[16:05] <rsalveti> not much, but qt is not the main problem
[16:05] <rsalveti> seems other packages that uses it could break on arm
[16:05] <rsalveti> that's what I'm testing atm
[16:05] <ari-tczew> pitti: I'd like to debate with you about 1 SRU. are you able?
[16:05] <rsalveti> Riddell: but if you think it would be ok to have it with gles support now, we can work fixing the other bugs later
[16:06] <pitti> ari-tczew: which one?
[16:06] <ari-tczew> pitti: https://code.launchpad.net/~iheino+ub/ubuntu/lucid/w3m/bug683337/+merge/46532
[16:08] <yonij> Hi...I would like to know if its possible to implement a dsm system to use with a multinode process/thread migration  system we r trying to develop........or would it b possible to port this module from another project ?.....pls sugggest....and if there is a better channel to ask this pls put that too....thnx
[16:09] <ari-tczew> guess that #ubuntu-app-devel
[16:13] <pitti> ari-tczew: well, I can't say that I'm particularly happy about such feature backports; we already have more SRUs than we should
[16:14] <ari-tczew> pitti: so backport not SRU?
[16:16] <pitti> that'd work for me; if someone really wants to push for it, so be it, but I don't think it's worth doing
[16:20] <pitti> good night everyone!
[16:20] <jdstrand> pitti: hi! I'm looking at NBS and see cups is still using libpoppler7. are you planning an upload for that? I can try a no change rebuild locally and upload if it builds if you'd prefer
[16:20] <jdstrand> pitti: sorry for the poor timing :)
[16:21] <pitti> jdstrand: I'll certainly do an upload soon, but if you want to get rid of it qucikly, please go ahead
[16:21] <jdstrand> pitti: k, thanks (think I will-- I'm in a groove right now :)
[16:21] <jdstrand> pitti: have a great night :)
[16:22] <pitti> go, jdstrand, go!
[16:22] <jdstrand> hehe
[16:22] <pitti> jdstrand: if you have suggestions how to improve nbs.html, please let me know
[16:24] <JamesPage> cjwatson: so does this point to a potential perl issue? happy to take some guidance on what is needed to help triage bug 708537
[16:24] <jdstrand> pitti: I think the page is good, but am still getting used to it. as I go I might have more to say about it. the hardest part was trying to figure out what was on installation media. I've worked through that now
[16:24] <JamesPage> james_w: thanks again
[16:24] <james_w> np
[16:31] <cjwatson> JamesPage: I'm not sure, I haven't really read the bug in detail, it probably needs a reliable reproduction technique
[16:32] <JamesPage> cjwatson: OK; I'll go back to the reporter and see if it can be reproduced.
[16:33] <cjwatson> pitti: FWIW, while I can't find the e-mail right now, Robbie e-mailed the foundations team a while back to say that somebody internal had asked for that w3m backport - possibly the Launchpad team?  I can't remember
[16:38] <ari-tczew> cjwatson: that's possible since micahg has suggested to nonix4 about mail to TB about it
[16:38] <SpamapS> jhunt_: still around?
[16:39] <jhunt_> SpamapS: yup - can you give me 5 mins?
[16:39] <SpamapS> jhunt_: I've literally got all day. :)
[16:57] <ari-tczew> nonix4: as you can read above log, only full backport from natty is possible
[17:04] <mdeslaur> @pilot out
[17:05]  * dholbach hugs mdeslaur
[17:05]  * mdeslaur hugs dholbach back :)
[17:12] <hallyn> mdeslaur: thanks mucho for pushing the kvm fix :)
[17:12] <mdeslaur> hallyn: np
[17:12] <shadeslayer> whats the package name for the csharp mono libraries?
[17:13] <shadeslayer> currently get this http://paste.kde.org/3457/ with a package
[17:19] <ari-tczew> cjwatson: I'm not sure whether Debian will upload lilo 23.1 to unstable before FeatureFreeze. I'd like to upload it from Debian git, then sync. What do you think?
[17:29] <cjwatson> ari-tczew: would prefer to wait until after the Debian release - there's 2.5 weeks in there for them to do the upload
[17:30] <ari-tczew> cjwatson: hmm. does Debian preparing toolchain 1-2 weeks like Ubuntu?
[17:31] <cjwatson> ari-tczew: no
[17:31] <Laney> unstable is going to be *fun* :)
[17:31] <ari-tczew> Laney: why?
[17:31] <cjwatson> ari-tczew: if nothing else, people have been uploading not-for-squeeze uploads to unstable for months anyway
[17:32] <Laney> I imagine it will see a lot of activity
[17:32] <ari-tczew> cjwatson: and they (people) should upload to experimental instead?
[17:32] <cjwatson> not necessarily
[17:33] <cjwatson> for leaf packages where it's unlikely RC fixes for squeeze are going to be needed, it's not unreasonable to upload to unstable
[17:33] <cjwatson> I've done several of those myself
[17:34] <ari-tczew> cjwatson: you're fired! :D
[18:04] <jdstrand> Riddell: hi! I noticed that kword, krita and karbon (all koffice) were built against several NBS binaries. are you planning to do a koffice upload before alpha2?
[18:09] <Riddell> jdstrand: wasn't planning to, what's NBS?
[18:09] <jdstrand> Riddell: not built from source. they are pulling in extra stuff onto installation media
[18:10] <jdstrand> s/stuff/libraries/
[18:10] <kees> ari-tczew: yup, thanks.
[18:10] <jdstrand> Riddell: I can attempt a no-change rebuild, but if there are problems with building locally I would file a bug on it
[18:11] <Riddell> jdstrand: go for it
[18:11] <jdstrand> ok
[18:13] <kees> it's never good to ask yourself, "gee, what's eating one of my CPUs?" the answer is rarely what you want.
[18:13] <jdstrand> hehe
[18:13] <jdstrand> kees: your cat again?
[18:14] <kees> jdstrand: hah, no, not sure the cause, but virt-manager was at 100% cpu, though totally responsive and otherwise "normal".
[18:14] <jdstrand> neat
[18:16] <jdstrand> Riddell: interesting:
[18:17] <jdstrand> E: Build-Depends dependency for koffice cannot be satisfied because the package libdcmtk1-dev cannot be found
[18:17] <jdstrand> Riddell: dcmtk is in universe, and afaics, has always been
[18:17] <Riddell> jdstrand: oh yes, it's waiting on MIR process
[18:18]  * jdstrand wonders how koffice ever built
[18:19] <Riddell> it was only added recently, bug 702026 has some outstanding work to be done, I can do an upload with it removed for now
[18:19] <jdstrand> Riddell: that would be fantastic :)
[18:32] <kees> pitti: hi! the security team needs to be coordinated with for kernel cadence publications when there is a CVE in the changelog.
[18:33] <kees> pitti: what do you think the best way to give us lead time to produce a USN is?
[18:33] <jdstrand> kees: fyi, he is eod
[18:33] <kees> jdstrand: yeah
[18:53] <janimo_> do patch system (in particular quilt) support per-arch patches, for example to have one ftbfs.armel only be applied if built on armel?
[18:53] <ari-tczew> janimo_: rather debian/rules should handle it
[18:54] <ari-tczew> but I dunno how to do that, sorry
[18:54] <ari-tczew> I'm just guessing
[18:54] <janimo_> ari-tczew, that can be done, but I was hoping for something simpler and more declarative
[18:55] <cjwatson> not in 3.0 (quilt)
[18:55] <cjwatson> with raw quilt you can of course generate the series file dynamically if you like, but it doesn't support it otherwise
[18:55] <cjwatson> best to put the conditionals in the patch itself, generally
[18:57] <micahg> janimo_: you can take a look at what fta did for Chromium WRT series patches: http://bazaar.launchpad.net/~chromium-team/chromium-browser/chromium-browser.head/view/head:/debian/enable-dist-patches.pl
[18:58] <janimo_> cjwatson, micahg thanks, I'll guess I do it the ifdef way in the patch itself
[19:04] <rsalveti> Riddell: what do you think about changing libqt4-opengl to gles on arm? did you see the patch?
[19:05] <cody-somerville> Why is qemu-kvm-extras called qemu-kvm-extras? The stuff in qemu-kv-extras doesn't actually use kvm, right?
[19:18] <fta> micahg, just added an example in my script..
[19:19] <micahg> fta: cool
[19:19] <fta> micahg, is it clear enough?
[19:20] <micahg> fta: yes, looks fine
[19:25] <mterry> doko_, was your intention with bug 684704 to get Riddell to decide to either file a MIR or drop the depends or was the intention to start a MIR itself?
[19:44] <dobey> can i poke someone in ubuntu-backporters to look at bug 704590 please?
[19:46] <micahg> ScottK: ^^
[19:48] <kklimonda> dobey: you have decided not to push 1.0.1 through updates after all?
[19:49] <ScottK> dobey: What rdepends does this affect?
[19:49] <dobey> kklimonda: yeah, it's basically impossible to do right
[19:50] <dobey> ScottK: python-couchdb and desktopcouch are the ones i'm directly aware of, and the same versions of those are on both lucid and maverick so shouldn't be a problem.
[19:51] <ScottK> OK.
[19:51] <kklimonda> dobey: what's the problem with installing couchdb 1.0.1 somewhere else, like in /usr/lib/desktopcouch/couchdb/? I know it was one of the options you were discussing and I'm cruious what's wrong with it.
[19:51] <kklimonda> curious*
[19:51] <dobey> kklimonda: because it's way too much work to do and support
[19:53] <ScottK> Done
[19:53] <micahg> kklimonda: https://lists.ubuntu.com/archives/ubuntu-devel/2010-November/032169.html
[19:55] <apw> i assume compiz archive borkage is known ?
[19:55] <dobey> ScottK: thanks!
[19:57] <kklimonda> micahg: I do remember the discussion, but in my opinion that (creating a new package, and preparing upgrade paths) was still a better option from users' perspective. with -backports every affected user will have to install two packages by hand or risk enabling entire backports repository. Plus the discussion took place two months ago, so there was quite a lot of time to do testing.
[21:40] <soren> I have a daemon I start from upstart using: exec su -c "blah blah" some_system_user
[21:41] <soren> GDM shows some_system_user (as logged in, no less).
[21:41] <soren> What am I doing wrong?
[21:42] <seb128> soren, does that get a ck session?
[21:42] <soren> seb128: ck-list-sessions doesn't list it.
[21:43] <seb128> soren, is ck-history listing it?
[21:43] <soren> ck-history fails :-/
[21:43] <seb128> ck-history --frequent
[21:43] <soren> http://paste.ubuntu.com/559230/
[21:44] <soren> seb128: Yeah, that does show it.
[21:44] <soren> At the very top, even :)
[21:44] <seb128> soren, ok, so  seems a ck issue then
[21:44] <seb128> that's what gdm is using to build its user list
[21:44] <soren> http://paste.ubuntu.com/559231/
[21:45] <seb128> well that and filtering on uid as well
[21:45]  * soren glances at pam_ck_connector
[21:45] <soren> seb128: Thanks for the hint. I looked at ck-list-sessions, and didn't see it, so I stopped looking at consolekit.
[21:46] <soren> seb128: But yeah, I would have thought some uid filtering would have taken care of it, too.
[21:46] <seb128> soren, you're welcome
[21:46] <Riddell> mterry: I need to file a qmf MIR
[21:46] <mterry> Riddell, ok, cool.  /me waits for it  :)
[21:46] <seb128> soren, it's using login.defs to filter the ids iirc
[21:47] <Riddell> rsalveti: patch looks fine to me, go ahead when you wish and are happy enough with the testing
[21:47] <rsalveti> Riddell: ok, thanks!
[21:47] <rsalveti> will have better results for tomorrow I think
[21:47] <rsalveti> ping you back then
[21:48] <soren> seb128: gdm, you mean? Or consolekit?
[21:48] <chrisccoulson> does anyone have any clue about bug 703618? it's blocking me from testing another change to swt-gtk :(
[21:49] <seb128> soren, gdm was but seems we dropped our patch for that since upstream code was supposed to handle it now
[21:49] <mterry> tremolux, out of curiousity, how does it pull in new ratings?  Whenever I do an apt-get update or is a separate thing?
[21:51] <soren> seb128: Ah, it seems to bypass the uid check because it turns up in ck-history.
[21:52] <tremolux> mterry: it gets ratings from the R&R server
[21:52] <tremolux> hey kiwinote  \o
[21:53] <kiwinote> heya tremolux
[21:53] <kiwinote> rnr is looking sweet :)
[21:53] <tremolux> kiwinote: fun times!  :)
[22:07] <soren> seb128: Ah, found it.
[22:09] <seb128> soren, oh?
[22:09] <seb128> soren, ck bug?
[22:09] <bigon> seb128: could you please sync telepathy-mission-control?
[22:10] <seb128> bigon, ok, only this one or also glib and gabble?
[22:11] <soren> seb128: Nope, gdm.
[22:11] <soren> bug 708911
[22:11] <seb128> soren, thanks
[22:11] <soren> seb128: I
[22:11] <soren> Ḯll fix it.
[22:12] <seb128> great!
[22:13] <bigon> seb128: mm good question, not looked at the other updates (btw: http://people.collabora.co.uk/~cassidy/tp-versions.html)
[22:15] <soren> seb128: Is there any particular numbering scheme for the patches in debian/patches in the gdm package that you want me to follow?
[22:15] <seb128> soren, no
[22:31] <soren> seb128: Figures. Now I can't reproduce my original problem. I've pushed a patch anyways. The issue I found is definitely accurate (minimal uid for non-system users was 500, debian policy says 1000).
[22:31] <soren> seb128: I'll have to look at it again when/if it happens again.
[22:31]  * soren calls it a day
[22:31] <seb128> soren, ok, we had a patch from kees reading login.defs to get the number
[22:31] <seb128> but we dropped it because upstream rewrote the code and said they handled that correctly now
[22:32] <seb128> which seems to not be true
[22:32] <soren> seb128: The patch I saw in the Lucid version just redefined the minimal uid, too.
[22:32] <soren> seb128: Oh, well. I didn't upload anything, only pushed to the bzr branch.
[22:32] <seb128> ok
[22:33] <soren> Oh, I see Kees' patch  now.
[22:33] <soren> I'll look at it again tomorrow. Now -> bedtime.
[22:33] <seb128> 'night soren
[22:33] <soren> 'night, seb :)
[22:55] <hallyn> slangasek: were you still going to send an email to ubuntu-devel about moving qemu-kvm-extras to the arm tree?
[22:56] <slangasek> hallyn: sent 2 minutes before you asked ;)
[22:56] <persia> Just extras?  How about extras-static?  Will this affect regular KVM for i386/amd64/powerpc ?
[22:56]  * persia goes to read email
[22:57] <hallyn> slangasek: hah, awesome :)  i've been thinking for the last week that i should ask you :)
[22:58] <persia> slangasek, Are you expecting changes to support for powerpc guests/chroots as a result (on non-powerpc hosts)?
[22:58]  * persia isn't that fussed about degraded x86 guests on armel/powerpc hosts
[23:01] <RAOF> Mmm. x86 emulation on armel.  I can think of nothing more delicious.
[23:01] <RAOF> Perhaps x86 emulation on an emulated armel on x86!
[23:02] <stgraber> would be fun ! doing an ls in what, 2 minutes ? ;)
[23:02] <slangasek> persia: I haven't looked at the status of powerpc user emulation on either branch; if you find that it doesn't work, I'll gladly escalate and if that isn't satisfactory we can look at splitting powerpc out as well - but that makes the package transitions more complicated
[23:02] <stgraber> arm chroots using qemu on x86 actually work quite well (for what I needed), running x86 using qemu on arm might be quite different though ;)
[23:03] <slangasek> I know powerpc system emulation is DOA in Ubuntu because openhackware / openbios-ppc are FTBFS
[23:03] <persia> Well, one can use the binaries from Debian, but yeah :)
[23:04] <persia> But I'll test the static emulation for powerpc on amd64 when the new packages come out, and let you know.
[23:07] <slangasek> persia: appreciate it!
[23:24] <kirkland> slangasek: ping
[23:24] <slangasek> kirkland: ohaipong
[23:25] <kirkland> slangasek: re: qemu-linaro, will it build powerpc binaries too?
[23:25] <slangasek> kirkland: yes - anything that's in qemu-kvm-extras* today
[23:25] <kirkland> slangasek: my read of your email would be "yes"
[23:25] <kirkland> slangasek: coolio
[23:28] <persia> kirkland, Just to make sure there is alignment, the qemu-kvm package would still be providing kvm for powerpc-on-powerpc, right?
[23:28] <kirkland> persia: no, i think it will be qemu
[23:28] <persia> Why?
[23:28]  * persia applied patches in maverick to support KVM, and doesn't understand why this would be removed
[23:31] <persia> I may be mistaken, but my understanding was that there was a missing kernel bit that jk was planning to add for natty for powerpc.
[23:31] <kirkland> persia: yes, that's in progress
[23:31] <kirkland> persia: ibm is developing kvm patches against qemu base
[23:33] <persia> Then I'm confused.  From which source should I expect to have binaries to do powerpc-on-powerpc?
[23:33] <kirkland> persia: is qemu-kvm does this already, we can test and verify it, and that's fine -- that's what I would like
[23:35] <persia> It did for maverick, except it couldn't boot because of a kernel option.  I'm not expecting to have time to work on that until end-Feb or March (I like powerpc, and want to do emulation, but it's always a low priority for me each cycle)
[23:35] <kirkland> persia: from my current discussion with IBM, they've needed to add some other specific development, which they've done against qemu
[23:35] <kirkland> persia: okay, i'll keep you posted as we learn more
[23:36] <persia> kirkland, Cool, thanks.
[23:36] <kirkland> persia: your preference would be to apply these changes against qemu-kvm, if possible?
[23:37] <persia> I'm not sure.  I've been vaguely poking at kvm-on-powerpc since Karmic, but it's always low priority, so I haven't gotten so far.  I just don't want to end up with a separation of sources such that one works great for armel and another for i386/amd64, and having trouble finding a safe target :)