[01:39] <jbicha> darkxst: ping
[01:39] <darkxst> pong
[01:42] <jbicha> I'm curious how much you know about bug 1187981 and if there's some way you can think of that we can work around it
[01:42] <jbicha> I think it's the biggest blocker bug to getting g-c-c 3.8 in to Saucy (besides the whole running out of time issue)
[01:43] <darkxst> jbicha, the easiest option would be to just rename the symbols in libtimezonemap so they don't conflict with g-c-c
[01:44] <jbicha> I had trouble looking up the symbols in g-c-c that matched the same names in libtimezonemap
[01:45] <darkxst> things like cc_timezone_location_new
[01:45] <jbicha> alternatively we could patch g-c-c's panel to use different function names right?
[01:46] <darkxst> well all the symbols have a cc_ prefix
[01:46] <darkxst> which makes sense for g-c-c, but not a standalone library
[01:49] <jbicha> I think I was grepping the wrong repository before because I didn't see matching functions
[01:50] <jbicha> is it possible for you get me a list of the date-time symbols g-c-c uses or show me how to make that list?
[01:51] <jbicha> I think GNOME will eventually fix https://bugzilla.gnome.org/show_bug.cgi?id=702194 but it's not clear whether it will happen for 3.10 or sometime later
[01:55] <darkxst> its basically all the public symbols in cc-timezone-map.h
[02:00] <jbicha> gtk+3.0 finally migrated
[02:01] <darkxst> yes I noticed!
[02:03] <jbicha> it was a big headache but this was all that was needed: https://launchpadlibrarian.net/145852087/notify-osd_0.9.35daily13.06.12-0ubuntu1_0.9.35%2B13.10.20130725-0ubuntu1.diff.gz
[02:11] <darkxst> oh i see, totally unrelated to gtk then
[02:12] <jbicha> yeah, new uploads now trigger autopkgtests for their rdepends, see http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[02:13] <jbicha> like the gcc-4.8 upload
[02:14] <jbicha> notify-osd had actually been broken for a week already https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-notify-osd/
[02:16] <jbicha> I'm thinking about bribing people to do gtk uploads for me next time :)
[02:16] <jbicha> like for instance I was glad Laney did the evolution 3.8 update and not me so I won't get blamed for any issues with it :)
[03:10] <darkxst> seems like a plan!
[03:33] <darkxst> jbicha, what do you think of the new wallpaper?
[03:42] <jbicha> I'm still on 3.8 so I haven't really used it yet
[03:45] <jbicha> I'm not sure whether it will be confusing to ship gnome-backgrounds 3.10 for Saucy when we will be 95% 3.8 but I am a bit tired of Stripes
[03:46] <jbicha> I'm ok now with us shipping a different wallpaper as default
[03:49] <jbicha> my wife likes the Ubuntu animals such as https://commons.wikimedia.org/wiki/File:Cacomixtle_Ubunte%C3%B1o_by_Carlos_and_Paula_Morales.jpg
[03:50] <roasted> aw, Saucy isn't getting 3.10?
[03:50] <jbicha> roasted: GTK 3.10 will be rather disruptive like usual
[03:50] <roasted> dang, GTK isn't doing us any favors
[03:51] <roasted> they really need to stop doing that.
[03:51] <roasted> I don't recall seeing complaints from the KDE crowd with 4.9 vs 4.10, etc. :(
[03:52] <jbicha> darkxst: I know I should try it for myself but how well do the fancy new titlebars work with Unity/Ambiance?
[03:53] <jbicha> I expect the answer is badly https://bugzilla.gnome.org/702971
[03:53] <roasted> you wouldn't think a version bump within 3.x would be that bad
[03:55] <jbicha> seb128 really doesn't like all of these https://git.gnome.org/browse/gtk+/log/?qt=grep&q=deprecate
[03:56] <roasted> :(
[03:57] <jbicha> https://git.gnome.org/browse/gtk+/commit/?id=fbbcb is disruptive but I expect Debian & Ubuntu will override that since it's easy to do and disabling it does more harm than good
[03:59] <jbicha> roasted: the new HeaderBar looks something like these screenshots: http://worldofgnome.org/gnome-weather-3-9-3/
[04:00] <roasted> I was just reading an article about why there is such a severe lack in gtk3 themes
[04:00] <roasted> which seems largely due to gtk devs breaking compatibility with each release
[04:00] <roasted> sounds pretty... awesome :/
[04:00] <jbicha> unfortunately the X is in the top right and GNOME doesn't care to make the window buttons customizable and of course they want to convert as many of their apps as possible to it
[04:00] <roasted> I hope gnome gets their act together with that.
[04:00] <jbicha> I like my X in the top left
[04:00] <roasted> You can only irritate users for so long
[04:01] <jbicha> the Ubuntu devs obviously can't use inconsistent stuff like that
[04:02] <roasted> hence their Qt move?
[04:03] <jbicha> yeah but I think they'd prefer using well-tested and fully featured stuff like Nautilus on the desktop
[04:04] <bjsnider> what advantage does the x on the left get you?
[04:04] <jbicha> if you read through https://wiki.ubuntu.com/SystemSettings mpt clearly envisions using gnome-control-center (or a fork of it) on the desktop and not just ubuntu-system-settings
[04:05] <jbicha> bjsnider: for one I use Unity part of the time
[04:06] <jbicha> but it also makes it faster to close windows from the Activities Overview
[04:06] <jbicha> for opening or closing (fullscreen) windows I can just throw my pointer to the top left corner
[04:07] <jbicha> gsettings set org.gnome.shell.overrides button-layout 'close:'
[04:09] <bjsnider> well,  you know what the gnome devs say, engage them in a spirited discussion (heated flame war) over the issue and convince them they're wrong
[04:19] <darkxst> jbicha, arent those  wayland only though?
[04:20] <jbicha> darkxst: I don't think so but like I said I didn't try it yet, maybe tomorrow I'll try it out
[04:29] <darkxst> jbicha, right, they look a little odd w/ Ambiance but otherwise do work https://www.dropbox.com/s/9f6aezag334w7pd/Saucy%20-%203.9%20%40%202013-07-27%2014%3A27%3A04.png
[04:30] <darkxst> overview search box is busted in ambiance, btw
[04:36] <jbicha> but seb128 will see that as more than a "little odd", especially for core Ubuntu apps
[04:37] <jbicha> it solves a problem that was also solved by Unity's appmenu
[04:38] <darkxst> well apps don't automatically get it, I think
[04:40] <jbicha> apparently, gnome-control-center got it https://git.gnome.org/browse/gnome-control-center/log/?qt=grep&q=header
[04:41] <jbicha> it looks like nautilus doesn't yet but I expect they'll add it to a lot of apps
[04:44] <darkxst> gnome-control-center still has the old titlebar
[04:44] <darkxst> i.e. there are no window controls in the headerbar (yet)
[04:45] <jbicha> oh ok
[04:45] <jbicha> I like that listbox and libgd are now part of GTK 3.9
[04:45] <darkxst> yeh, but its going to be a pain building 3.8 apps against 3.9/10
[04:47] <jbicha> :(
[04:47] <darkxst> oh unity appmenu is broken also
[04:48] <jbicha> bug 1191345 ?
[04:50] <darkxst> yeh thats the one
[06:46] <darkxst> ricotz, hi
[06:50] <darkxst> ricotz, think its ok to loose the gdm fallback greeter (in saucy)
[08:58] <hombibi> Hi All, just broke my ubuntu-gnome installation with an standard "dist-upgrade", It removed "gnome-shell" and "ubuntu-gnome-desktop". Trying to get it reinstalled gives me the error "gnome-shell : Depends: libgdm (>= 3.5.90) but it is not installable). Anyone encountered this issue already? I can't find any reference with google.
[09:00] <darkxst> hombibi, raring or saucy?
[09:00] <hombibi> raring, gnome 3.8
[09:02] <darkxst> right I probably broke it ... oops!
[09:05] <darkxst> hombibi, uploaded a fix, give it 10mins or so to build
[09:06] <hombibi> So quickly! Great. I'll check in 15 and revert with my experience. Thanks very much!
[09:34] <ricotz> darkxst, please testbuild things like gdm -- dont forget to add back consolekit support
[09:53] <hombibi> darkxst, my error message trying to reinstall "gnome-shell and ubuntu-gnome-desktop" remains the same: "gnome-shell : Depends: libgdm (>= 3.5.90) but it is not installable)".
[09:58] <hombibi> darkxst: "sudo apt-get install libgdm" returns "E: Package 'libgdm' has not installation candidate."
[10:18] <darkxst> hombibi, sorry build failed, I will check once I have had dinner
[10:23] <hombibi> :-) Enjoy dinner, Thanks.
[10:49] <darkxst> ricotz, yep pre-dinner brain-fade. Should be fixed now ...
[11:19] <Ponch0> Hey guys another "partial-upgrade" that removed my desktop and is now unusable
[11:19] <Ponch0> removed 4 packages, upgraded 3
[11:20] <Ponch0> whats up with that
[11:26] <darkxst> Ponch0, you shoud always check before doing a partial-upgrade
[11:26] <darkxst> if it looks like its removing important packages just wait
[11:28] <darkxst> Ponch0, that said should be fixed now, just reinstall gdm/gnome-shell
[11:29] <darkxst> hombibi, ^try again now
[11:29] <Ponch0> got it, i should know.  I'm a slow learner
[11:29] <darkxst> Ponch0, I would generally suggest avoiding the partial upgrade button ;)
[11:30] <Ponch0> I get it when clicking software update.
[11:30] <darkxst> Ponch0, but there are two buttons right?
[11:30] <Ponch0> I have 3 options, cancel, partial-upgrade or continue
[11:31] <darkxst> continue is 100% safe
[11:31] <Ponch0> Got it now thank you.
[11:31] <darkxst> and I guess cancel is also pretty safe
[11:31] <darkxst> but partial-upgrade will sometime try to remove important packages
[11:31] <Ponch0> hahah right.
[11:31] <darkxst> when dependencies don't work out
[11:32] <Ponch0> Ok I should probably write this down for the future, how do I fix my issue now?
[11:33] <darkxst> Ponch0, sudo apt-get install gnome-shell gdm
[11:33] <Ponch0> thank you.
[11:34] <darkxst> Ponch0, apt-get update, first of course
[11:38] <ricotz> darkxst, i see ;)
[11:43] <darkxst> ricotz, its been a long Sat. Should have just gone riding.....
[12:10] <hombibi> darkxst: installation now worked, rebooting, long wait at "init: failsafe main process killer by term signal" , then a blue screen with nothing for several minutes already.
[12:11] <darkxst> hombibi, logs?
[12:12] <darkxst> /var/log/gdm/:0*
[12:14] <hombibi> One sec, had to ssh in, can't get a terminal at all.
[12:16] <hombibi> darkxst: what do you need, all of it? or only the last greeter, slave and default log.
[12:17] <darkxst> start with the greeter (assuming there are no errors in the X log
[12:20] <hombibi> cat :0-greeter.log gnome-session[1860]: WARNING: Failed isActive call to ConsoleKit: Rejected send message, 2 matched rules; type="method_call", sender=":1.24" (uid=114 pid=1860 comm="/usr/bin/gnome-session --autostart /usr/share/gdm/") interface="org.freedesktop.ConsoleKit.Manager" member="IsActive" error name="(unset)" requested_reply="0" destination=":1.21" (uid=0 pid=1728 comm="/usr/sbin/console-kit-daemon --no-daemon ") g
[12:22] <hombibi> darkxst: once more, the former was not complete
[12:22] <hombibi> darkxst: cat :0-greeter.log gnome-session[1860]: WARNING: Failed isActive call to ConsoleKit: Rejected send message, 2 matched rules; type="method_call", sender=":1.24" (uid=114 pid=1860 comm="/usr/bin/gnome-session --autostart /usr/share/gdm/") interface="org.freedesktop.ConsoleKit.Manager" member="IsActive" error name="(unset)" requested_reply="0" destination=":1.21" (uid=0 pid=1728 comm="/usr/sbin/console-kit-daemon --no-da
[12:24] <hombibi> darkxst: limit on text length, you want me to post in parts?
[12:24] <hombibi> darkxst: or just the error messages.
[12:25] <darkxst> hombibi, paste.ubuntu.com
[12:27] <darkxst> ^i.e. put the whole log there
[12:27] <hombibi> darkxst: done.
[12:28] <darkxst> hombibi, link?
[12:31] <hombibi> http://paste.ubuntu.com/5918193/
[12:32] <darkxst> and that is off a clean reboot?
[12:35] <darkxst> hombibi, :0.log?
[12:36] <hombibi> http://paste.ubuntu.com/5918209/
[12:37] <darkxst> (EE) open /dev/dri/card0: No such file or directory
[12:37] <hombibi> darkxst, the computer won't power down on sudo shutdown -r now, need to hold the powerbutton to power it of.
[12:37] <darkxst> that sounds like a kernel issue
[12:38] <hombibi> darkxst: thus not a clean boot.
[12:39] <darkxst> so force a clean boot, this doesnt seem related to gdm/shell updates
[12:43] <hombibi> darkxst: agreed, how do I force a clean boot: sync;  sudo shutdown -P now ?
[12:44] <darkxst> sync; hard reset should be fine
[12:44] <darkxst> a.k.a reset button
[12:46] <hombibi> darkxst: gui is back.
[12:47] <darkxst> hombibi, good! because I am going now ;)
[12:47] <hombibi> Thank you very much for your help.
[12:47] <darkxst> np


[01:26] <twb> So this "weyland" thing that Mark was waffling on about... does it mean ssh -X won't Just Work in upcoming releases of Ubuntu?
[01:26] <twb> (Or: is there a more appropriate channel to ask that?)
[01:37] <kklimonda> twb: it's simply way to early to ask that
[01:37] <twb> okey dokey
[01:38] <kklimonda> also, X are not the only way of running applications remotely.
[01:39] <twb> I realize that, but I'd prefer not to replace ssh -X with some raster-based nightmare like RFB or RDP
[01:39] <kklimonda> but it's still too early to ponder about it.
[01:39] <twb> Nod.
[01:42] <Chipaca> is there an easy and magic way to split a library package into libfoo and libfoodev?
[01:42] <lifeless> .install files
[01:45] <Chipaca> lifeless: thanks
[01:45]  * Chipaca reads
[01:55] <electrofreak> I've realized a problem with the powernowd and Phenom II's dynamic clocking. For example... if I download mprime and run 4 stresses from the program, my CPU usage will go to 100%, but the clocks of all the cores is 800MHz except for 1, which is at 3.2GHz. This was also a problem when doing multithreaded converting with ffmpeg. But if I use 'stress' with 4+ cpu stresses, it will clock up all the cores properly. So, there seems to
[01:55] <electrofreak> be a problem with the threading and powernowd clocking each of the cores independently. Any ideas on a proper fix? (killing powernowd is a workaround)
[01:58] <psusi> electrofreak, uninstall the powernowd package... it's obsolete and I have requested that it be removed from the archive... the functionality it provides is now provided by the kernel itself
[01:59] <twb> Doesn't it just set the CPU scaling governor to performance on AC and conservative on battery?
[01:59] <psusi> I think that's laptop mode tools...
[02:00] <psusi> though it is interesting that your cores report different clocks... usually all the cores in a multi core cpu must be using the same clock
[02:01] <twb> Last time I looked, all those throttling apps basically just modprobed the driver and then set the governor on ACPI events
[02:01] <twb> i.e. they were all pretty much useless
[02:04] <electrofreak> psusi, well... I don't think that the kernel's version works right either
[02:05] <electrofreak> psusi, I could be wrong maybe
[02:05] <electrofreak> psusi, well, in older CPUs... they clocks were different per core...
[02:06] <electrofreak> but this is a brand new Phenom II... each core clocks differently
[02:06] <psusi> electrofreak, given that it works correctly with one program and not the other, I'd guess that the one is either not actually running multiple threads and keeping all cores busy, or they are running at low priority so are ignored by the governor.. but first thing I suggest is that you remove the powernowd package...
[02:06] <electrofreak> psusi, err... I messed up that sentence... in older CPUs, they clocks on each core were the same. But on new CPUs... each core can clock independently
[02:08] <electrofreak> psusi, well... that program is definitely doing multiple threads... because in top it reports nearly 400% CPU (4 cores) and when I stop powernowd... the temperature jumps up very quick.
[02:08] <electrofreak> psusi, 'stress' actually spawns separate processes.
[02:08] <electrofreak> psusi, I'll try removing powernowd
[02:09] <electrofreak> psusi, although, I might need to reboot now... because it just stopped it and the kernel itself isn't handling it on its own right now (probably because powernowd took over before
[02:10] <electrofreak> psusi, or is there something that I can set in /sys to make the kernel take over again?
[02:17] <electrofreak> psusi, ok. I echo'd "ondemand" into /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor, that seems to work
[02:17] <electrofreak> but now, mprime for some reason doesn't cause any of the cores to clock higher now.
[02:19] <psusi> electrofreak, it's probably nicing itself and iirc, ondemand by default ignores processes using the maximum niceness
[02:20] <electrofreak> nice value is 10
[02:20] <electrofreak> should I try 0 nice?
[02:34] <electrofreak> psusi, ok. I figured this out. have to set ignore_nice_load=0... then everything works fine.
[02:34] <electrofreak> psusi, adding it to sysfs.conf to persist through reboots, too.
[06:50] <pitti> Good morning
[06:51] <pitti> slangasek: nice, thanks
[07:35] <dholbach> good morning!
[09:24] <neeraj> Hi, while uploading my package in ppa, I am getting this error msg again and again or two/six packages which I am packaging. Rejected:
[09:24] <neeraj> Unable to find sugar-presence-service-0.90_0.90.1.orig.tar.bz2 in upload or distribution.
[09:24] <neeraj> Files specified in DSC are broken or missing, skipping package unpack verification.
[09:26] <neeraj> anyhelp? I tried google but not able to find a soln
[09:36] <akheron> neeraj: try building with the -sa option
[09:38] <neeraj> akheron: thanks. I forgot to use "-sa" and kept trying with -s flag :(
[12:48] <pitti> sconklin: I assigned bug 672964 to you, it's a regression in the lucid proposed kernel
[12:48] <pitti> sconklin: diwic reported it, I guess he can supply additional debug info if needed
[13:53] <Riddell> doko: what should we do about -mimplicit-it=thumb ?
[13:54] <Riddell> doko: so far we added it to qt and kde4libs to work around failing to build
[13:54] <Riddell> doko: should we add it to other packages as needed or should it go back in the gcc defaults?
[13:54] <Riddell> currently the kde stack is stuck on http://launchpadlibrarian.net/58639702/buildlog_ubuntu-natty-armel.kdepimlibs_4:4.5.3-0ubuntu1_FAILEDTOBUILD.txt.gz
[14:10] <mdeslaur> cjwatson, ev: bug 673028
[14:35] <Riddell> \sh: could you verify bug 533369 ?
[14:45] <Riddell> oubiwann: hi, what was the outcome of the touch sessions with the Qt people?
[14:52] <\sh> Riddell: I trashedbin my squeeze stuff, but can redo do it tomorrow...not right now...
[14:54] <oubiwann> Riddell: they liked the architecture, have used v1 of the GEIS API (complete with a Qt demo), and are even more excited about GEIS v2
[14:55] <oubiwann> they provided a great deal of feedback on all aspects of utouch, and really improved the quality of the UDS sessions as a result
[14:55] <Ng> 9
[14:55] <Ng> doh
[14:55] <ogra_ac> 10
[14:55] <ScottK> 11
[14:59] <Riddell> oubiwann: so presumably we can look forward to touch on linux being in Qt 4.8?
[14:59] <oubiwann> Riddell: well, it's more complicated than that... full MT support on Linux with Qt depends on XInput 2.1 landing
[15:00] <oubiwann> we're hoping that 2.1 makes it into the X 1.11 release
[15:01] <oubiwann> 1.10 is probably going to come out around Apr 2011, and that will still be too soon for XI2.1 to be fully tested
[15:01] <oubiwann> 1.11 is likely to come out around August of 2011, so that's the target for XI2.1 getting released
[15:02] <oubiwann> toolkits aren't interested in supporting touch officially for linux until 2.1 lands
[15:03] <oubiwann> but the Qt guys are really staying closely involved with the 2.1 dev process and plans, and I would expect that they'll be ready to go as soon as X is
[15:03] <oubiwann> (in other words, I wouldn't expect a 6 month lag from them after August 2011)
[15:07] <Riddell> oubiwann: right, thanks for the update
[15:07] <oubiwann> Riddell: no prob
[15:11] <bilalakhtar> Where can I find a listing of people with upload rights to 'which packageset' and other details
[15:12] <geser> bilalakhtar: the data is in LP and to some part also distributed in the heads of some people
[15:13] <bilalakhtar> geser: I mean, what is the URI to the LP page?
[15:13] <bilalakhtar> since I know there is one
[15:13] <geser> I don't know a single page
[15:13] <bilalakhtar> geser: okay
[15:13] <bilalakhtar> fine then
[15:13] <geser> especially that I don't know of any page in LP that shows upload permissions at all
[15:14] <geser> you have to use the LP API to get the data
[15:14] <bilalakhtar> ok
[15:14] <geser> PPU and similiar (e.g. package sets) are only managed through the LP API
[15:17] <geser> are you looking for something special? perhaps I can tell you the right spots to look at
[15:28] <cjwatson> bilalakhtar: might be easiest to use edit_acl.py from lp:ubuntu-archive-tools - it has a query feature
[15:29] <bilalakhtar> cjwatson: thanks
[15:30] <SpamapS> So.. I'm wondering why there was no discussion of btrfs at uds-n .. don't we want it as a default FS for 12.04? is that being relaxed now?
[15:30]  * SpamapS has started using btrfs for all cache/temporary data.
[15:31] <cjwatson> mostly forgetfulness, but I thought there were still serious issues with reliability and things like being able to use a halfway reasonable percentage of the block device
[15:33] <SpamapS> since UDS-M I've been using it for my local mirror and now I'm working on getting schroot's setup on it
[15:34] <SpamapS> have had no issues, but have never gotten near capacity on a drive. does it just fragment badly?
[15:34] <pitti> I have used it as / (not /home yet) for about half a year without data loss
[15:34] <pitti> however, resuming from RAM often hangs, and I heard that this was particular to using btrfs
[15:36] <jdong> I've used it as / and /home and /srv for a year...
[15:36] <jdong> no data loss but two reformats due to metadata occupying tens of gigabytes of space
[15:36] <cjwatson> SpamapS: I don't know the details.  comments I've heard are that you're lucky if you get it to use even half the disk space.  I think that's unacceptable for Ubuntu
[15:36] <jdong> and performance, I've found, rapidly degrades with time
[15:36] <jdong> cjwatson: it's lately more like 80%, but still not great.
[15:37] <cjwatson> (I haven't looked in a while though, and I recognise that we're not contributing much to the kernel side)
[15:37] <jdong> it's much more irritating when it mysteriously goes slow though...
[15:38] <jdong> particularly with qemu/kvm type workloads (random IO on gigantic files), btrfs can generate a lot of disk traffic
[15:39] <jdong> it's still missing important features like a consistency check / repair mechanism too
[15:41]  * cjwatson grumbles at having to do http://paste.ubuntu.com/528747/ to busybox
[15:42] <SpamapS> jdong: wow.. ok .. so not in 12.04 ;)
[15:43] <jdong> SpamapS: well I don't know. I'm not great at predicting the future, and Ubuntu doesn't have a stake in doing this kernel development right now
[15:43] <jdong> so it's just speculation on our end
[15:43] <jdong> this looks like a case of proverbial "it's ready when it's ready"
[15:44] <\sh> cjwatson: why?
[15:44] <SpamapS> jdong: IMO, if its not ready by 11.04, its not ready for 12.04 given the long term ramifications of a default filesystem choice on an LTS
[15:44] <cjwatson> \sh: see build logs.  irritating header incompatibilities
[15:45] <jdong> SpamapS: well the filesystem is certainly not something to risk mass-exposure to. But who knows, maybe by 12.04 ext4 will be deprecated in favor of btrfs :)
[15:45] <jdong> SpamapS: never know what'll happen in a year+ of Linux dev
[15:48] <jdong> SpamapS: but I think the bottom line is, we'll decide around UDS time for 12.04 with the information then. Right now it's hard to speculate one way or the other
[15:48] <jdong> but users are already welcome to do btrfs installs and play with the technology
[15:48] <SpamapS> jdong: if there is one thing to be conservative about.. default filesystem on an LTS is probably it. ;)
[15:48] <jdong> yep :)
[15:48] <\sh> cjwatson: hmm...wasn't there some discussion about not using <linux/*> includes when avoidable?
[15:49] <SpamapS> jdong: if its not already default for 11.10 .. it would be hard to convince *me* that its ready enough for 12.04. :-P
[15:50] <jdong> SpamapS: your opinion might be different if all the other popular OS'es by 12.04 have features afforded by btrfs-type filesystems.
[15:50] <SpamapS> Seems to me like there's another thing going on, which is changing the way people think about files in general. There's the traditional static folder/tree view, and then there's something else.. I like the idea of a file manager that is entirely time-oriented.
[15:51] <SpamapS> jdong: If they have something btrfs-type that is tested and agreed upon, then lets use that. ;)
[15:51] <jdong> SpamapS: indeed if OS X, Windows, RedHat, and friends ALL had time machine type snapshotting features, live checksumming / recovery, etc... we might get impatient
[15:51] <ebroder> i'm kind of skeptical that's a compelling enough use case to be worth getting impatient over
[15:52] <SpamapS> ebroder: people don't think twice about saving a file if they know it is version controlled. "forever undo" is quite freeing. :)
[15:53] <jdong> ebroder: deep integration with the rest of the desktop of COW snapshotting would make me very impatient ;-)
[15:53] <cjwatson> \sh: yes.  hence "grumbles"
[15:58] <doko> Riddell: are thre bug reports open about this?
[16:06] <Riddell> doko: no, just build logs
[16:17] <doko> Riddell: I'll have a look tomorrow with the linaro people
[16:19] <doko> Riddell: so this is kdepimlibs, qt and kde4libs ?  a bug report would be nice
[16:24] <TeTeT> tkamppeter: hi, I'm encountering a black/white vs color printing problem in eog, I filed a bug against eog, but not sure if it's not actually cups: https://bugs.launchpad.net/ubuntu/+source/eog/+bug/673082
[16:39] <m4t> hey, i've got a .config that fails to boot when compiled with 10.10 32bit toolchain
[16:39] <m4t> i verified this on another maverick install also
[16:40] <m4t> CONFIG_MPENTIUMM and CONFIG_M686 both have the issue
[16:41] <m4t> should i file this under linaro-gcc?
[17:35] <pitti> cjwatson: any idea how this could have happened? https://launchpad.net/ubuntu/jaunty/+source/xserver-xorg-video-geode/2.11.10-1~jaunty1
[17:35] <pitti> cjwatson: Q-FUNK just accidentally uploaded it (was meant for PPA)
[17:36] <pitti> cjwatson: shall I reject the binary?
[17:36] <psusi> jdong: I've been playing with lvm snapshots to test ugprading to natty and then reversing it... very nifty
[17:36] <pitti> it should just have been rejected (upload to stable), and on top of that jaunty is EOL
[17:36] <RoAkSoAx> kirkland: ping?
[17:36] <pitti> wgrant: ^ any idea about this jaunty upload?
[17:37] <cjwatson> pitti: madison-lite on cocoplum doesn't list it
[17:37] <pitti> cjwatson: it was just uploaded a few mins ago
[17:38] <cjwatson> absolutely should have been uploaded, do what you can to reject it
[17:38] <cjwatson> er, shouldn't
[17:39] <pitti> cjwatson: I rejected the binary, but of course the source is there now
[17:40] <RoAkSoAx> pitti: howdy! I have a question for you! I'm gonna ship the scripts (to reduce power consumption) with powernap. So I was wondering if it would be better to install the scripts in usr/lib/powernap/actions and then symlink to  etc/pm/power.d, or should I install them directly to etc/pm/power.d ?
[17:40] <pitti> RoAkSoAx: install directly, please; that's much less confusing
[17:41] <jdong> psusi: yeah and btrfs's potential to extend that to the per-file/per-directory level, once integrated with applications, will be incredible too
[17:41] <RoAkSoAx> pitti: indeed. though I'm also writing a tool to enable/disable scripts easily and also list scripts with their description. So i gues that the tool will just remove the executable bit
[17:42] <pitti> RoAkSoAx: or rename them to .disabled or so
[17:42] <pitti> RoAkSoAx: but chmod -x sounds okay, too
[17:42] <SpamapS> https://launchpad.net/~clint-fewbar/+archive/fixes/+build/2037553/+files/buildlog_ubuntu-lucid-amd64.mongodb_1%3A1.2.2-1ubuntu1.1~ppa1_FAILEDTOBUILD.txt.gz
[17:42] <SpamapS> can anybody explain why this symlink produces this error:
[17:42] <TerminX> anyone know why rsyslog hasn't been synced from debian in quite a long time?
[17:43] <SpamapS> dpkg-deb: building package `mongodb' in `../mongodb_1.2.2-1ubuntu1.1~ppa1_amd64.deb'.
[17:43] <SpamapS> tar: ./usr/bin/mongo: file changed as we read it
[17:43] <SpamapS> /usr/bin/mongo is a symlink
[17:43] <RoAkSoAx> pitti: alright, will evaluate which one is more convenient. Thanks for the Input :)
[17:43] <SpamapS> to ../lib/mongodb/xulwrapper
[17:45] <cjwatson> TerminX: needs merge, somebody needs to look at it by hand
[17:45] <cjwatson> (like all merges)
[17:45] <RoAkSoAx> SpamapS: you doing the symlink manually?
[17:45] <SpamapS> no, with dh_link
[17:46] <SpamapS> it works fine when building locally w/ sbuild
[17:46] <TerminX> cjwatson: ah, I guess there's no specific maintainer for the package then?  I was under the impression that ubuntu had switched to rsyslog by default
[17:47] <TerminX> I don't think anybody looked at it during the maverick dev cycle either
[17:48] <SpamapS> some things just get lost in the scuffle. ;)
[17:48] <cjwatson> TerminX: merges are assigned to the person who touched the package last by default; but not everyone gets around to all their merges
[17:48] <cjwatson> the standard rubric is that if you want to do it, you contact the person who touched it last to avoid duplicating work
[17:49] <RoAkSoAx> SpamapS: idk then... maybe the symlinks gets overriden by something else during the creation of the package (i'm just guessing :) )
[17:49] <SpamapS> RoAkSoAx: at this point all I can do is guess. :-/
[17:49] <ebroder> looking at the diff from debian, there's probably a bunch of stuff you could drop if you merged rsyslog now - stuff like sysklogd transitional code
[17:49] <SpamapS> RoAkSoAx: I suppose I can ls -lR debian/mongodb in the rules file so we see what it looks like before that point
[17:51] <RoAkSoAx> SpamapS: or see if soemthing is installing in /usr/bin/mongo instead of just symlinking
[17:52] <SpamapS> RoAkSoAx: ls -lR will show that I hope
[17:52] <SpamapS> RoAkSoAx: doesn't relaly make sense that it would "change while reading" though
[17:52] <SpamapS> and why it does it only on the buildd's I'm a little confused
[17:52] <juk_> bug-buddy just caught stardict with: ** GLib **: /build/buildd/glib2.0-2.26.0/glib/gmem.c:239: failed to allocate 512 bytes
[17:55] <SpamapS> hmm
[17:55] <RoAkSoAx> SpamapS: try building with a pbuilder instead ..
[17:55] <ebroder> pitti: by the way, i'd very much like to help with the perl-sectomy, or the footprint work more generally. please feel free to throw tasks at me if you'd like
[17:55] <SpamapS> I just updated my lucid schroot and one of the things it pulled down was this:
[17:55] <SpamapS> Get:14 http://archive.ubuntu.com/ubuntu/ lucid-updates/main tar 1.22-2ubuntu1 [390kB]
[17:55] <pitti> ebroder: ooh, much appreciated
[17:55] <RoAkSoAx> SpamapS: ah!1 that might be it then
[17:55] <SpamapS> If it breaks now, there may be a regression
[17:55] <RoAkSoAx> SpamapS: indeed
[17:56] <RoAkSoAx> SpamapS: btw.. is there a meeting today?
[17:56] <SpamapS> RoAkSoAx: yes, 18:00UTC, though I think that will be moved to 16:00UTC going forward
[17:56] <RoAkSoAx> SpamapS: ok cool... will be back later ... my battery is almost drained :)
[17:57] <SpamapS> looks like zul forgot to update the header
[18:09] <pitti> ebroder: do you want to start with some small ones, like cups-driver-gutenprint and libfile-copy-recursive-perl?
[18:09] <pitti> ebroder: not sure whether you followed the changes I already uploaded today?
[18:10] <pitti> ebroder: in the ideal case, packages already don't need anything from perl-modules, so a simple dh_perl -d is enough
[18:10] <pitti> ebroder: for some packages I needed to replace functionality from perl-modules with external programs (like rm -r) or other small replacements
[18:10] <pitti> ebroder: I sent them to Debian, too, one patch is already accepted :)
[18:10] <ogra_ac> pitti, we need to talk abotu the WI tracker some time this week ... (mobile got renamed to arm etc)
[18:11] <pitti> ebroder: the biggest thing left is apparmor-utils
[18:11] <ogra_ac> (not today anymore though, just a heads up that i will ping you some time)
[18:13] <pitti> ogra_ac: sure; please feel free to adapt natty.cfg yourself (~platform on lillypilly)
[18:13] <ogra_ac> ok
[18:14] <ebroder> pitti: sure, the small ones sound fine. i can look at apparmor-utils too if i get a chance, but what is our solution if a package does need something from perl-modules?
[18:14] <pitti> ebroder: for easy cases I rewrote the code to just use perl-base
[18:14] <jdstrand> pitti, ebroder: you might check with kees on the apparmor one-- he may already be working on it
[18:14] <pitti> ebroder: like "dirname"
[18:15] <pitti> ebroder: for doc-base the only place that needed it was --dump-db, which is a debug option; I changed the code to say "Please install perl for this blabla" if you use it
[18:15] <ebroder> pitti: ok, sounds good. i'll try to be sufficiently creative
[18:15] <pitti> ebroder: I haven't yet worked on a package where perl-modules is necessary for core functionality
[18:16] <pitti> ebroder: in that case we still have the option to split out that module from perl-modules, so that we can install it separately
[18:16] <pitti> ebroder: we should make a list of those in the blueprint, so that we can do that in a larger step
[18:16] <pitti> ebroder: so if you stumble over one of those, please make a note there
[18:16]  * ebroder nods
[18:16] <cjwatson> I wouldn't do that casually though, the Replaces forest can get pretty insane
[18:16] <pitti> ebroder: thanks! please let me know about the progress, so that we can coordinate
[18:16] <pitti> cjwatson: no, we should try to avoid that
[18:17] <cjwatson> you'll probably run into File::Path at some point
[18:17] <pitti> fortunately so far it wasn't needed
[18:17] <pitti> you can do surprisingly much with perl-base
[18:18] <kees> pitti, ebroder: so apparmor-utils uses libterm-readkey-perl, librpc-xml-perl in the Depends
[18:18] <cjwatson> libfile-copy-recursive-perl uses File::Copy which is in perl-modules
[18:18] <ebroder> pitti: in the cases where we can just do dh_perl -d, why don't i just make a note on the blueprint? it'll probably be faster for you to just do those than you dealing with a branch from me
[18:18] <kees> actually, ${perl:Depends}
[18:18] <pitti> kees: right, those are fine (as soon as we fix those to not pull in perl); we need to fix apparmor-utils' "perl" dependency itself, though
[18:18] <cjwatson> sometimes you can use the module optionally and implement some other fallback
[18:19] <kees> pitti: it's coming from ${perl:Depends} I assume
[18:19] <kees> pitti: shouldn't we fix dpkg's idea of that instead?
[18:19] <pitti> kees: right, dh_perl adds a perl dependency by default
[18:19] <cjwatson> kees: that's what dh_perl -d does
[18:19] <kees> pitti: so what's the right solution?
[18:19] <pitti> kees: I usually go through "grep -wr use" and check where all imported modules come from
[18:20] <kees> ah, s/dh_perl/dh_perl -d/ in rules
[18:20] <pitti> kees: and once nothing is left, change dh_perl to -d
[18:20] <cjwatson> be sure to check require as well as use
[18:20] <pitti> right
[18:21]  * pitti will still do some maverick SRU catchup and then call it a day; enough breakage for one day :)
[18:21] <pitti> so, good night everyone!
[18:27] <kees> okay, I remain confused. what is the process to make sure I can switch to perl-base?
[18:27] <kees> because it seems like a lot of stuff lives in perl-modules, which requires perl currently
[18:28] <pitti> kees: grep the source for "use" and "require" and check whether all of those are in perl-base, or standalone perl packages (which are seprate dependencies)
[18:28] <kees> pitti: right, I have the list now. I guess doing the perl-name to package is the trick
[18:29] <pitti> kees: for "use foo" I usually do "dpkg -S foo.pm"
[18:29] <pitti> not sure whether there's something better
[18:29] <kees> yeah, that's where I am too. Okay, cool.
[18:29] <pitti> kees: thanks for looking into it!
[18:29] <kees> you bet.
[18:30] <kees> pitti: btw, with the loss of changelog.Debian.gz, people will not be able to examine their local filesystem to determine why a security update to a package was performed...
[18:30] <kees> what happens if I encounter something that requires perl-modules ?
[18:30] <pitti> kees: they just came back :) (in reduced form), see u-d-a@ and planet
[18:31] <pitti> kees: but apt-changelog should pick those up as well
[18:31] <pitti> kees: for simple cases it's often possible to rewrite
[18:31] <kees> require Term::ReadLine;
[18:32] <kees> pitti: ah, top 10 changes, nice.
[18:32] <pitti> e. g. rmtree($dir) -> system('rm', '-r', $dir)
[18:32] <kees> use Data::Dumper
[18:32] <pitti> kees: that's more tricky; perhaps we could use libterm-readline-gnu-perl for that, and un-"perl"-ize (and MIR) that
[18:33] <pitti> kees: Dumper was used in doc-base, but it was only a debugging tool; I did http://launchpadlibrarian.net/58890660/doc-base_0.9.5_0.9.5ubuntu1.diff.gz for that
[18:33] <kees> File::Basename, the list goes on and on
[18:33] <pitti> kees: as I said, this one will be hard :)
[18:33] <pitti> Basename is trivial to express with core Perl, though
[18:33] <kees> hrmpf.
[18:33] <kees> yeah
[18:34] <pitti> kees: I don't (much) expect to actually be able to drop Perl completely in Natty; but working towards it
[18:34] <kees> -    mkpath ($d, 0, 0755);
[18:34] <kees> -    rmtree ($d.$suffix, 0, 0);
[18:34] <kees> +    system ('mkdir', '-m', '-p', $d);
[18:34] <pitti> at least it will be much easier to drop it for custom projects, etc
[18:34] <kees> that's wrong. -m requires an argument
[18:34] <pitti> kees: oops, thanks; didn't come up in testing
[18:35] <kees> I think we'd be better have a perl module that lives in -base that implements all these common uses
[18:36] <pitti> kees: as I said above, for the more complex ones we might actually just split them out from perl-modules
[18:36] <pitti> so that we can install them separately
[18:36] <kees> okay.
[18:37] <pitti> kees: fortunately most packages just look like http://launchpadlibrarian.net/58895007/foomatic-filters_4.0.5-0ubuntu3_4.0.5-0ubuntu4.diff.gz
[18:39] <kees> pitti: heh, good. apparmor-utils seems to make up for it. :) 6 things from -modules or perl itself. :)
[18:40] <pitti> I'll keep that for later then :)
[18:40] <kees> heh
[18:41] <pitti> kees: I'll start with the simple libraries, they should be easy, and can collect necessary stuff along the way
[18:41] <kees> have you replaced File::Temp anywhere yet?
[18:41] <pitti> no
[18:41] <pitti> I touched some 6 packages so far, 4 were trivial (just add -d), one required a simple code change, and doc-base was the one nontrivial one so far
[18:42] <pitti> kees: (doc-base fixed, FTR, thanks for spotting)
[18:42] <kees> pitti: cool
[18:43] <SpamapS> RoAkSoAx: darn, no failure with the updated tar
[18:44] <kees> pitti: oh, actually, sorry, it's still wrong. File::Path::mkpath's $mode is filtered by umask where as mkdir -m is not.
[18:44] <pitti> kees: but it's just a cache from public doc data..
[18:45] <apw> pitti, whome owns the launchpad-janitor scripting ?
[18:45] <pitti> I think having that directory 700 would be wrong
[18:45] <pitti> apw: launchpad?
[18:45] <pitti> apw: you mean the thing that autocloses bugs and so on?
[18:51] <apw> pitti, yeah indeed ... my real question is, is there a way to say 'really don't close this bug' so that we can have a proposed kernel with two uploads, the first one closes a bug and the second reopens it ...
[18:51] <apw> and if there isn't do we think that they would accept a new syntax to allow that
[18:51] <pitti> apw: accepting into proposed doesn't close bugs
[18:51] <pitti> just when they get moved to -updates
[18:57] <apw> pitti, right ... exactly but when it does go into -updates everying in the changelog which is all proposed versions in one block via -v<old updates version> get processed and closed
[18:57] <pitti> apw: correct
[18:58] <pitti> apw: so the followup upload has to change the changelog accordingly to not mention the dropped patches any more
[18:58] <apw> pitti, and i want to be able to close a bug in the first -proposed upload, but undo it in the second -propoesed upload ... so that the bug is not closed when moving to -updates
[18:58] <pitti> we can't close bugs in the first upload
[18:58] <pitti> they aren't fixed if they are only in -proposed
[18:58] <apw> pitti, so it is acceptable to hand edit the changelogs to drop the LP: bits from the first upload to proposed to ensure they don't close on move to updates ?
[18:58] <pitti> apw: there is no actual need to start a new changelog record, though; you could just bump the existing one and drop stuff
[18:58] <apw> pitti, yep ... get you on the proposed not doing anything bit
[18:59] <apw> pitti, that is acceptable ?
[18:59] <pitti> apw: that works for me as well
[18:59] <pitti> whatever is more convenient
[18:59] <pitti> i. e. update the first changelog record, or add a new one for the new version and just retro-fix the previous one
[18:59] <pitti> the former would look less confusing to users, though
[19:00] <apw> pitti, doesn't that mean that our changelog sort of lies ?
[19:00] <pitti> apw: not really IMHO; the bits that get released to -updates never had the dropped changes after all
[19:00] <pitti> apw: but as I said, I'm also fine with your method
[19:00] <apw> pitti, ok thanks
[19:02]  * pitti waves good night for real now
[19:04] <RoAkSoAx> SpamapS: weird then
[19:06] <cjwatson> kees: BTW, best not to do any of this (perl-base -> perl) unless you have to, IMO - I don't think we should be aggressively doing it for stuff not on the CDs
[19:08] <cjwatson> apw: why list them in the -proposed upload in the first place, then?  Why not just say "see LP #nnnnnn" (or some similar syntax which carefully doesn't match the close regex) if you just want to refer to it?
[19:09] <bilalakhtar> pitti: So this means that there won't be a debian/changelog in ubuntu packages from now on?
[19:10] <apw> cjwatson, well we are uploading a -proposed with them in where they should close, then if they fail testing we revert them and want them not to close any more... seems the appropriate thing is to as you say change that first reference from LP: xxx to SEE: xxx and we'll be golden
[19:11] <bilalakhtar> BTW, why is -proposed frozen?
[19:11] <cjwatson> apw: so you're not unconditionally leaving them open in -updates, only if -proposed fails?
[19:11] <cjwatson> bilalakhtar: be careful about the distinction between debian/changelog (source packages) and changelog.Debian.gz (binary packages).  pitti's work only affects the latter (and there's open TB discussion about it)
[19:11] <cjwatson> bilalakhtar: -proposed is frozen to assist the Linaro 10.11 release
[19:12] <bilalakhtar> cjwatson: okay, thanks
[19:12] <cjwatson> or was frozen, I think I saw slangasek saying he was OK with it being unfrozen nowish
[19:13] <apw> cjwatson, we are marking them for closure yes in the first upload to -proposed, then we re-upload to -proposed undoing the commits which didn't work (or could not be verified) so we have a changelog block which has them closing and one which reverts that change.  when that moved to -updates it would erroneously close (via the janitor) so we were checking how to best avoid the bad close.  it seems effecticly removing the bug numbers from the first ch
[19:13] <apw> angelog section is the right approach
[19:13] <cjwatson> or you could just reopen after the janitor closes them
[19:13] <cjwatson> consider how much technical work is worth it :)
[19:14] <cjwatson> technically, a reupload ought to require some degree of reverification, which is expensive
[19:14] <apw> cjwatson, heh indeed, i think updaing the references in the old is easier than touching all the bugs as we can script the former
[19:14] <apw> cjwatson, yes, and the regression testing is meant to occur on the second upload to give us more confidence
[19:17] <lool> Hmm any idea why postgresql-9.0 isn't in natty?  I see it has been in unstable for ~20 days, perhaps we only sync packages which made it to testing?
[19:17] <cjwatson> you can script the latter too ... :-)
[19:18] <cjwatson> lool: no, it's because it delivers at least one binary package (libpq-dev I think) which is also in natty built by another source package.  I asked pitti about it and he said he wasn't sure if he wanted to switch to 9.0 yet
[19:18] <cjwatson> lool: testing isn't related
[19:19] <cjwatson> apw: sounds like a lot more work to me, but as you like ...
[19:19] <lool> cjwatson: Ok; thanks for the explanation, I remember you also mentioned that in your email, just didn't think of this explanation
[19:36] <robbiew> cjwatson: so http://cdimage.ubuntu.com/ubuntu-server/daily/current/ has server images for Mac/PPC32/PS3...was this done on purpose?
[19:37] <robbiew> consolidation?
[19:37] <cjwatson> robbiew: yes, https://blueprints.launchpad.net/ubuntu/+spec/ubuntutheproject-foundations-n-cdimage-ports-consolidation
[19:37] <cjwatson> killing off the ports directories in general
[19:37] <robbiew> ah ha!  I knew there was a blueprint
[19:37] <robbiew> couldn't find it
[19:37] <robbiew> thanks!
[19:38] <robbiew> cjwatson: so from a QA perspective, did we agree to test these as well?
[19:38] <cjwatson> (though the exact set of images being built may well change ...)
[19:38] <cjwatson> certainly not, no
[19:38] <robbiew> cool
[19:38] <robbiew> hggdh: ^^^
[19:38] <cjwatson> there's a separate blueprint somewhere for what we should be testing
[19:38] <cjwatson> this was just reorganisation of what we were already building
[19:38] <cjwatson> mind you, *somebody* should be on the hook to test anything we build
[19:38] <cjwatson> but it shouldn't necessarily be Canonical QA
[19:38] <hggdh> cjwatson, robbiew: thanks
[19:39] <robbiew> cjwatson: ack
[19:39] <robbiew> agreed
[19:39] <robbiew> cjwatson: so much for me requesting PS3s for the Server team
[19:39] <robbiew> lol
[19:44] <ajmitch> robbiew: surely you could get a few PS3s donated to willing community members to test? :)
[19:45] <robbiew> heh...they don't even support Linux as another OS anymore ;)
[19:48] <cjwatson> robbiew: :-)
[19:48] <cjwatson> yeah, I think ps3 was slated to be EOLed, I'm just waiting for somebody who purports to be authoritative for that port to tell me - don't like doing it by fiat
[19:49] <robbiew> cjwatson: so who's authoritative for PS3?
[19:59] <cjwatson> robbiew: good question.  I passed it on to somebody called IIRC Tiago Faria a while back, but I don't know who took it from there
[20:36] <wgrant> pitti: Hm, that's unfortunate.
[20:50] <jdstrand> sbeattie: fyi, apparmor hit maverick-proposed
[20:51] <sbeattie> jdstrand: cool, thanks
[21:40] <lifeless> sladen: hi
[21:43] <sladen> lifeless: hello
[21:48] <highvoltage> hi lifeless and sladen!
[22:04] <mathiaz> cr3: http://people.canonical.com/~chucks/SRUTracker/sru-tracker-bugs.html
[22:04] <mathiaz> cr3: ^^ this is the SRU tracker I mentioned
[22:06] <cr3> mathiaz: thanks, zul actually answered me. email sent to victorp for his information
[23:51] <bdrung> kirkland: thanks for the merge. can you move the errno tool from u-d-t to bikeshed?


