[00:21] <srid> launchpad down again? this is frustrating.
[00:21] <ebroder> Seems to WFM
[00:21] <srid> down for me since last 2 days
[00:21] <srid> loading forever, that is.
[00:21] <Laney> works here
[00:22] <ebroder> Seems snappier than usual to me. Seems like something weird on your end
[00:22] <srid> IP addr?
[00:22] <cjwatson> srid: I suggest #launchpad - they actually have some influence over Launchpad's responsiveness
[00:22] <cjwatson> we, in general, do not
[00:23] <srid> damn it, it's the damn opera. launchpad loads fine on safari.
[00:23] <srid> cjwatson: ok
[00:26] <ebroder> Crap - typed too quickly. Can somebody unsub ubuntu-motu from bug #394398?
[00:26] <ajmitch> one sec
[00:26] <ajmitch> ok, it's gone
[00:26] <ebroder> Thanks
[00:26] <ajmitch> LP still isn't snappy here :)
[00:27] <Laney> it has to travel through quite some tubes to get to you though
[00:28] <ebroder> ITYM they have to make room on the big truck :)
[00:31] <merkur2k> hey all
[00:33] <merkur2k> anyone here that can give me some help with customizing the installer via a preseed file?
[00:38] <ajmitch> ebroder: it's more like each packet gets hand-wrapped & taken to NZ on a rowboat
[00:40] <cjwatson> merkur2k: I can, but I'm just about to go to bed. I suggest asking on #ubuntu-installer during European working hours
[00:40] <cjwatson> merkur2k: and, if you haven't already, read the preseeding appendix in the installation guide (linked from help.ubuntu.com) first
[00:41] <merkur2k> ok, it might be a simple one. I am wanting to run a fairly complicated script from preseed/late_command that needs user input, but the installer has its own dialog up that blocks the screen
[00:41] <cjwatson> you'll need to use debconf if you want to interact with the user; not simple ;-)
[00:41] <merkur2k> just looking for suggestions or ideas for fixes or alternate methods
[00:42] <merkur2k> it is too interactive to be able to ask questions in advance
[00:42] <cjwatson> can talk you through the issues and possible fixes tomorrow or whatever
[00:42] <merkur2k> ok
[00:42] <cjwatson> debconf doesn't necessarily mean in advance
[00:43] <merkur2k> at the very least it would just be nice to have some progress feedback other than "running preseed command"
[00:43] <merkur2k> :)
[00:44] <merkur2k> but have a good sleep, i will be around
[02:39] <twb> Given an arbitrary source package (e.g. darcs) and release (e.g. feisty), how can I find out if there is a PPA or backport for a recent version of that package for that release?
[02:40] <ebroder> Google
[02:40] <twb> That is plan B.
[02:40] <twb> I had the impression that Launchpad had some sort of predictable naming scheme for PPAs
[02:40] <ebroder> Not really. They're arbitrary
[02:41] <twb> Bummer, thanks.
[02:41] <ebroder> People creating PPAs for backports usually create a team with a name similar to the package, e.g. https://launchpad.net/~git-core
[02:41] <ebroder> But that's entirely at the maintainer's discretion
[06:53] <pitti> Good morning
[06:54] <StevenK> Morning pitti
[06:55] <StevenK> pitti: So, lool wanted me to fix clutter to build a .pot. I've added langpack.mk to it's rules file, is that all I have to do?
[06:56] <pitti> StevenK: that should do; build log will tell :)
[06:58] <StevenK> pitti: But the .pot doesn't turn up anywhere?
[06:58] <StevenK> pitti: I can pastebin the build log, if you wish
[06:58] <pitti> StevenK: then it apparently doesn't use standard intltool?
[06:59] <pitti> StevenK: I just wonder why clutter has translatable strings in the first place; isn't it just a graphics lib?
[07:00] <pitti> pochu: the total ddeb archive size is 164 GB, 6 arches, 5 releases
[07:00]  * pitti cleans up gutsy
[07:01]  * StevenK waits for fbreader to finish building
[07:01] <StevenK> pitti: I'm not sure about a delta from Debian for the removal of -qt and -maemo
[07:01]  * ScottK decides not to wait for kdesdk to build and goes to bed.
[07:02] <pitti> StevenK: lool reviewed clutter and didn't complain about a missing pot
[07:02] <StevenK> pitti: See later comment
[07:02] <pitti> ah
[07:05] <pitti> laga: devkit-power is already used, yes; pm-utils needs to grow support for quirks, it's on the TODO list (https://wiki.ubuntu.com/Halsectomy)
[07:05] <pitti> laga: most devices today shouldn't need quirks any more, but it's still needed for old hw
[07:06] <dholbach> good morning
[07:12] <StevenK> pitti: http://paste.ubuntu.com/216679/
[07:15] <pitti> StevenK: looks good
[07:15] <pitti> hey dholbach! *hug*
[07:16]  * dholbach hugs pitti back
[07:16] <dholbach> hi thekorn
[07:17] <thekorn> hey dholbach
[07:17] <superm1> hi pitti.  so with the old HAL world, I was able to prevent partitions from being exposed in nautilus as user mountable with a nice FDI file.  with devicekit-disks, does similar functionality carry over?
[07:19] <pitti> superm1: yes, there is; this is just being re-added, see https://bugs.freedesktop.org/show_bug.cgi?id=22707
[07:20] <pitti> superm1: also, bug 394088
[07:20] <superm1> pitti, ah spectacular.
[07:20] <superm1> yeah i was gonna point out that dell utility partitions are getting mounted and shown too which brought it to my attention
[07:20] <pitti> superm1: our /lib/udev/rules.d/95-devkit-disks.rules already has an earlier version of that patch
[07:20] <superm1> which reading through is already in your comments from a few days ago
[07:21] <pitti> superm1: could you try the patch on the fd.o bug and verify that this covers it?
[07:21] <pitti> you can just apply it to /lib/udev/rules.d/95-devkit-disks.rules and reboot or udevadm trigger
[07:21] <superm1> pitti, yeah i should be able to tomorrow morning
[07:22] <pitti> unfortunately I wiped my recovery partition in a sad accident
[07:22] <superm1> well the utility partition and recovery partitions are different beasts though
[07:23] <pitti> tried to dd an image to my USB stick and accidentally picked sda..
[07:23] <superm1> after things are sorted for the utility partition, i'm planning on having a third party rule that will be part of the recovery media creation tool on factory shipped ubuntu and rhel6 systems
[07:23] <superm1> ah that'd do it
[07:25] <pitti> superm1: that would work; you should put it into /etc/udev/rules.d/
[07:26] <superm1> pitti, well it comes part of an installed system in a proper deb or rpm
[07:26] <pitti> ah, ok; /lib then
[07:28] <superm1> normally i'd say it's best to just put it in that upstream devdisk-disks.rules, but unfortunately the partition naming scheme clashes with that of the one for windows factory shipped systems and would cause people with a windows factory shipped system to not have access to their data from linux in a dual boot scenario
[07:33] <StevenK> pitti: So, I've done everything for fbreader aside from the i18n, since I have no idea how to sprinkle in a standard intltool build system
[07:34] <pitti> StevenK: that'd indeed be a more intrusive patch, and you should really check with upstream first that they'd take it
[07:34] <StevenK> pitti: Right.
[07:35] <StevenK> pitti: So does fbreader have a hope of getting approved without i18n?
[07:35] <pitti> StevenK: well, if you need it in mobile, sure
[07:35] <pitti> but as I said, it's really an ugly wart
[07:35] <pitti> and I really recommend fixing it
[07:36] <pitti> sure, it's a day of work, but if you consider it an important use case, it's well worth it
[07:36] <pitti> the intltool build system is easy to do
[07:36] <pitti> most of the work is writing some python code to generate .po files from the existing xml files
[07:39] <pitti> superm1: just uploaded a new dk-disks with current ignore rules
[07:40] <pitti> (needed for NBSing out libsgutils2 anyway)
[08:09] <StevenK> pitti: fbreader uploaded
[08:12] <pitti> thanks
[08:12] <StevenK> pitti: Bug task slammed back to New, too
[08:58] <lool> StevenK: +include /usr/share/cdbs/1/rules/langpack.mk
[08:58] <lool> StevenK: that's not mergeable in Debian AFAIK
[08:59] <lool> StevenK: You could have used -include foo to the same effect, but that would have been mergeable in Debian; I fixed clutter/clutter-gtk in Debian's pkg-gnome SVN to include gnome.mk instead of autotools.mk which should pull in langpack.mk automatically
[08:59] <pitti> ( ^ confirmed)
[09:23] <StevenK> lool: Okay, I'll fix them both soonish
[09:34] <ogra> is my system supposed to drop out of usplash after finding the initramfs with the last kernel update or did i just see a race ?
[10:26] <chrisccoulson> hi asac
[10:27] <asac> hi
[10:34] <coolbhavi> hello
[10:35] <coolbhavi> do ppa's and archives use different buildd's?
[10:35] <Nafallo> coolbhavi: yes
[10:38] <coolbhavi> Nafallo, please take a look: package is building on my ppa https://edge.launchpad.net/~bhavi/+archive/bhavi-upstream-testing/+build/1116212 but ftbfs on archive buildd: http://launchpadlibrarian.net/28954351/buildlog_ubuntu-karmic-i386.libselinux_2.0.82-1ubuntu1_FAILEDTOBUILD.txt.gz
[10:38] <Nafallo> coolbhavi: ehrm. why would I be a good person to look at that?
[10:38] <Keybuk> pitti: quick reply to your mail
[10:38] <Keybuk> pitti: the Mini 9 has an SSD, I/O seek and load times are _rarely_ an issue
[10:39] <coolbhavi> Nafallo, okay anyone please guide am confused now..
[10:39] <pitti> Keybuk: well, cold vs. hot cache makes a _tremendous_ difference for gnome-panel, so I wondered how big of an impact it has on ssd
[10:40] <seb128> pitti, most of the gnome-panel start time on my laptop is the menu building
[10:41] <seb128> ie it starts in 1.5s rather than 6s when there is no .desktop installed
[10:41] <pitti> seb128: right, I aked Key to time gnome-menus-ls.py with cold and hot cache
[10:41] <pitti> for me that's 10s (cold) vs. 0.1 (hot)
[10:41] <pitti> seb128: that's what I discussed with vuntz on LinuxTag
[10:41] <Keybuk> pitti: will do that this morning :-)
[10:42] <pitti> Keybuk: it's not urgent (I won't actually get to this in the next weeks), but I'm curious
[10:42] <pitti> Keybuk: thanks
[10:43] <coolbhavi> pitti, can you please help me? /me scratches his head
[10:43] <pitti> coolbhavi: I guess your PPA package was built earlier, and a new kernel broke it or so?
[10:44] <coolbhavi> pitti, okay now what to do?
[10:45] <pitti> coolbhavi: I didn't look into it yet, it probably nees a small fix for current linux-libc-dev
[10:45] <Keybuk> pitti: I'm doing the i386 vs. i586 performance tests this morning, easy enough to slip that one in as well
[10:45] <pitti> Keybuk: oh, does that make a significant difference?
[10:45] <Keybuk> pitti: I'll tell you when I've done the tests
[10:45] <pitti> good luck
[10:45] <Keybuk> it certainly did with the last set of test CDs we made
[10:45] <Keybuk> but we think we made those wrong :p
[10:46] <Keybuk> the last test proved that the new gcc + i586 makes a much faster install than the old gcc + i386 ;)
[10:46] <coolbhavi> pitti, okay, in the archive or in the source that I kept for sponsoring?
[10:47] <pitti> coolbhavi: in libselinux
[10:47] <seb128> hey coolbhavi
[10:47] <seb128> coolbhavi, thanks for your work on the pango update
[10:48] <coolbhavi> okay pitti hey seb128 no mention
[10:48] <coolbhavi> pitti, sorry for the mistake I created
[10:48] <pitti> coolbhavi: don't worry; it wasn't a mistake, just a timing issue
[10:48] <pitti> these things are perfectly normal in a dev release which changes as fast as Karmic
[10:49] <pitti> coolbhavi: the original version would be FTBFS as well now, so it's a completely new issue
[10:50] <coolbhavi> I changed the cflag thing and tested it on my PPA it built so I created a diff
[10:52] <coolbhavi> pitti, now also I tested out on my PPA its building fine
[10:52] <coolbhavi> but I didnt think it would ftbfs in the archive
[10:56] <laga> pitti: ok, thanks for the input re devicekit and quirks. i read an email from the pm-utils guy from last year saying that he didn't want the quirks in pm-utils, i guess that has changed then
[10:57] <pitti> laga: well, it has to
[10:57] <pitti> nothign except pm-utils is using them
[10:57] <ogra> pitti, any chance we get the drum sound back into gdm at some point ?
[10:57] <pitti> ogra: I consider that a feature :-P
[10:57]  * ogra doesnt 
[10:57] <ogra> :)
[10:58] <pitti> anyway, would need to be hacked into the simple greeter
[10:58] <ogra> i like that i can hear when my system is done booting without watching the screen
[10:58] <pitti> but DX has some plans for this greeter anyway, I think
[10:58] <ogra> and i gues TheMuso likes that too :)
[10:58] <ogra> *gues
[10:58] <ogra> s
[10:58] <ogra> pfft
[11:00] <TheMuso> ogra: Yeah I have been meaning to look into that. It may be a matter of tweaking the default sound theme for the gdm session.
[11:00] <ogra> yeah, i bet its not to hard
[11:00] <pitti> ah, indeed
[11:01] <pitti> I keep forgetting that it's a normal gnome session now
[11:01] <lool> pitti: I made the same remark to kirkland about the cron job which should move to PAM (slangasek was complaining about the usage of a cron which spams syslog°
[11:01] <lool> pitti: I think the issue was that you need to update more frequently than on each login, perhaps to display up-to-date information when displaying it within screen for instance
[11:02] <TheMuso> After all, pulseaudio gets run by GDM, and if you press the backspace key in the password field, you get a sound.
[11:02] <lool> pitti: But I didn't confirm that; perhaps this information should simply be updated whenever it's needed rather than regularly though; I agree
[11:02] <pitti> lool: but then screen should directly display the load
[11:02] <pitti> instead of jumping through the python/cron -> motd -> read motd hoop
[11:03] <pitti> a static file is simply not the right thing for this kind of information which updates every second
[11:03] <pitti> (also, why do we need a load, etc. in motd in the first place?)
[11:04] <lool> pitti: It's not just the load, it's a bunch of things like e.g. number of packages which are update-able
[11:04] <pitti> lool: right, but that can be updated in the apt cronjob
[11:05] <pitti> it just feels like throwing a lot of resources into trying to feed dynamic information into a static file
[11:05] <lool> pitti: I don't want to dive into specifics; I made the same high level remarks than you did, but I don't use it
[11:06] <lool> To answer this fully, I would have to check every plugin and see how it could be made efficient
[11:06] <lool> I agree with you on APT updates and on load; I don't know what else is involved
[11:28] <Keybuk> pitti: replied with numbers
[11:28] <pitti> Keybuk: wow, SSD has quite an effect
[11:29] <pitti> thanks
[11:29] <Keybuk> SSD has the effect of eliminating "hot cache" issues from your performance tests
[11:29] <pitti> it's a worthwhile optimization for spinning disks still
[11:29] <Keybuk> since it's almost as fast to read from the SSD as it is from the page cache
[11:29] <Keybuk> sure
[11:29] <Keybuk> but that's not the problem I see
[11:29] <Keybuk> the problem I see is that there are still fundmental performance issues with gnome-panel *after* you eliminate the I/O problem
[11:30] <seb128> it's named libbonobo
[11:30] <seb128> and sync calls
[11:31] <Keybuk> sync calls wouldn't show up as CPU time
[11:32] <seb128> how much cpu usage do you get?
[11:33] <Keybuk> I don't have a recent chart to hand, but it's a fair amount
[11:34] <seb128> ok, I've no been looking at that because it was so small on my chart compared to disk use
[11:34] <seb128> but I'm using a regular disk
[11:34] <seb128> and 80% of the gnome-panel start here is ios
[11:34] <Keybuk> right, when you're using a regular disk, the I/O wait and load times is what will show up
[11:34] <pitti> hm, an autoreconf in gnome-panel adds "SHAVE_INIT(., enable)
[11:34] <pitti> " to configure
[11:34] <pitti> which fails
[11:34] <Keybuk> seb128: ah, be careful
[11:34] <Keybuk> don't fall into *that* trap
[11:34] <pitti> does that ring a bell with anyone?
[11:35] <seb128> pitti, no
[11:35] <james_w> pitti: it fails with a syntax error in configure?
[11:35] <Keybuk> seb128: if a process is waiting for I/O, it'll show up as I/O wait
[11:35] <pitti> james_w: yes
[11:36] <Keybuk> even if it's caning the CPU at the same time for something else
[11:36] <james_w> pitti: check Makefile.am has "ACLOCAL_AMFLAGS = -I m4"
[11:36] <seb128> Keybuk, ah, I didn't know that
[11:36] <Keybuk> so the "80% is I/O" just means that on a rotary disk, you spend 80% of your time in I/O wait
[11:36] <pitti> james_w: find -name Makefile.am | xargs grep ACLOCAL_AMFLAGS -> nothing
[11:36] <Keybuk> if you take away the I/O, it often doesn't speed it up by removing that
[11:36] <Keybuk> you just expose what else it was doing while it was waiting for I/O
[11:36] <Keybuk> often in another thread, etc.
[11:36] <seb128> Keybuk, ok, it will just unmask the cpu use
[11:37] <seb128> I see
[11:37] <james_w> pitti: if there is m4/*.m4 then try adding that line, it fixed it in other packages
[11:37] <pitti> james_w: to all 25 Makefile.am files? *sigh*
[11:37] <james_w> pitti: just ./Makefile.am should work
[11:37]  * pitti sobs at autotools breakage the 23948234th time
[11:37] <james_w> pitti: then autoreconf
[11:37] <seb128> pitti, in configure.ac is usually enough
[11:38] <james_w> fwiw, autoreconf tells you that you should do this :-)
[11:38] <seb128> it has "AC_CONFIG_MACRO_DIR([m4])" already
[11:38] <pitti> james_w: autoreconf outputs several hundred lines, admittedly I didn't read them all
[11:39] <Keybuk> if autoreconf outputs more than a dozen lines, you probably have a problem :p
[11:39] <seb128> pitti, "libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am." is displayed indeed
[11:40] <james_w> admittedly only if you run with -v and work out that that particular message is the one you should pay attention to
[11:40] <pitti> james_w, seb128: I think that helped; thanks!
[11:40] <james_w> np
[11:41] <seb128> that's the only message from autotools
[11:41] <seb128> the flood is for the documentation which you don't really care about
[11:42] <pitti> yay, gnome-panel configured, building now
[11:52] <dholbach> who'd like to run a session on merging at UDW? or about anything else ubuntu-develop-y?
[11:52] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep still has some open slots
[11:52] <StevenK> Hmmm. How do I change CPU frequency scaling?
[11:52] <ogra> StevenK, you cant anymore
[11:52] <ogra> its builtin ...
[11:53] <laga> ogra: so there is only one governor?
[11:53] <StevenK> But I don't want this machine to be running at 2GHz
[11:53] <ogra> at least the governor is hardcoded now
[11:53] <wgrant> StevenK: The GNOME Panel frequency scaling applet will let you change things temporarily.
[11:53] <laga> ogra: it might still be possible to change to governor in /sys
[11:54] <StevenK> I wasn't after temporarily, either. :-)
[11:54] <wgrant> Is ondemand not sufficient to reduce it?
[11:54] <ogra> StevenK, it is set to performance during initramfs and should switch to ondemand after boot
[11:54] <ogra> check if its at ondemand now
[11:54] <StevenK> How do I check?
[11:54] <ogra> if not, file a kernel bug
[11:55] <StevenK> Since that's one of the things I'm not clear on
[11:56] <ogra> cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
[11:57] <ogra> should be ondemand
[12:25] <ScottK> pitti: Is there a wiki page on how to make multimedia keys work in Karmic?  I've got a Dell Mini 10v that's not very happy in that department and I'd like to look into it.
[12:30] <alkisg> asac, just notifying that I'll be here for the next few hours, in case you'd like feedback on https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/391040
[12:42] <StevenK> pitti: You'll look at fbreader today?
[12:43] <StevenK> lool: So, should I undo the change to clutter-gtk, and fix clutter to use gnome.mk?
[12:46] <lool> StevenK: I guess it's ok as long as the person doing the clutter/clutter-gtk merges know that the langpack include can be dropped
[12:47] <lool> StevenK: I had in mind to do a couple of Debian uploads and then ask for syncs, but didn't have time yet; I guess we'll get the changes after next upstream release
[12:48] <StevenK> lool: Well, I screwed it up, so I should fix it.
[12:51] <lool> StevenK: It's not very screwed up, just a bit inelegant; if you like to fix it, perhaps you can do a merge from a snapshot of the SVN packages?
[13:20] <pitti> StevenK: okay; so mobile team (you, lool, etc.) are fine with broken translations?
[13:20] <lool> pitti: Which one?
[13:20] <pitti> ScottK: incidentally I just updated https://wiki.ubuntu.com/Hotkeys/Troubleshooting for Karmic last week :)
[13:22] <pitti> lool: fbreader
[13:22] <pitti> lool: it doesn't use gettext, but translated xml files
[13:23] <ScottK> pitti: Thanks.  I'll have a look.
[13:25] <tseliot> cjwatson: I managed to get the debian installer to install my product-check udeb (to check hardware and halt the installer) but the script in lib/debian-installer-startup.d doesn't seem to be called: https://pastebin.canonical.com/19636/
[13:26] <tseliot> cjwatson: am I supposed to tell which script the installer should use in debian-installer-startup.d ?
[13:30] <lool> pitti: That sounds bad
[13:32] <dpm> pitti: lool, StevenK: if the decision is to go with xml translations (I'd prefer gettext as well, but I realise this might require some work and coordination with upstream), I'll tell Ubuntu translators that at least they can translate the xml files and also send them to upstream - or maybe someone from the community might want to have a go at adding gettext support to fbreader upstream
[13:32] <cjwatson> tseliot: name shouldn't matter. To debug it I suggest booting with BOOT_DEBUG=3, exiting the *first* shell you get (but not the second), and stepping through what /sbin/debian-installer-startup would do by hand
[13:32] <pitti> lool, dpm: adding gettext support and changing the build system doesn't actually sound hard; one just needs to write a script to translate the existing .xml files to .po files
[13:34] <tseliot> cjwatson: it's an automated installation and after I choose it, there's no way to exit. Or are you suggesting some CTRL+ALT+F1?
[13:35] <cjwatson> tseliot: so make it not automated for the purposes of debugging! :-)
[13:35] <cjwatson> tseliot: i.e. boot the installer with BOOT_DEBUG=3 on the kernel command line to see what it's doing
[13:36] <cjwatson> tseliot: when you do that, it will give you the shells I mentioned, regardless of any automation
[13:36] <lool> pitti: I think gettext has some support for XML; but I have no idea whether it applies here
[13:37] <dpm> pitti, lool: do you mean that the most work would be simply in writing a one-time script to convert the existing xml files to PO in order to reuse existing translations? I thought the most (or at least most intrusive) work would be to add gettext support (the code uses string id's instead of the English strings)
[13:37] <pitti> lool: no, that's just intltool
[13:37] <pitti> dpm: right
[13:37] <pitti> dpm: as far as  I can see, all strings are defined in a single .c file, in a string_constant = blabla('string') manner
[13:38] <pitti> trivial to wrap that in a _()
[13:38] <lool> pitti: I think xgettext can read Glade files
[13:39] <dpm> pitti: they are in several files (although I guess that's not important), but I think the problem is that string id's are used instead of the English texts. If we wrap them in _() we're going to get the id's as msgids
[13:40] <pitti> dpm: right, the English strings need to go into that file
[13:41] <tseliot> cjwatson: it looks like s37speakup fails with "line 1: cannot open /proc/cmdline: no such file" then debian-installer-startup exits
[13:41] <dduck> hi
[13:41] <dduck> are here ubuntu developers?
[13:44] <dpm> pitti: I'm not sure I can follow. So you're proposing:
[13:44] <dpm> 1) adding gettext support to the code
[13:45] <dpm> 2) replace the string id's in the code by the English strings in the .cpp file where those are defined
[13:45] <dpm> 3) wrap those replaced strings in _()
[13:45] <pitti> right
[13:46] <lool> Replacing the string ids sounds like a large diff
[13:46] <pitti> that's why I said that this should be cleared with upstream first
[13:46] <pitti> it's much easier to do that one-time (with the xml->po conversion), etc.
[13:48] <dpm> pitti, lool: ok, I understand it now, thanks. For me 1) is the gray area, since I don't know how the xml strings are loaded at the moment and I don't really now how much work would be to get rid of their own special l10n system and replace it by gettext
[13:49] <pitti> dpm: I suppose it's a manday of work in total
[13:49] <pitti> but, it's really only worth it if upstream takes it
[13:50] <pitti> maintaining that large delta forever would be a PITA
[13:51] <tseliot> cjwatson: that happens because /proc is still empty
[13:55] <dpm> pitti: lool, StevenK: would anyone from the mobile team be willing to do this work for fbreader if I contact upstream (maybe some Ubuntu translators might want to help as well)?
[13:56] <lool> StevenK: ^
[13:57] <cjwatson> tseliot: sounds as though you ignored my advice to exit the first shell straight away, and use the second one it gives you
[13:57] <cjwatson> tseliot: the first shell is immediately before /proc is mounted
[14:00] <tseliot> cjwatson: I can get to the isolinux (boot) screen and to a second shell in which I can select the automatic installation (which then I customise to pass it BOOT_DEBUG=3). Is it wrong?
[14:00] <cjwatson> on the isolinux boot screen, press F6 to get to extra options
[14:00] <cjwatson> add BOOT_DEBUG=3 to the kernel parameters there
[14:00] <cjwatson> press enter
[14:00] <cjwatson> wait until you get a Unix shell
[14:00] <cjwatson> type 'exit'
[14:00] <cjwatson> you will get another Unix shell
[14:00] <cjwatson> do your work there
[14:05] <StevenK> dpm: I would be, yes.
[14:15] <dpm> StevenK: then I'll contact upstream with the proposal and you on CC. Depending on what they say, I'll then also tell Ubuntu translators, since some of them might be able to contribute to the technical work. Sounds ok?
[14:19] <ScottK> jdstrand: Just about to upload clamav with your apparmor change.  I didn't get to it over the weekend.
[14:21] <jdstrand> ScottK: oh np. there is no rush on that-- it is just sometime during the cycle
[14:22] <ScottK> Right. It was mostly I said I'd do it over the weekend and then didn't.
[14:25] <tseliot> cjwatson: F6 doesn't seem to do anything on the isolinux boot screen
[14:28] <tseliot> cjwatson: never mind, I got to the 2nd shell
[14:28] <ogra> doko, the debian package has the same upstream version, i thought it was an upstream change
[14:29] <ogra> (re binutils)
[14:29] <ogra> doko, the differentce is that debian builds with gcc-4.3
[14:30] <cjwatson> tseliot: ok
[14:31] <doko> ogra: the debian package doesn't have the patch applied
[14:31] <ogra> oh, i thought it was accepted upstream
[14:34] <tseliot> cjwatson: it looks like my script is not in /lib/debian-installer-startup.d/ and this is why it's not called.
[14:34] <tseliot> cjwatson: currently I make sure that it's installed by adding the package to the list in pkg-lists/local
[14:35] <tseliot> maybe the package is installed after debian-installer-startup
[14:38] <cjwatson> tseliot: no, pkg-lists is entirely processed at build-time not run-time
[14:39] <cjwatson> tseliot: I don't know why your udeb wasn't included; check the d-i build log
[14:39] <tseliot> cjwatson: ok, thanks
[15:08] <StevenK> dpm: Sorry, I was AFK. That sounds great.
[15:09] <dpm> StevenK: np, cool, I'll do that, then.
[15:52] <smoser> anyone else seeing timeouts on keyserver.ubuntu.com ?
[15:53] <smoser> on --send-keys, i'm getting "gpg: keyserver timed out" and "gpg: keyserver send failed: keyserver error"
[16:33] <kirkland> pitti: yo
[16:33] <ogra> ...ghurt ?
[16:34] <ion> May the Schwartz be with you
[16:34] <pitti> hey kirkland, good morning
[16:35] <kirkland> pitti: howdy howdy
[16:35] <kirkland> pitti: so you're hating on update-motd as a daemon :-)
[16:35] <pitti> ion: Mr. Coffee or Mr. Radar?
[16:35] <liw> kirkland, he's not the only one
[16:35] <pitti> kirkland: well, it's a very large club to slam a small problem :)
[16:35] <kirkland> pitti: i can revert the upload, but i need to figure out what an acceptable approach might be to all parties
[16:35] <kirkland> liw: lool: right, i appreciate your views too :-)
[16:36]  * liw rejects the entire notion of automatically editing /etc/motd to start with :)
[16:36] <pitti> kirkland: perhaps we should step back for a while
[16:36] <pitti> kirkland: what is the actual goal? displaying system stats on login?
[16:36] <pitti> kirkland: since I don't think that modifying /etc/motd is your actual goal, it's just one way to reach your actual goal
[16:37] <pitti> kirkland: if you want to display system stats on login, wouldn't that be so much easier to do directly in an optional pam module?
[16:37] <kirkland> pitti: i don't think it's about the stats at all, at this point
[16:37] <kirkland> pitti: the goal is to provide the system administrator, as well as other packages, a method to dynamically inject interesting information into the MOTD
[16:38] <pitti> modifying a static system configuration file every 5 seconds seems like an approach that can only result in weird hacks?
[16:38] <pitti> kirkland: again, into /etc/motd, or for an user to see when he logs in?
[16:38] <kirkland> pitti: as for the system stats, they are inherently always stale (which was part of the motivation for the byobu-approach to delivering such system stats)
[16:38] <pitti> (since the latter can be done with a pam module, and doesn't need motd)
[16:39] <kirkland> pitti: fair enough
[16:39] <kirkland> pitti: we considered that approach back in August
[16:39] <pitti> kirkland: I'm just trying to understand what you actually want to achieve
[16:39] <kirkland> pitti: i'm happy to revisit it though, as it's been almost a year
[16:39] <pitti> and obviously I don't know all the history
[16:39] <kirkland> pitti: the objection to pam (actually, it was /etc/profile.d that we examined) was that it could introduce a delay on login, gathering such statistics
[16:40] <liw> kirkland, what is the goal of modifying motd?
[16:40] <kirkland> pitti: particularly the calculation of the updates available
[16:40] <pitti> kirkland: well, that's an one-time 0.1 second penalty, as opposed to the permanent penalty you pay by having a resident python daemon..
[16:40] <kirkland> pitti: i suppose we could handle those particular cases with appropriate caching
[16:40] <pitti> kirkland: well, I'm not saying that you should swing to the other extreme and calculate _everything_ on the fly :)
[16:40] <lool> kirkland: Concerning available updates, there's a daily cron, perhaps you could hook into that?
[16:41] <pitti> kirkland: e. g. the apt cron job could write that information into a cache, and load etc. is cheap to calculate
[16:41] <kirkland> lool: yeah, just catting /var/run/updates-available would be the cheapest alternative
[16:41] <pitti> kirkland: you could still have a motd.d/ with scripts, which are run by that pam module
[16:41] <pitti> and one would just display apt's cache file, the other would output the load, etc.
[16:42] <pitti> but then motd could remain static, cause less headache to admins who modify it (and backup systems), and avoids all the cron/daemon stuff
[16:42] <tseliot> cjwatson: it looks like my package is only added to the packages pool (in binary/pool/main/p ) but it's not installed. Maybe I should use anna-install to make sure that the package is installed?
[16:43] <kirkland> liw: motd = message of the day, but it's no where near that dynamic in its non-update-motd implementation
[16:44] <liw> kirkland, I know what motd is, and I know it is semi-useless for providing info to people... so what is your goal in modifying it? :)
[16:44] <kirkland> pitti: okay, so drop the cronjobs, drop the daemon;  replace it all with a compiled-c pam module that runs every time a user logs in that executes each of the update-motd scripts, concatenating the results
[16:45] <kirkland> liw: to make it more useful
[16:45] <pitti> kirkland: for efficiency it could provide some standard stuff itself, such as load
[16:45] <pitti> kirkland: but well, it shouldn't matter that much
[16:45] <pitti> login, with all the profile.d/, ecryptfs, etc. stuff is so slow that it would hardly matter
[16:46] <pitti> kirkland: if that'd be feasible, I would certainly like it much better personally; however, what do _you_ think?
[16:46] <kirkland> pitti: you think it's better as a pam module?  because it would be like a 5-line script in profile.d ?
[16:46] <vadi2> I'm not sure where to report this, but the rafal.ca mirror has a 404 on the update manager kde version 0.111.8 for jaunty
[16:46] <pitti> kirkland: oh, if profile.d/ works, so much the better
[16:47] <pitti> kirkland: right, that already has legal.sh
[16:47] <pitti> kirkland: great, that's even easier :)
[16:48] <pitti> kirkland: so, /etc/profile.d/ubuntu-system-info.sh should be all you need?
[16:49] <cjwatson> tseliot: putting it in pkg-lists/local should have caused it to be included in your image. anna-install will *not help you at all*, nor will *any run-time methods*.
[16:49] <kirkland> pitti: i think it would make more sense to keep sysinfo a consumer of a generic update-motd script in profile.d
[16:49] <kirkland> pitti: i've gotten a few random emails from people telling me how they're using update-motd for their unique situations
[16:50] <pitti> kirkland: "sysinfo" is the landscape thingy in your context?
[16:50] <kirkland> pitti: but if you're okay with that approach, so am i
[16:50] <kirkland> pitti: yes, landscape-sysinfo is one consumer of update-motd
[16:50] <pitti> kirkland: sure, I don't mind one more level of indirection
[16:50] <kirkland> pitti: cool, i'll run with this
[16:50] <kirkland> pitti: until someone else slams me for that approach :-D
[16:51] <pitti> kirkland: so in summary, it needs an extension to the apt cronjob to cache the package updates, and then just another profile.d/ script? perfect
[16:51] <pitti> kirkland: I'll come to your defense then :)
[16:51] <kirkland> pitti: i think the apt cronjob already does that?
[16:51] <kirkland> pitti: i thought i worked with mvo on that in Jaunty, for screen-profiles and byobu?
[16:51] <kirkland> pitti: my "requirement" was that /var/run/updates-available be "as current as the last apt run"
[16:52] <pitti> mmmm retroactive features :)
[16:52] <kirkland> pitti: where either that was the cronjob apt
[16:52] <pitti> kirkland: /var/run wouldn't work so well for this, though
[16:52] <pitti> it should be in /var/cache
[16:52] <kirkland> pitti: or your last apt-get update manually
[16:52] <pitti> since /var/run is cleaned on boot
[16:52] <pitti> I don't have that file there
[16:52] <pitti> since I rebooted two hours ago
[16:52] <kirkland> pitti: ah
[16:52] <pitti> but in /var/cache it should be perfect
[16:53] <kirkland> pitti: cool, i'll get with mvo on this one
[16:53]  * pitti ^5s kirkland, thanks so much
[16:53] <kirkland> pitti: okay, thanks
[17:06] <superm1> pitti, it appears the updated udev rule in devkit disks you uploaded fixes utility partitions properly
[17:07] <superm1> I adapted the rule for what factory shipped linux systems should look like.  by specifying the partition number I don't suspect it should clash with windows factory shipped systems.  do you think this should go upstream too, http://pastebin.com/f17bffd6c ?
[17:10] <mvo> kirkland: I changed the code in u-n to use /var/lib/update-notifier/updates-available now
[17:18] <lool> Keybuk: hola
[17:18] <Keybuk> lool: what's up?
[17:18] <lool> Keybuk: libnih seems to cause upstart to timeout on ARM
[17:18] <lool> Keybuk: the test_node.c file seems too big
[17:18] <lool> Keybuk: I couldn't decide whether it's generated
[17:18] <Keybuk> it's not generated
[17:18] <lool> It's 16k lines
[17:18] <lool> Keybuk: Could we split it?
[17:18] <Keybuk> ogra filed a bug report, it caused gcc to crash for him
[17:18] <Keybuk> no
[17:18] <Keybuk> besides, there are bigger files
[17:18] <Keybuk> there's a ~50,000 line file not long after
[17:18] <ogra> Keybuk, yes, but thats apparently a HW issue on my side
[17:19] <lool> Keybuk: Indeed; that's worrying
[17:19] <Keybuk> why would it take >2.5hrs to compile that file?
[17:19] <lool> Keybuk: Is this something new?
[17:19] <ogra> its either ld's fault of the system running out of ram
[17:19] <NCommander> Keybuk, if its paging out, it might cause the issue. I've seen that when trying to build KDE on the NSLU2
[17:19] <Keybuk> lool: "new" ?
[17:19] <lool> Keybuk: Did you recently introduced large files?
[17:19] <ogra> lool, the whole 0.6 upstart is *new* :)
[17:19] <Keybuk> NCommander: well, we know that the current I/O scheduler is fucked and can permanently defer forever things using too much I/O :)
[17:19] <ogra> we had 0.3 until now
[17:20] <lool> It only took 10 minutes in jaunty
[17:20] <Keybuk> lool: right, as ogra said; 0.6 is basically a rewrite
[17:20] <NCommander> Keybuk, we've had issues w/ that before with libipc-sharelite-perl
[17:20] <lool> Keybuk: Did < 0.6 have large source files as well?
[17:20] <lool> Keybuk: I'm trying to decide whether it's a regression the toolchain
[17:20] <Keybuk> lool: some relatively large source files in the test suite, yes
[17:20] <lool> jaunty's upstart built relatively fast: Build needed 00:10:48, 22740k disk space
[17:20] <Keybuk> jaunty's upstart had fewer tests
[17:20] <lool> It didn't have test_node.c though
[17:20] <ogra> you cant compare them
[17:21] <Keybuk> lool: it didn't link to libdbus either
[17:21]  * NCommander wonders how much swap the buildds have ...
[17:23] <NCommander> rimu has a little under 1.5GB worth of swap; I think the buildds are setup the same ...
[17:24] <lool> Keybuk: Couldn't we split at least the test_path_valid/test_new/test_start_tag etc. into separate files?
[17:24] <Keybuk> lool: no, the test suite doesn't work that way
[17:24] <lool> test_proxy_functions is the huge function; 10k lines
[17:25] <lool> Keybuk: What do you suggest?
[17:25] <Keybuk> lool: fix gcc
[17:26] <Keybuk> hell, I thought we had commercial engagements with the maintainers of the gcc ARM port for precisely this reason
[17:30] <superm1> Keybuk, ping.  I missed you last week, so I'll retry: I'm having a hard time figuring out something going on with a udev rule.  [ACTION=="add", SUBSYSTEM=="bluetooth", RUN+="/usr/sbin/bluetoothd --udev"] is the rule.  it works fine if the device is hotplugged, but not if the system boots up with the device plugged in.  Any ideas?
[17:32] <Keybuk> superm1: /usr not mounted when the system is booted?
[17:32] <superm1> Keybuk, so shouldn't udev be retrying any failed rules then?
[17:32] <superm1> but that sounds like a sensible reasoning
[17:32] <Keybuk> superm1: no, it doesn't
[17:33] <superm1> is there any way to specify in said rule then to defer running it until /usr gets mounted?
[17:38] <Keybuk> superm1: no
[17:38] <Keybuk> superm1: indeed, such things are deliberately not permitted
[17:38] <Keybuk> bluetoothd should probably be in / anyway?
[17:39] <superm1> Keybuk, oh well when you were saying /usr I was thinking you meant / (and /usr being on /). It is in /
[17:40] <Keybuk> dunno then
[17:40] <Keybuk> what does your logs say?
[17:42] <superm1> well I'm having a hard time figuring out how to get verbose logs from during boot. the init script makes it look like they should be ending up /dev/.udev/, but I'm not seeing logs there
[17:43] <superm1> /var/log/udev definitely does show an add event for a device on the bluetooth subsystem
[17:48] <Sarvatt> it isnt loading v4l devices at boot for me and a bunch of people too (no webcams)
[18:00] <Keybuk> superm1: right, I'm betting /usr/sbin/bluetoothd is failing in some strange way
[18:00] <Keybuk> ie. that it's not a udev bug
[18:00] <Keybuk> probably tries to write to the filesystem or something
[18:03] <superm1> well they've got it working in fedora devel with this udev rule, so I was leaning towards some type of integration problem here. i'll try'n switch it out with a daemon that I know should work then
[18:03] <Keybuk> run a shell script around it and capture the output?
[18:04] <pitti> superm1: cool, thanks
[18:04] <superm1> can't write to the filesystem that early though can you?
[18:04] <cjwatson> use /dev/
[18:04] <pitti> superm1: hm, "OS" seems prone to false positives
[18:05] <cjwatson> /dev/.initramfs/ for example
[18:05] <pitti> superm1: in that generality I think it'd be better to do as an OEM rule
[18:05] <superm1> pitti, okay will keep it that way then thanks
[18:11] <pitti> superm1: no chance to slam a "special" partition type to it?
[18:11] <superm1> pitti, it unfortunately really is a vfat partition
[18:11] <pitti> superm1: like 27?
[18:11] <pitti> superm1: sure, but vfat is the file system
[18:12] <superm1> dellutility really is a special type that has other data embedded in it
[18:12] <pitti> superm1: it could still be partition type 27, as opposed to 06 or 0b
[18:12] <pitti> okay
[18:24] <Ng> am I the only person seeing ubuntu-bug cause ff35 to crash in karmic? it looks to be spinning up a new instance of ff which immediately crashes :/
[18:24] <Ng> I've asked a couple of other karmic users and they are able to file bugs fine with ubuntu-bug and ff35
[18:34] <Caesar> Wee
[18:34]  * Caesar just read #389322
[18:35] <Caesar> pitti: what's your preferred way forward for bug 389322 on Hardy?
[18:35] <ScottK> Caesar: IIRC there's a fixed package in hardy-proposed.
[18:36] <pitti> Caesar: hm, someone backporting the fix and sending it to the bug? :-)
[18:36] <pitti> ScottK: only in jaunty-updates
[18:36] <ScottK> Ah.  Misemembered.
[18:36] <ScottK> ..r..
[18:36] <Caesar> pitti: so you're cool with a honking great big debdiff?
[18:37] <pitti> Caesar: whatever works; jaunty-proposed debdiff was huge, too
[18:38] <Caesar> Yeah, so I saw
[18:38] <pitti> but if it only touches the yahoo protocol, it can hardly get any worse
[18:38] <Laney> if you can succeed where I failed, please go ahead
[18:38] <Caesar> Okay, I'll see about cooking up a debdiff
[18:38] <Laney> Caesar: I'll send you what I got if you like
[18:38] <pitti> Caesar: gret, thanks!
[18:38] <Laney> I just couldn't get it to work
[18:38] <Caesar> Laney: sure
[18:38] <Caesar> I think we have some Pidgin developers on staff
[18:38] <Caesar> So they might be able to help
[18:39] <Laney> oh
[18:39] <Laney> I think I deleted it ¬_¬
[18:39] <Caesar> Laney: no biggie
[18:40] <Laney> the simple backport didn't work anyway, kept throwing nss problems
[18:40] <Caesar> Yay
[18:41] <Laney> but good luck
[19:43] <jsteel> Hi. I'm trying to build a custom kernel with a patch to support the latest winbond watchdog. I run `fakeroot make-kpkg --initrd --append-to-version=-custom kernel_image kernel_headers` and everything works great except the /lib comes out to be 1.1GB. Compare that to the 100-200MB that the server image creates in lib. Does anybody know how to make my image smaller? Whats the magical incantation to make?
[20:12] <BUGabundo> pitti: around? https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/389686
[20:13] <BUGabundo> oops
[20:13] <BUGabundo> wrong link ehe
[20:13] <BUGabundo> pitti: https://bugs.launchpad.net/ubuntu/+source/gui-ufw/+bug/398945
[20:35] <radix> so, uh, has anyone else received (private) responses to u-d-d posts from a guy named "Kevin Croissant" containing a link to a javascript hack which DoSes firefox while displaying extremely disturbing images?
[20:52] <maco> radix, i have not, but thank you for the warning
[21:57] <kirkland> seb128: around?
[21:57] <seb128> kirkland, yes
[21:57] <kirkland> seb128: hi, update-notifier question for you
[21:58] <BUGabundo> hey kirkland
[21:58] <kirkland> seb128: http://pastebin.ubuntu.com/217283/
[21:58] <seb128> kirkland, update-notifier is mvo's but sure if I can reply
[21:59] <kirkland> seb128: ah, right, i saw your name in the changelog recently, and mvo is not around ;-)
[21:59] <kirkland> BUGabundo: hang on a second
[21:59] <kirkland> seb128: i was about to commit that change to bzr
[21:59] <kirkland> seb128: i'd like to upload too, but i see that 0.86 is not yet uploaded to karmic
[21:59] <kirkland> seb128: so i was nervous about pushing
[22:00] <BUGabundo> kirkland: don't bother. just waving o/
[22:00] <kirkland> ah, hello
[22:01] <seb128> kirkland, better to ping mvo about it tomorrow or drop him an email
[22:01] <kirkland> seb128: okay, thanks
[22:01] <seb128> kirkland, looking at the source update-mot.d doesn't seem used at all by update-notifier
[22:02] <kirkland> seb128: i thought you guys might be off for Bastille day tomorrow
[22:02] <kirkland> seb128: yes, it should be
[22:02] <kirkland> seb128: in the links
[22:02] <seb128> kirkland, I am, german guys and mvo are not ;-)
[22:02] <majikman> are there plans to modify tomcat so that it doesn't log to syslog?
[22:02] <kirkland> seb128: doh!  sorry
[22:02] <seb128> kirkland, nothing to be sorry about ;-) you will probably get a reply from mvo tomorrow
[22:03] <kirkland> seb128: cool, thanks.
[22:19] <davmor2> guys due to kms and intel the text for ejecting cd press enter to continue is tiny.  Is this a set font size?
[22:23] <BUGabundo> seb128: still here? did something change on gnome for karmic, not allowing apples to be dragged with mouse middle click?
[22:25] <seb128> BUGabundo, there is new tarballs every 3 weeks for GNOME I expect that something changed yes, we would not bother doing 60 uploads of nothing
[22:26] <seb128> BUGabundo, I just moved the clock and the wcnk applet there, works correctly
[22:26] <seb128> the menus too
[22:26] <BUGabundo> seb128: not for me! let me find some one else
[22:26] <seb128> did you lock those applets?
[22:27] <sebner> seb128: don't forget to re-enable gnome tetris as clutter 0.9.x is now in karmic :P
[22:27] <BUGabundo> seb128: yes they are unlocked
[22:28] <seb128> sebner, ah ah, it's far to be on the CD though
[22:29] <sebner> heh
[22:35] <NCommander> pitti, ping, has there been any issues w/ the apport-retracer on karmic recently?
[22:35] <chrisccoulson> seb128 - this g-c-c update is a pain ;)
[22:35] <BUGabundo> seb128: seems I can't confirme it on another system... but it does happen on this one :(
[22:35] <chrisccoulson> it doesn't build without libgnomekbd from git
[22:36] <seb128> chrisccoulson, I'm sure you can win over it ;-)
[22:36] <chrisccoulson> most probably. i might not get it finished tonight though ;)
[22:36] <seb128> NCommander, what sort of issue?
[22:37] <chrisccoulson> shall we wait for a libgnomekbd tarball or do you want me to package it from git?
[22:37] <NCommander> seb128, Can't exec "/tmp/libssl0.9.8.config.87075": Exec format error at /usr/share/perl/5.10/IPC/Open3.pm line 168. and issues with update-alternatives
[22:37] <NCommander> seb128, same issue popped up on both powerpc and armel, so I'm kinda curious to figure out what's going on
[22:38] <seb128> NCommander, well the retracers only use apport-retrace which meanwhile use a chroot
[22:38] <BUGabundo> seb128: I got this on identica: "jacob: @bugabundo Working only on icons and the notification area. Everything else is stuck, even though unlocked. "
[22:38] <seb128> not sure about that issue
[22:39] <NCommander> seb128, I think its a bad interaction between fakechroot, the auto-update, and karmic
[22:39] <seb128> could be
[22:39] <seb128> needs debugging I guess
[22:39] <NCommander> I was hoping the same issue would pop up on i386/amd64, but that doesn't seem to be the case
[22:41] <seb128> chrisccoulson, I've no strong opinion, patch backport, git snapshot
[22:41] <seb128> chrisccoulson, I can try pinging upstream when he's around but that's not the case right now
[22:41] <chrisccoulson> seb128 - no problem. i'll put the g-c-c update to one side for now and work on the gnome-session one
[22:41] <seb128> ok
[22:43] <BUGabundo> seb128: another user just confirmed it again. should I open a bug and upstream it ?
[22:44] <directhex> TheMuso, gabaug's got a11y working in banshee's infamous listview :)
[22:44] <seb128> no
[22:44] <BUGabundo> seb128: ok
[22:44] <seb128> BUGabundo, on what applets do you get the issue?
[22:44] <BUGabundo> most of them to me
[22:44] <BUGabundo> but the some do work
[22:44] <seb128> names!?
[22:44] <BUGabundo> gnome-monitor, netspeed, diskmounter
[22:45] <seb128> some standard ones?
[22:45] <BUGabundo> doesn't are among thes ones don't work
[22:45] <seb128> ie menus, mixer, wnck, clock, weather, etc?
[22:45] <BUGabundo> time, menu, work
[22:45] <BUGabundo> funny.... bright doesn't ,but xkills does work
[22:46] <seb128> open a gnome-panel bug if you want, upstream would be better if you can open it there too
[22:47] <BUGabundo> I can
[22:47] <BUGabundo> I will
[22:47] <seb128> thanks
[22:59] <BUGabundo> seb128: should I file upstream on 2.27 snapshot or 2.26, cause gnome-panel is still 2.26.3?
[22:59] <BUGabundo> https://bugs.edge.launchpad.net/ubuntu/+source/gnome-panel/+bug/399031
[23:00] <seb128> BUGabundo, there is no 2.27 so 2.26
[23:00] <BUGabundo> gnome-media:  Installed: 2.27.3.1-0ubuntu1
[23:02] <BUGabundo> seb128: and I see it on the dropdown list on bugzilla.g.o
[23:02] <seb128> BUGabundo, gnome-media for applets?
[23:02] <BUGabundo> even my about says so Version: 2.27.3
[23:02] <BUGabundo> seb128: no... for gnome
[23:02] <seb128> BUGabundo, you want gnome-panel
[23:02] <BUGabundo> ok
[23:02] <seb128> well gnome-media has 2.27 tarballs
[23:02] <seb128> gnome-panel doesn't
[23:04] <BUGabundo> seb128: upstream http://bugzilla.gnome.org/show_bug.cgi?id=588488
[23:04] <seb128> BUGabundo, thanks
[23:07] <BUGabundo> seb128: np
[23:26] <TheMuso> directhex: Great. I am not a banshee user.
[23:27] <TheMuso> directhex: But good news nonetheless.
[23:28] <directhex> TheMuso, well, yes. banshee's had a11y problems for years
[23:28] <directhex> which doesn't cause *me* issues, but i hear some folks without perfect vision like to use computers...
[23:30] <maco> also, nose prints on the screen aren't so fun :P
[23:37] <ion> maco: I officially have a nose print on my screen. I had to test whether the touchscreen can be controlled with a nose. :-P
[23:38] <maco> haha...i was referring to my tendency over time to get closer and closer to my screen. if i dont stop and notice that i'm only 2 inches away...im sure one day i'll smack right into it
[23:41] <slangasek> pitti: where did hal's Recommends: smartdimmer go?  component-mismatches wants to demote smartdimmer now
[23:42] <ajmitch> slangasek: a MIR needs to be filled out for any package recommended by something in main, right?
[23:42] <slangasek> ajmitch: yes
[23:43] <ajmitch> thanks, I think I'll change it to suggests for a bit instead