[01:09] <greenfish> i apologize if this is off topic... is there a debug kernel image available for lucid that i can use for profiling purposes?
[05:50] <ccheney> shtylman: ping
[05:55] <ccheney> shtylman: i saw your comment on 389623 but wasn't sure if you meant documents aren't supposed to be saved into $HOME/Documents on KDE or if you meant it just doesn't work for any locale when you closed it invalid, isn't $HOME/Documents a XDG dir that is supposed to be used for cases like this?
[07:27] <pitti> Good morning
[07:31] <ddecator> morning pitti
[07:35] <ajmitch> morning pitti
[08:15] <dholbach> good morning
[08:33] <didrocks> good morning Mr Holbach :)
[08:46] <dholbach> Salut didrocks
[09:10] <tkamppeter> pitti, hi
[09:15] <Laney>  	  #5
[09:15] <Laney> Rebooting my system and attempting to reinstall did not correct the issue for me. My system consistently hangs when attempting to install assemblies into mono.
[09:15] <Laney>  	  #5
[09:15] <Laney> Rebooting my system and attempting to reinstall did not correct the issue for me. My system consistently hangs when attempting to install assemblies into mono.
[09:15] <Laney>  	  #5
[09:15] <Laney> Rebooting my system and attempting to reinstall did not correct the issue for me. My system consistently hangs when attempting to install assemblies into mono.
[09:15] <Laney> oops
[09:15] <Laney> sorry
[09:15] <ajmitch> Laney: you obviously need to remove mono ;)
[09:16] <Laney> REVEALED: Laney looks at mono bugs!
[09:16] <ajmitch> *gasp*
[10:03] <cjwatson> seb128: can the main task on bug 438434 be closed?  I see that maverick has 2.26.3
[10:03] <seb128> cjwatson, wrong bug?
[10:04] <cjwatson> bug 438484
[10:04] <seb128> cjwatson, yes
[10:04] <seb128> doing that now
[10:04] <seb128> cjwatson, thanks
[10:05] <cjwatson> ta
[10:05] <cjwatson> seb128: ditto bug 582178
[10:05] <seb128> same, closing it
[10:20] <hyperlinx> my monitor is only of the Half of the existing surface
[10:21] <seb128> cjwatson, do we need verification on all bugs?
[10:21] <seb128> cjwatson, seems that 5 bug fix verified and no regression should be good to go
[10:21] <seb128> we usually don't aim at fixing all issue but to have something better than the current version
[10:22] <cjwatson> well, I thought it worth asking
[10:22] <cjwatson> if the reporter says he can't, then we can look at the whole lot
[10:22] <cjwatson> I was just doing a drive-by and hadn't read the other bugs in detail
[10:23] <seb128> ok
[10:28] <hyperlinx> my monitor is only of the Half of the existing surface
[10:35] <mdz> is anyone else seeing sd_espeak and sd_dummy running with a blank argv[]?
[10:35] <mdz> 13203 ?        Sl     0:00
[10:35] <mdz> 13207 ?        Sl     0:00
[10:37] <pitti> mr_pouit, davidbarth: is xfce4-panel capable of displaying indicators?
[10:43] <seb128> pitti, it should since it can run applets too
[10:43] <seb128> I guess you can add the indicator-applet to it
[10:43] <seb128> pitti, switching to xfce?
[10:43] <pitti> seb128: in a small VM
[10:46] <ogra_cmpc> seb128, i bet pitti tries to solve the same prob i'm attacking with efl launcher for arm in maverick :)
[10:46] <seb128> ogra_cmpc, disk space?
[10:47] <ogra_cmpc> and ram
[10:47] <pitti> I'm trying to run netbook-laucher-efl in an xfce session
[10:47] <ogra_cmpc> what we discussed yesyerday, in maverick the 2D session will use as less gnome stuff as possible and get a gtk container as panel for the indicators
[10:48] <ogra_cmpc> i'll have the spec ready this evening so you should be able to read up about the implementation
[10:48] <ogra_cmpc> effectively the DX team will write us a minimal gtk panel
[10:51] <davidbarth> pitti: it is, with the g-applet compatibility module
[10:52] <davidbarth> pitti: ie, running indicator-applet, withing xfce g-applet applet; a bit convoluted, but that works
[10:52] <ogra_cmpc> but likely doesnt save you much
[10:52] <ogra_cmpc> (ram/diskspace)
[10:55] <pitti> davidbarth: ah, it's in a separate package, I suppose?
[10:55] <seb128> pitti, it is
[10:55] <pitti> ah, xfce4-xfapplet-plugin
[10:55] <seb128> yes
[10:55] <pitti> thanks guys!
[10:56] <ogra_cmpc> pitti, do you make a ram/diskspace comparison between xfce panel and a normal 2D session ?
[10:56] <pitti> ogra_cmpc: I will
[10:56] <ogra_cmpc> i would be intrested in data if you plan to collect any
[10:56] <ogra_cmpc> cool !
[11:01] <tkamppeter> pitti, hi
[11:02] <pitti> hey tkamppeter
[11:03] <tkamppeter> There is still the problem with CUPS not being started by upstart, bug 554172. Have you any idea how to solve it, also some minimum-invasive way for Lucid?
[11:04] <tkamppeter> pitti, for me the whole backward compatibility mode of upstart seems to be broken, as users also complain about other sservices not starting.
[11:06] <pitti> tkamppeter: unfortunately no, since I still don't know why it's not started in the first place :-(
[11:06] <cjwatson> rc-sysinit.conf has 'start on filesystem and net-device-up IFACE=lo', so if lo never comes up for some reason, or if filesystems never get mounted, then the system will never enter runlevel 2
[11:06] <pitti> davidbarth, ogra_cmpc: yep, works like a charm, cheers
[11:06] <ogra_cmpc> cool
[11:06] <cjwatson> some people have to put 'nobootwait' on some entries in /etc/fstab
[11:07]  * ogra_cmpc is intrested in the resource usage we probably dont need upanel at all if its low enough
[11:07] <cjwatson> this is not an upstart problem, it's (if anything) a mountall problem - although mountall will eventually be integrated into upstart
[11:13] <pitti> ogra_cmpc: http://people.canonical.com/~pitti/screenshots/xfce-panel-indicators-nl-efl.png :)
[11:13] <pitti> (yes, not themed yet, etc.)
[11:13] <ogra_cmpc> pitti, looks great !
[11:17] <tkamppeter> pitti, the bug is assigned to the CUPS package and when I assign it to upstart they simply assign it back to CUPS. Seems that whoever works on upstart is not convinced that the problem is in upstart.
[11:24] <cjwatson> you can't just say "I don't understand this, must be in upstart", you need analysed evidence of what's going on
[11:24] <cjwatson> full --verbose logs at the very least
[11:25] <ogra_cmpc> but but ... upstart is so easy to blame :)
[11:37] <mr_pouit> pitti: as you noticed, not natively (there is a xfce4-indicator-plugin, but it's not in the archive, and it doesn't work because the api changed too much)
[12:10] <simonp> is this the right place to ask about a problem i have with debconf (im building .debs)
[12:10] <simonp> or should i be in some other channel?
[12:12] <cjwatson> simonp: maybe - what's the problem?
[12:15] <simonp> im getting an error when testing. ive got my config and config.templates but when i run the config file (in debug) i get a 10 'cant find' error
[12:15] <simonp> ive double checked, its not a typo
[12:15] <simonp> ive tried using config.templates and also a standalone templates file
[12:16] <cjwatson> config.templates is a bogus name, don't know where you got that from
[12:16] <cjwatson> can you post the whole package somewhere?
[12:16] <simonp> i got it here http://www.fifi.org/doc/debconf-doc/tutorial.html
[12:17] <cjwatson> no you didn't, it doesn't say "config.templates" anywhere
[12:17] <simonp> 'First, if there is a file with a name that is ".templates" appended to the name of the config script that is being run, debconf assumes that is the templates file.'
[12:17] <simonp> ?
[12:18] <simonp> my script is called 'config'
[12:18] <simonp> therefore, config.tempaltes
[12:18] <cjwatson> oh, that's a special case, don't do that
[12:18] <simonp> ok
[12:18] <cjwatson> that is for people doing weird stuff
[12:18] <cjwatson> can you post the whole package somewhere?
[12:19] <simonp> its not fully built, im still testing the debconf stuff. so i cant test it from command line, i have to build it and install to test?
[12:19] <cjwatson> no, I mean the source package
[12:19] <cjwatson> your debian/ directory anyway
[12:19] <simonp> ok sec
[12:19] <cjwatson> I don't care whether it's built or not
[12:21] <simonp> http://pastebin.com/GTf4F3tW
[12:22] <simonp> thats it in its most basic form
[12:22] <simonp> :)
[12:22] <cjwatson> uh, you really can't test debconf stuff like that
[12:23] <cjwatson> not unless you know debconf very very well and know all the tricks
[12:23] <simonp> ok so probly easier to use my own postinst then and skip debconf
[12:23] <cjwatson> it's really much, much easier to get the package built and test it that way
[12:23] <cjwatson> anyway, I notice two mistakes there
[12:24] <simonp> ooh :)
[12:24] <cjwatson> firstly, you shouldn't Pre-Depends: debconf because you don't need to - a Depends is quite sufficient (if you use Depends: ${misc:Depends}, dh_installdebconf will fill in the right thing for you)
[12:24] <cjwatson> secondly, you have no postinst - see the second note under "Modifying Existing Maintainer Scripts" in that tutorial
[12:25] <cjwatson> i.e. if you're using debconf in the config script, the postinst script needs to at least do  . /usr/share/debconf/confmodule
[12:25] <simonp> yep havent done the postinst yet, was just tyring to get to grips with actually asking questions nad putthing shite in the db
[12:25] <cjwatson> technically, the thing you were missing was calling debconf-loadtemplate, but it's easy to get that sort of thing wrong
[12:26] <simonp> ahh! ok so i mis understood that, the way i read it was that it would find the temaplte based on a filename
[12:26] <simonp> ill read up about that bat, cheers for the pointer
[12:26] <simonp> bat?
[12:26] <simonp> s/bat/bit/g
[12:27] <simonp> cheers :)
[12:27] <cjwatson> well, it does do that, just not the way you were trying to run debconf ...
[12:27] <cjwatson> using the 'debconf' command itself is a very special-purpose thing and doesn't do that magic
[12:27] <cjwatson> it's for debugging
[12:28] <cjwatson> if you'd just executed the script directly it might have managed it
[12:28] <simonp> awesome thats just fixed it :)
[12:28] <simonp> you ledgend
[12:28]  * simonp facepalms
[13:18] <shtylman> ccheney: Is there an environment variable for this folder? cause right now, the save dialog defaults to $HOME unless openoffice itself hints at something different.
[13:20] <maeon31> I have a long datafile with lines in it, boss wants Line-level encryption so some lines are encrypted and some are not, so that some lines cannot be read, but others can be.  What would be the best way to go about that?
[14:01]  * wgrant is a little unsure about the whole new websites thing.
[14:01] <wgrant> eg. the white on light grey on http://www.ubuntu.com/server, plus a whole lot of other little things.
[14:09] <G> wgrant: it's going to get some people I agree, but the homepage etc is clearer now
[14:10] <wgrant> They both seem really... rough.
[14:11] <G> wgrant: the Desktop/Netbook/Server links at the top are perfect positioning for the first glance at the page (I don't know how, but it took me several clicks to find the server ISOs on the old site, I think because Download was the most prominent feature
[14:11] <G> hmmm I do have a graphics glitch on the homepage, but I think I'm going to put it down to my ISP
[14:11] <wgrant> I wouldn't.
[14:12] <G> wgrant: I live in a rural area, rain gets into the overhead lines and makes my connection unreliable
[14:13] <G> wgrant: for me, the bottom right hand part of the ? for 'Get support' is missing
[14:13] <Pici> Thats how the image is
[14:13] <wgrant> The bottom left is deliberately missing.
[14:13] <wgrant> It took me a few minutes to work it out.
[14:13] <wgrant> But it's actually the profile of a head.
[14:14] <G> oh, the ? is the ears?
[14:14] <Pici> Just like the top of the fishbowl on the community thing is missing.
[14:14] <wgrant> I guess it could be.
[14:14] <Pici> http://www.ubuntu.com/sites/default/files/active/03_global/02_pictograms/pictogram_support_medium.pnghttp://www.ubuntu.com/sites/default/files/active/03_global/02_pictograms/pictogram_support_medium.png
[14:14] <G> oh and of course, the other isa fishbowl
[14:14] <Pici> oops, double paste.
[14:15] <sgallagh> Question: what's the process for getting Ubuntu to pull in a newer point release of a package?
[14:15] <G> Pici: thanks for explaining it
[14:15] <G> not sure if I'd go along with the community = fishbowl analogy or not, but okay :)
[14:23] <zul> how do I handle source package renames do I have to do a MIR and all that fun stuff?
[14:24] <pitti> zul: no, of course not; just tell today's archive admin
[14:24] <zul> pitti: thanks
[14:25] <cjwatson> sgallagh: for stable release updates, in the vast majority of cases, we ask that people instead backport only critical bug-fixes
[14:25] <cjwatson> sgallagh: for the development release, it's quickest to get Debian to adopt it and then we'll pull it in semi-automatically; otherwise, file a bug
[14:26] <sgallagh> cjwatson: The update in question is a critical bugfix-only release
[14:26] <cjwatson> https://wiki.ubuntu.com/StableReleaseUpdates
[14:26] <sgallagh> cjwatson: The package in question (SSSD) actually appeared first in Ubuntu
[14:26] <sgallagh> It was only recently built in Debian
[14:26] <cjwatson> if it really is *absolutely nothing else*, we can consider it via the process above
[14:27] <sgallagh> cjwatson: https://fedorahosted.org/sssd/wiki/Releases/Notes-1.0.6
[14:28] <cjwatson> I don't want to get involved with putting the upload together, I'm just pointing you in the right direction
[14:28] <sgallagh> (Apologies for all the questions, I'm a Fedora guy)
[14:28] <cjwatson> that looks short enough that we could accept it in its entirety, I think
[14:29] <cjwatson> an Ubuntu developer will have to prepare an upload for it
[14:29] <cjwatson> it really ought to get into maverick first though
[14:29] <sgallagh> cjwatson: Ok, so I should file a bug in Launchpad?
[14:29] <cjwatson> for a stable update, there must be a bug filed in Ubuntu, yes
[14:29] <cjwatson> that's how we deal with QA tracking
[14:29] <sgallagh> cjwatson: Well, hopefully Maverick will be pulling in SSSD 1.2.0 (which is being built in Debian next week)
[14:30] <sgallagh> This is just a fix for a very serious bug in our old stable tree
[14:30] <sgallagh> It was already fixed in 1.1.x and 1.2.x
[14:30] <sgallagh> But it only came to my attention today that Ubuntu was still on 1.0.x
[14:30] <cjwatson> I'm just quoting a statement from the policy page above ...
[14:30] <cjwatson> "It is, in general, not appropriate to release bug fixes for stable systems without first testing them in the current development branch."
[14:31] <cjwatson> so if 1.[12].x includes that fix, that's fine too
[14:31] <sgallagh> Yes, it was a straight trivial merge from the 1.1.x branch
[14:32] <sgallagh> Ok, I'll open a bug and see what we can do.
[14:32] <sgallagh> Thanks for your help
[14:33] <cjwatson> I guess you had a sponsor to get sssd into Ubuntu in the first place?  Best to get them interested
[14:33] <cjwatson> mathiaz or tjaalton, by the looks of it
[14:34] <sgallagh> Yes, both of them, I think.
[14:35] <sgallagh> tjaalton: Toss me a ping when you're around, if possible. I'd like to talk to you about a bugfix update for SSSD 1.0.x
[14:36] <ccheney> shtylman: ping
[14:36] <shtylman> ccheney: pong
[14:37] <ccheney> shtylman: i think it probably uses the XDG_CONFIG_DIRS env var, but not completely sure, about to grep sources to see
[14:37] <shtylman> ccheney: k, if you do find where it sets that up for the file dialog, do let me know... I can fix that in the kde one as well... also, I have a patch that allows mailto links (and other links) to work now
[14:37] <shtylman> per one of the other bugs
[14:38] <jcastro> sgallagh: since you're here I work on pages for upstreams to help document things like our SRU process: https://wiki.ubuntu.com/Upstream
[14:38] <jcastro> feedback always welcome!
[14:38] <ccheney> shtylman: maybe only by ooo-build and/or just the gnome dialog, will let you know what i find
[14:38] <shtylman> k
[14:38] <ccheney> shtylman: great :)
[14:38] <sgallagh> jcastro: Thanks, I'll take a look
[14:40] <ccheney> shtylman: hmm i don't see how its working, at least its not doing anything obvious under fpicker
[14:40] <shtylman> hm
[14:41] <shtylman> ccheney: maybe the gnome dialog defaults to that directory by itself? it would seem strange that it does that... but it may be possible
[14:41] <shtylman> ccheney: that bug seems pretty minor tho... the user can just select the right folder :)
[14:43] <ccheney> shtylman: perhaps, i'm asking on go-oo, i don't think it would default to Documents without at least somehow prodding it to the right type of dir
[14:43] <ccheney> shtylman: but there may some flag i don't know to search for that would do it
[14:44] <shtylman> ccheney: k
[14:48] <ccheney> shtylman: whatever is changed even the internal file dialog defaults there, and on official upstream so not something done by go-oo patches
[14:49] <hrw> hi
[14:49]  * ccheney will ask in upstream channel, maybe someone there knows
[14:49] <shtylman> k
[14:49] <shtylman> very strange
[14:49] <apw> pitti, are you doing a general reset of trend lines or should i be doing that for kernel ??
[14:50] <pitti> apw: some teams asked me to flush their work items last week
[14:50] <pitti> apw: once you guys have your specs ready, I can do that for kernel as well
[14:50] <ccheney> shtylman: it might be somewhere in framework code since it seems not to be in fpicker, my grep will take a while, will update you later
[14:51] <shtylman> ccheney: kk.. no problem.. will be on the lookout for any update :)
[14:51] <pitti> apw: or, if you want to keep the history, just change it in maverick.cfg
[14:52] <jdub> howdy, foundations-m-toolchain is listed as accepted, but has no wiki page; while https://wiki.ubuntu.com/Specs/M/ARMToolChainSelection suggests gcc 4.5 except for g++
[14:53] <jdub> seeing that both 4.4 and 4.5 have been uploaded, anyone know the outcome?
[14:54] <hrw> doko: ping
[14:55] <jdub> (long time no see, btw, old chums!)
[14:55] <ccheney> actually looks like slangasek is in charge of that spec
[14:55] <ccheney> slangasek: ^
[14:55] <apw> pitti, yeah i don't see any value in dropping the history or anything, its just the trend line, so i can sort that
[14:56] <doko> hrw: ?
[14:56] <doko> jdub: 4.4 default, 4.5 optional (in main)
[14:57] <hrw> doko: I wanted to discuss about https://bugs.launchpad.net/ubuntu/+source/gcc-4.4/+bug/585439 (debhelper7 for gcc-4.4)
[14:57] <jdub> doko: so no elements of 4.5 in the default toolchain at all (libstdc++ etc)?
[14:57] <hrw> doko: if you have few minutes
[14:57] <doko> jdub: except for the runtime libs
[14:58] <jdub> ah okay
[14:58] <jdub> thanks :-)
[14:58] <doko> hrw: what do you need to know?
[14:59] <apw> pitti, like this ??
[14:59] <apw> trend_start = {
[14:59] <apw>         'canonical-kernel-team': 168,
[14:59] <apw> }
[14:59] <pitti> apw: for that, and presumably also for ('canonical-kernel-team', 'maverick-alpha-2')?
[14:59] <hrw> doko: does migration to dh7 (done in better way) will be accepted?
[15:00] <apw> pitti, ahh ok ta
[15:00] <hrw> doko: I need to check yet how to better use dh_install (no --autodest) and then how to show not packaged files.
[15:01] <doko> hrw: what is the advantage compared to v5?
[15:01] <doko> hrw: the best fix would be to de-deprecate dh_movefiles, or add an option --move to dh_install
[15:01] <apw> pitti, i assume the cron runs at '0' so i guess i just missed it
[15:02] <pitti> apw: at :5
[15:02] <doko> dapper still has v5,
[15:02] <pitti> so you're lucky :)
[15:02] <ccheney> shtylman: ok its set by an option in OOo which probably pulls it from xdg somehow but that isn't needed to be search for anymore, just have to determine how to query the internal var now
[15:02] <apw> heh i am indeed
[15:02] <tjaalton> sgallagh: ok, I can prepare it. thanks for the heads-up
[15:02] <hrw> doko: we (arm team) want to do some changes and thought that moving to dh7 would be good addition (thats my idea, others can not agree)
[15:02]  * apw hopes he hasn't blown the whole thing up and pitti won't have to come round and beat him
[15:02] <pitti> apw: you know, I don't actually have to look at the WI charts this cycle ;)
[15:03] <shtylman> ccheney: yea.. I see the comment in go-oo, I guess someplace in shell
[15:03] <apw> pitti, lucky man
[15:03] <doko> hrw: "do some changes" should be specified ... and no, I don't think v7 is a good idea on its own
[15:04] <hrw> doko: you are using debian/tmp/ now to check which files did not got packaged? what about comparing list of installed files (from debian/tmp) with list of packaged ones?
[15:04] <doko> hrw: how did you test your patch?
[15:04] <sgallagh> tjaalton: Great! Thank you very much.
[15:04] <hrw> doko: sure, agree. so far they exists as list of work items in https://blueprints.launchpad.net/ubuntu/+spec/arm-m-cross-compilers
[15:05] <hrw> doko: built normally for host (amd64) and for cross (amd64 -> arm), then applied my patch and built again same targets. then debdiffed resulting packages
[15:06] <tjaalton> sgallagh: looks like maverick still has 1.0.5, so I'll upload it there first, not merging the debian changes to keep the diff minimal, then that version can be uploaded to lucid-proposed
[15:06] <jdub> doko: warty was built for i486, right?
[15:06] <jdub> doko: or just particular optimisations?
[15:07] <sgallagh> tjaalton: Ok, cool. Let me know if there's anything you need from me.
[15:07] <hrw> doko: if I can test it in better way then I am all ears
[15:08] <doko> jdub: gcc-4.1 (4.1ds7-0exp7) experimental; urgency=low
[15:08] <doko>   * Set default 32bit ix86 architecture to i486.
[15:08] <doko>  -- Matthias Klose <doko@debian.org>  Fri, 27 Jan 2006 22:23:22 +0100
[15:09] <jdub> doko: oh, so dapper! gosh.
[15:10] <doko> jdub: not sure, didn't check which gcc version was in use for warty and hoary
[15:10] <cjwatson> dh_movefiles was deprecated because the operation of moving rather than copying can't meet policy's idempotency requirements
[15:10] <doko> hrw: please do without --autodest, I think /lib and /usr/lib might get wrong
[15:11] <hrw> doko: I am now building gcc-4.4 to get base for work this out
[15:11] <cjwatson> so dh_install --move would just reintroduce that problem
[15:11] <doko> cjwatson: deprecated for that reason? I remember that globbing issues were the reason
[15:12] <cjwatson> multiple reasons - see debhelper 4.0.0 changelog
[15:12] <doko> #315518 is still open =)
[15:12] <cjwatson> anyway, dh_movefiles is still there, you can still use it with debhelper 7
[15:16] <axonnn> oh hi guys
[15:16] <axonnn> I want to develop something similar to Wubi. What are the main topics should I study?
[15:17] <axonnn> are u sleepin?
[15:18] <azeem> no, but your question is probably too vague
[15:18] <axonnn> azeem: actually I'm looking for some keywords
[15:18] <axonnn> such as loopmount, lupin etc.
[15:19] <hrw> axonnn: "windows grubdos linux wubi" are not enough?
[15:19] <axonnn> hrw: oh I will develop a new wubi for a distro. so I should learn main concepts in this stuff
[15:20] <hrw> axonnn: I would first check how wubi and debian win32 installers work and how they are done
[15:20] <hrw> but I did not had to use wubi
[15:20] <axonnn> hrw: yeah I'm wondering exactly that. should I checkout the code? not sure..
[15:22] <azeem> checking out the code is rarely wrong
[15:22] <axonnn> azeem: hmm okay so I would do that.
[15:25] <axonnn> wubi is such a good software. however some people say that it is significantly slow. is that true?
[15:26] <azeem> shouldn't you evaluate things like that yourself if you want to develop something like it?
[15:27] <tjaalton> sgallagh: looks like the package didn't include sssd.api.conf. how big of an issue is that?
[15:27] <tjaalton> sgallagh: wondering if I should fix that as well..
[15:28] <axonnn> azeem: actually not evaluating just asking that ntfs is really slow or not.
[15:28] <sgallagh> Ah, shoot
[15:29] <sgallagh> tjaalton: Trying to remember. You just didn't package it, or I added it in this patch?
[15:29] <tjaalton> sgallagh: the tarball has it, but the package didn't because of a typo in the packaging scripts ;)
[15:29] <axonnn> kewl.
[15:29] <sgallagh> oh ok
[15:30] <sgallagh> tjaalton: Well, without it, the SSSDConfig API won't work, but I don't think you have any consumers of that API in Ubuntu yet (in Fedora we have authconfig)
[15:30] <tjaalton> sgallagh: alright, then I'll keep it out, we'll get that from debian when we merge/sync 1.2.0
[15:33] <ogra> kirkland, hrm, seen bug 532733 recently ? i wonder against which upstream we're supposed to file it if not qemu
[15:34] <hrw> cjwatson: with dh_movefiles checking which files did not got packaged is easy - "find debian/tmp" basically. which way you would do such check with dh_install being used?
[15:35] <sgallagh> tjaalton: At some point, you probably want to add an install-script based on the SSSDConfig API to set up network configuration.
[15:36] <tjaalton> sgallagh: yes, sounds nifty
[15:36] <arand> Keybuk: Are you planning to do the merge of the new e2fsprogs, or do you mind if I tried poking it a bit? (I was told you were in charge of that package?)
[15:38] <Keybuk> arand: there shouldn't be a need to merge
[15:38] <Keybuk> our e2fsprogs package is from the same git tree as Ted's
[15:38] <Keybuk> it should be up to date
[15:39] <Keybuk> there's just a new version to pull
[15:39] <Keybuk> I'll do that at some point - it's just "git pull ted" "dpkg-buildpackage"
[15:39] <ogra> that would build a ted package, no ?
[15:39] <ogra> :)
[15:40] <arand> Keybuk: Ah, ok, I got on the track since I was thinking that https://bugs.edge.launchpad.net/ubuntu/+source/e2fsprogs/+bug/582035 might need an SRU with a fix that is in the new release.
[15:41] <Keybuk> arand: SRU doesn't really need to be done within git, so you can backport that one patch to lucid and upload
[15:41] <jjardon> Hello, I'd like to update the info from: https://launchpad.net/gtk
[15:41] <Keybuk> I've tried to keep the Ubuntu package in git for easier collaboration with Ted
[15:41] <tjaalton> sgallagh: uploaded to maverick, next up lucid-proposed. the process will handle it from there :)
[15:42] <jjardon> How can I do that?
[15:43] <sgallagh> tjaalton: Thanks again for your help.
[15:43] <arand> Keybuk: Yea, ok, I wasn't sure on the procedures really, but I'll make the -proposed debdiff ready for lucid and just wait until the new version gets into maverick then?
[15:43] <seb128> jjardon, you can try asking on #launchpad
[15:43] <seb128> jjardon, what do you want to change?
[15:45] <jjardon> set the branch of developemt, the stble branch, obsolete ...
[15:45] <jjardon> Also, Is anyone working in GTK+3 packages
[15:45] <jjardon> ?
[15:46] <jjardon> seb128, see https://launchpad.net/glade-3 as an example
[15:46] <seb128> jjardon, not that I know
[15:46] <Keybuk> arand: why do you need to wait for the new version?
[15:47] <tjaalton> sgallagh: np, thanks for the notice
[15:47] <ogra> Keybuk, SRU policy
[15:47] <ogra> needs to be in $dev_release before the SRU is accepted
[15:49] <pitti> Keybuk, ogra: haven't followed scrollback, but NB that if lucid version == maverick version, we can just copy lucid-proposed to maverick, so no extra upload necessary
[15:49] <pitti> that's standard practice right after a new release
[15:51] <jdub> http://ubuntuedge.wordpress.com/2010/05/27/previously-on-maverick/ <- thoughts? (blog about devel branch activity)
[15:51] <tjaalton> sgallagh: who reported the issue? filed a bug here, so they should confirm it's fixed once the package is available https://bugs.launchpad.net/ubuntu/lucid/+source/sssd/+bug/585885
[15:53] <sgallagh> tjaalton: It was filed a long while ago upstream, and was fixed in 1.1.0
[15:53] <sgallagh> tjaalton: But I only today realized that Ubuntu had never upgraded to 1.1.x
[15:53] <sgallagh> So I backported it to a version you'd be able to continue with
[15:54] <tjaalton> sgallagh: ah ok
[15:54] <tjaalton> wonder who's going to confirm the bug, but since it came from upstream I think it's good :)
[15:55] <sgallagh> tjaalton: Well, I'll have the guy who came to me about it verify it for you
[15:56] <mdeslaur> pitti: I have an occasional problem with evolution where all of a sudden it's calendar timezone gets screwed up. I have traced the problem to /usr/share/zoneinfo/UTC getting replaced with my current timezone file when I do a dist-upgrade. Any idea what package would be messing with the UTC file?
[15:56] <tjaalton> sgallagh: ok, thanks
[15:56] <mdeslaur> pitti: I have a list of packages in LP: #254980 if you want to take a look
[15:56] <pitti> mdeslaur: tzdata for sure
[15:56] <mdeslaur> pitti: yes, but that's not the one that is _breaking_ the UTC file. There's another package that is breaking it.
[15:57] <pitti> mdeslaur: hm, check dpkg -S /usr/share/zoneinfo/UTC and grep zoneinfo /var/lib/dpkg/info/* ? (the latter will look for broken postinst scripts)
[15:58] <pitti> mdeslaur: but maybe it just picks up the file in an intermediate bad state during unpack?
[15:59] <mdeslaur> pitti: I tried those two already...tzdata still owns it, and nothing looks broken in the postinst scripts
[16:01] <mdeslaur> pitti: it's a weird problem...and I've had it sporadically for the last couple of years...jdstrand also
[16:02] <mdeslaur> hmm...I wonder if it has something to do with schroot
[16:03] <mdeslaur> nah
[16:16] <cjwatson> hrw: dh_install has two options just for that - --list-missing and --fail-missing
[16:19] <hrw> cjwatson: but does it work if I do lot of dh_install calls?
[16:19] <cjwatson> why would you do that?
[16:19] <cjwatson> you shouldn't need to if you're using debian/<package>.install properly
[16:22] <hrw> cjwatson: gcc-4.4 rules has 103 calls to dh_movefiles (which I so far changed to dh_install)
[16:22] <cjwatson> hrw: it shouldn't be expected to be a one-to-one translation
[16:22] <zeroluck> anyone have experience installing kernel modules/patches for rocketraid card drivers?
[16:22] <hrw> I know and I am working on it
[16:22] <cjwatson> anyway, I don't see why arm should need to do this :)
[16:23] <hrw> ;)
[16:27] <dholbach> Laney, stefanlsd: mind if I subscribe you to community-m-packaging-docs?
[16:27] <dholbach> you have action items on there
[16:27] <ricotz> seb128, hello, are there already some packaging attempt for gtk+3.0 yet?
[16:28] <seb128> ricotz, hi, no
[16:28] <dholbach> Laney, stefanlsd: done, jbicha too
[16:28] <seb128> ricotz, we have lot of others things to work on, but contributions are welcome
[16:30] <ricotz> seb128, i was hoping you already have a ppa, i wanted to look into it since gnome-shell will propably depend on it soon
[16:30] <seb128> urg, good luck with that
[16:30] <jcastro> hi ricotz, I sent you a mail about -shell dailies a day or so ago
[16:31] <ricotz> jcastro, hi, you did? let me check
[16:32] <ricotz> jcastro, i got no mail
[16:34] <ricotz> seb128, thanks :(
[16:35] <seb128> ricotz, don't package gtk3 in a ppa in any case
[16:35] <seb128> if you work on it please work with us to get it done in Ubuntu
[16:37] <ricotz> seb128, isnt it best way to use a ppa, and let someone of you check it?
[16:38] <seb128> ricotz, no offense to your work but you don't want to ship non official gtk builds to user
[16:38] <seb128> ricotz, it could create quite some issues
[16:38] <seb128> those need to be done properly and reviewed
[16:39] <ricotz> seb128, i havent planed to publish it widely
[16:39] <seb128> if it's in a ppa with gnome-shell users will get it
[16:39] <seb128> and it might break upgrades to the official version
[16:39] <seb128> work with us to get it properly done in debian and ubuntu
[16:39] <ricotz> i wouldnt put it in there!
[16:39] <seb128> ok, good
[16:40] <ricotz> gtk3 should also be able to install besides gtk2
[16:42] <ricotz> seb128, i have done some testing with gtk-sharp3 some time ago which should be a similar transition like gtk+
[16:42] <seb128> ricotz, right, it just need to have rebuild of all theme engines, etc for it
[16:42] <seb128> + bindings
[16:42] <seb128> + input methods
[16:42] <seb128> + etc
[16:43] <ricotz> yes, thats why i asked cause this package is a bigger deal
[16:45] <mvo> Riddell: we are about to move language-selector to dbus/policykit. I suppose this will be fine with kubuntu? it has a policykit1 auth dialog I assume?
[16:45] <mvo> (just double checking to not accidently break stuff)
[16:46] <Riddell> mvo: yes we have polkit-1 support in kde
[16:46] <Riddell> but might be worth testing it
[16:47] <Riddell> JontheEchidna: incase you're interested ^^
[16:51] <mvo> Riddell: cool, thakns
[17:08] <apw> pitti, is there any reason that having the default start for the trend line as the highest bar in the range would ever be unreasonable
[17:09] <pitti> apw: rickspencer3 didn't like that, since it would hide the fact if new WIs are added to your workload after the original plans, and thus are responsible for slipping deadlines or not delivering other projects
[17:12] <apw> pitti, i was more thinking as a default ... and as long as you don't delete the history the jump in bar height at day N tells you someone added work doesn't it?
[17:12] <apw> that has nothing todo with the meaning of the trend line for my mind
[17:14] <pitti> apw: TTYL, just finished a phone call and off for dinner; back in 30
[17:14] <apw> sure
[18:01] <seb128> jdong, hey, do you think you could do some sru reviewing work? there is quite some updates waiting, cjwatson has been reviewing a good bunch of those bugs would be nice to have somebody else helping him I guess
[18:01] <seb128> or slangasek or other sru team members
[18:03] <jdong> seb128: ah I'm so sorry about that. For the past two weeks I've been swamped with house repair work. When I get back tonight I'll spend an hour going through the queue
[18:03] <jdong> thanks cjwatson for filling in
[18:04] <seb128> jdong, nothing to be sorry about, thanks for having a look to those ;-)
[18:04] <pitti> I'll spend some 20 mins on it now
[18:06] <seb128> pitti, thanks!
[18:17] <jdub> seb128: are you guys aiming for GTK+ 3 in maverick?
[18:18] <seb128> jdub, no
[18:18] <seb128> jdub, well depends what you call aim, I aim at having it available
[18:18] <seb128> I'm leaning toward trying to keep it out of the default installation
[18:18] <seb128> it's going to be a non trivial transition
[18:18] <jdub> seb128: ah, so mostly focusing on having stuff built against 2.22?
[18:18] <seb128> and having 2 gtk versions on the CD would be challenging
[18:19] <seb128> right, mostly stabilizing what we have now
[18:19] <seb128> getting platform uptodate
[18:19] <seb128> then trying to get GNOME3 things as they seem reasonable ready
[18:19] <seb128> but we are not going to run into gsettings on gtk3 port for the desktop components
[18:20] <jdub> ok, cool -- thanks :-)
[18:31] <pitti> seb128: I'm done with some -updates migration, but there's some half-finished langpack upload in the -proposed queue (asked ArneGoetje for details) which breaks the review script
[18:31] <pitti> but it's time for Taekwondo anyway
[18:31] <pitti> bye everyone!
[18:31] <seb128> pitti, ok thanks, have fun, see you tomorrow!
[18:54] <debfx> Daviey, superm1: hi, mythtv and mythplugins need to build-depend on libqt4-webkit-dev as QtWebKit is no longer part of libqt4-dev
[18:56] <brassman> i need some help
[18:57] <brassman> i installed ubuntu with Wubi
[18:57] <brassman> 3 days latter my hard drives doesnt boot
[18:57] <brassman> any suggestions
[18:58] <azeem> brassman: please ask in #ubuntu
[19:27] <superm1> debfx, can you please file a bug with tasks for both?
[19:28] <superm1> (and i'm assuming that change was made for maverick - earlier versions can still b-d on just libqt4-dev)
[19:29] <ScottK> superm1: Yes.  It's just maverick.
[19:38] <debfx> superm1: done
[19:39] <superm1> thanks
[20:22] <zul> is there an archive admin around? mysql-dfsg-5.1 got renamed to mysql-5.1 in debian I just uploaded the newest version from debian and need to replace mysql-dfsg-5.1 with mysql-5.1
[20:50] <blue_anna> hey, is this a bug in ruby or could it be in my base libraries? http://pastebin.ws/1tuwkd
[20:51] <blue_anna> ruby's documentation says taht it uses the native architecture‘s double-precision floating point representation.
[20:58] <kitallis> ok
[20:58] <kitallis> why doesn't Set up Broadcast Account open up on my lucid install
[20:58] <blue_anna> kitallis: did you mean to go to #ubuntu ?
[20:58] <kitallis> ubuntu has too much noise.
[20:59] <kitallis> but, okay.
[21:00] <blue_anna> kitallis: whichever you want it's a free world (well sorta) -  I think generally if you have questions here it is supposed to be about libraries, not end-user stuff
[21:00] <kitallis> well, this is a sort of an unfixed _bug_
[21:00] <kitallis> https://bugs.edge.launchpad.net/gwibber/+bug/523964
[21:01] <blue_anna> ooh, yeah that's maybe perfect question for here
[21:01] <Chipzz> blue_anna: no, this channel is about the development of ubuntu (and some derivates) as a whole, and the development of some core technologies
[21:03] <blue_anna> so it's strictly about development of the next packages, no debugging of current ones?
[21:03] <blue_anna> I mean -- I'm asking .. I volunteered because it was pretty quiet for a minute, is all :)
[21:05] <blue_anna> kitallis: it launches for me, although I do see dbus errors in STDOUT when it does
[21:05] <Chipzz> blue_anna: debugging of the current ones too, of course
[21:06] <Chipzz> if by current you mean the packages in the current development release
[21:06] <Chipzz> blue_anna: just mentioning what I have noticed appears to be the general trend here
[21:06] <Chipzz> my word is by no means final :)
[21:06] <blue_anna> Chipzz: thank you :)
[21:07] <Chipzz> but saying that #ubuntu-devel is purely about libraries would be wildly inaccurate :)
[21:07] <kitallis> well
[21:07] <Chipzz> there are some other things that tend to get discussed here
[21:07] <kitallis> i'm getting those errors + couchdb returning a 500 error
[21:07] <blue_anna> python error messages always are illegible to me :S
[21:07] <kitallis> i've been updating as soon as things come, looks like it hasn't been fixed yet
[21:08] <blue_anna> -- /usr/lib/python2.6/httplib.py line 330 -- you failed to get a socket for some reason, not sure why
[21:08] <Chipzz> blue_anna: although it may have changed recently, another rough guideline is that packages in main/restricted get discussed here, packages in universe/mulitverse get discussed in #ubuntu-motu
[21:09] <Chipzz> but this may not be entirely accurate due to the reorganization of the pockets, iirc
[21:11] <kitallis> bah
[21:13] <blue_anna> kitallis: can you do python -d /usr/bin/gwibber and pastie the results?
[21:18] <kitallis> blue_anna: http://pastie.org/private/bzlwxgrvth1mx6r2mzdkqg
[21:19] <blue_anna> that looks different
[21:19] <blue_anna> attach taht to your bug --
[21:20] <blue_anna> "Connection refused" is what's causing your problem, and the code doesn't escape out of the connection attempt gracefully
[21:20] <blue_anna> well, I dunno know but, looks like it is your problem
[21:21] <blue_anna> kitallis: how did you file a bug?
[21:22] <blue_anna> I'm pretty sure I have one
[21:22] <kitallis> i did not
[21:22] <blue_anna> that's not your bug report you linked earlier?
[21:22] <kitallis> nope,
[21:22] <blue_anna> oo
[21:22] <kitallis> -,
[21:23] <blue_anna> kitallis: watch the thread it is marked as duplicate of instead of the one you linked me
[21:32] <blue_anna> hey, is this a bug in ruby or could it be in my base libraries? http://pastebin.ws/1tuwkd
[21:53] <debfx> seb128: the directfb so bump cause some packages to be uninstallable
[21:54] <debfx> especially libsdl which many packages build-depend on
[21:54] <debfx> I think that should be rebuilt: bug #585992
[21:56] <seb128> debfx, yes, that's true often true on soname changes
[21:56] <seb128> -true
[21:56] <seb128> debfx, somebody will fix it soon enough I guess
[21:57] <seb128> debfx, uninstallability happen especially early in unstable cycles
[21:58] <debfx> seb128: sure, it's just annoying when trying to build a package that has uninstallable build-deps
[21:59] <seb128> debfx, ...
[21:59] <seb128> debfx, not sure what you are looking for, I can't transition the whole archive by myself you are welcome to contribute if you have issues
[22:00]  * ajmitch TIL on libsdl, should probably upload a rebuild sometime
[22:05] <debfx> all I'm saying is that it would be nice to fix some of the packages that have many reverse build-deps
[22:25] <seb128> debfx, right, not discussing this, patches are welcome
[22:34] <blue_anna> I think the problem with firefox might be related to the floating point base libraries not being up to date on xorg
[22:35] <blue_anna> ** problem with firefox on xorg
[22:36] <micahg> YokoZar: my sound issue isn't with wine, it's with the audio subsystem :(
[22:38] <blue_anna> how do I upgrade my system to the development version?
[22:40] <blue_anna> there's no /testing page now