[02:56] <andresmujica1> wouldn't be nice if i could mark a bug as duplicate of another one and all the duplicated bugs from the first bug where marked automagically as dupes from the main bug?
[05:05] <hggdh> yes, and I think this is a bug on Malone, already
[05:10] <andresmujica> oh yea, that would be sweet
[05:11] <andresmujica> also i would like to see ia way to mark bugs as related to other bugs, not duplicates but related, so a developer can get an overview a better perspective...
[12:34] <anakron> Hi all
[12:34] <anakron> in which file i can add or remove recommended packages?
[16:18] <test34> What does "BUG: scheduling while atomic: swapper" mean in /var/log/syslog ? it happens when I turn ON my bluetooth headset..
[16:19] <test34> complete output at http://pastebin.com/f79233ca6
[16:35] <milos_> what package is responsible for sound effects in ubuntu?
[20:04] <MrKanister> Hi there. Can somebody set this bug (https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/290194) to wishlist?
[20:05] <crimsun> MrKanister: done.
[20:06] <MrKanister> crimsun: Thank you.
[20:07] <crimsun> np
[21:00] <torkiano> is this bug triaged correctly? bug 38988
[21:00] <kbrooks> Um
[21:00] <kbrooks> I have a poblem here.
[21:04] <kbrooks> I start Pidgin
[21:04] <kbrooks> Connect
[21:04] <kbrooks> Chat to someone
[21:04] <kbrooks> Switch to another app
[21:04] <kbrooks> Switch back
[21:05] <kbrooks> Pidgin freezes
[21:29] <charlie-tca> torkiano: You could ask asac, he´s the triager on it. I would expect it is, if he did it.
[21:32] <torkiano> charlie-tca: ok, i ask him
[21:34] <torkiano> charlie-tca: but is better forward this bug to mozilla? i'm lerning ;-)
[21:35] <charlie-tca> did you talk to asac?
[21:36] <charlie-tca> asac: ping
[21:38] <charlie-tca> torkiano: I did not notice the date on that! It´s pretty old now. Perhaps asking if it is still valid would be a good place to start
[21:38] <charlie-tca> Sorry (:
[21:40] <torkiano> charlie-tca: no problem ;-), i ask for it, thank you
[21:40] <charlie-tca> You are welcome. Good luck with triaging!
[21:42] <torkiano> charlie-tca: I'm closing old untouched bugs. I hope do it well...
[21:42] <charlie-tca> All you can do it try your best. If you have questions, ask here. Someone will help
[21:46] <torkiano> ok charlie-tca, i'm only close old incomplete bugs without response; they are more easy ;-)
[21:47] <charlie-tca> Good place to start. It gets you some experience, right?
[22:15] <Elbrus> torkiano: I don't think you need to close incomplete bugs
[22:15] <Elbrus> they are moved "out of the way" after 60 days
[22:16] <Elbrus> so marking a bug incomplete after a final plee for information is the most appropriate action IIUC.
[22:17] <hacktick1> Elbrus: but arent there old incomplete bugs which dont expire?
[22:17] <torkiano> Elbrus: thank you for the tip, i dont't know that
[22:18] <Elbrus> yah, but I don't think much people look at those, as they are archived... again, if I understand correctly
[22:18] <Elbrus> but that's how I see it
[22:18] <Elbrus> it is good to keep the bugs if they are not solved, better than closing
[22:19] <Elbrus> that's where incomplete IS for
[22:20] <Elbrus> without deliberately asking for old bugs they don't show up in overviews anyway
[22:21] <torkiano> In (https://wiki.ubuntu.com/Bugs/Responses#Incomplete bugs without a response from submitter ) say that  a bug in the "Incomplete" state for more than 4 weeks should be changed to "Invalid"
[22:36] <Elbrus> torkiano: ok, I guess that might be a matter of opinion. just make sure if you do that you give the explanation as given in the url.
[22:38] <test34> I experienced a kernel bug with the latest Ubuntu-2.6.27-9.19 kernel but not with the latest kernel v<IP_ADDRESS>
[22:39] <Elbrus> torkiano: good link by the way, helps me too. Thanks
[22:39] <Elbrus> test34: have you filed a bug?
[22:40] <test34> not yet.. what should I post, the syslog ?
[22:40] <torkiano> Elbrus: ;-)
[22:42] <Elbrus> test34: I don't know exactly, what is the experience? You can start with the bug and describe as best as you can and ask if they need more files
[22:43] <test34> ok
[22:43] <Elbrus> and provide files that you think are relevant
[22:43] <Elbrus> so if you see anything relevant in the syslog that will help
[22:43] <Elbrus> by the way: attach, not include in the report
[22:43] <test34> ok thanks
[22:44] <Elbrus> if you want more help afterwards, you could come back here and write bug <number> here and ask for more help
[23:20] <payload1> hi. i noticed that when purging firefox-3.0 you can still see firefox in gconf /desktop/gnome/url-handler/*
[23:20] <payload1> same for evolution
[23:21] <payload1> installing lynx an galeon or thunderbird
[23:21] <payload1> didnt replaced that
[23:23] <payload1> am i right at filing bug reports for each of      firefox-3.0, evolution, lynx, galeon and thunderbird    or could i file a report which says that this is maybe a general problem and should be checked for each and every package which should or have to modify   url-handlers  ??
[23:59] <Elbrus> payload1: if I am correct you can file 1 bug and use the "also affects" button to tag the other packages


[15:04] <BluesKaj> Hi all
 Yeah but urs still essential to go the website i mentioned earlier (re @IrcsomeBot: <mparillo> You would probably have better luck in #ubuntu)
 Hi (re @IrcsomeBot: <BluesKaj> Hi all)
 If i do all of that, how will i get extensions? (re @IrcsomeBot: <oerheks> install the extention/addon for your browser, then chrome-gnome-shell > https://www.omgubuntu.co.uk/install-gnome-extensions-on-ubuntu)
 Meh ill just reinstall ubuntu
 Meh ill just reinstall kubuntu


[08:08] <anpok> duflu: it didnt feel right to make something called greeter thats just a stripped down basic_server example..
[08:08] <duflu> anpok: There are always more options. It's just /less wrong/ than modifying render_surfaces or demo-shell
[08:09] <anpok> especially since you have to run a shall, a client to the shell, a basic "greeter" nested in the shell, and an application yielding transparent buffers..
[08:09] <anpok> to actually see the difference
[08:10] <anpok> hmm changing render_surfaces did feel less wrong then adding something similar like basic_server .
[08:11] <duflu> anpok: render_surfaces should be considered dead and frozen code. And demo_shell should never get transparency support like any real shell. That leaves only the creation of a demo_greeter if you want a real example
[08:13] <duflu> anpok: I understand your frustration. My first few features took over a month each to get approved. But it gets easier
[08:13] <anpok> not frustrated at all
[08:13] <anpok> well a more real example would be nice, but I had the impression that adding a demo_greeter that is kind of real would be a lot more effort
[08:13] <duflu> Glad to hear it then
[08:14] <duflu> anpok: A demo greeter doesn't have to do anything other than copy the basic server demo and do a glClear to some colour :)
[08:14] <anpok> hmm
[08:14] <anpok> demo_clearer :)
[08:15] <anpok> I had that bad feeling that I did spend too much time on that change
[08:16] <anpok> changing things over agaian is really issue - with each steps things got better - at least thats what I believe :)
[08:16] <anpok> *really no
[08:16] <anpok> -typos_all_over_the_place
[08:17] <anpok> regaring - clear - so thats why you suggested adding some means to change the clear color..
[08:34] <duflu> anpok: Actually I suggested it because of bugs I had run into, not being able to tell if I was moving a client surface or the nested server :)
[12:16] <greyback> Hi guys, anyone here using XMir? I am, and this morning it failed to start the unity-system-compositor. I was stuck at black screen.
[12:47] <mlankhorst> hm :P
[12:51] <mlankhorst> is mir broken on nexus7? I tried flashing the latest devel image, stops refreshing after a few seconds