[06:38] <pitti> Good morning
[08:51] <dkessel> good morning pitti :)
[08:51] <pitti> hey dkessel, wie gehts?
[08:53] <dkessel> pitti: gut, danke :) ich hoffe dir auch
[08:53] <pitti> dkessel: danke, geht so; noch ein bisschen jetlag
[08:55] <dkessel> pitti: hab dich mit der einhorn-maske auf dem kopf gar nicht erkannt :)
[08:59] <pitti> haha
[10:44] <pitti> elfy: was https://bugs.launchpad.net/ubuntu/+source/xfce4-weather-plugin/+bug/1377612/comments/21 testing the package from -proposed? that's not quite clear
[11:08] <brainwash> can anyone please take a look at bug 1365965 ? a package needs to be created from the debdiff and then uploaded to -proposed
[11:30] <bluesabre> brainwash: a package was already created and uploaded, only needs to be accepted into -proposed
[11:31] <brainwash> where can I see this info?
[11:31] <bluesabre> https://wiki.ubuntu.com/StableReleaseUpdates
[11:31] <bluesabre> The status is set to "In Progress"
[11:31] <bluesabre> you can also ask me, since I handle nearly all of the xubuntu uploads
[11:32] <pitti> https://launchpad.net/ubuntu/trusty/+queue?queue_state=1 FTR
[11:32] <pitti> (change release as appropriate)
[11:32] <bluesabre> and that
[11:32] <bluesabre> :)
[11:33] <bluesabre> in a rush to get out the door and to work, bbl
[11:33] <brainwash> oh, so you've uploaded it.. which makes sense after thinking about it
[12:42] <elfy> pitti: ack - from -proposed - worked fine


[06:09] <brobostigon> morning
[09:52] <daftykins> morn \o
[10:00] <brobostigon> morning
[10:08] <zxmoypi> o/
[11:40] <brobostigon> \o
[11:57] <daftykins> i have a meeting with the boss man at the small business i have been checking out recently, the one with the worst security i've ever seen and an entire office of EOL products on an EOL server
[12:01] <MattJ> \o/
[12:03] <daftykins> he might be a dangerous client as he seems to be the reason for why everything is so bad there, i don't think he believes in updates and thinks IT people do it to justify their jobs
[12:04] <daftykins> they run in-house email on MS Exchange, next month when the next Firefox and possibly Chrome releases are out, TLS v1.0 is being disabled by default, which their outlook web access relies on :D
[12:08] <zxmoypi> yeah, sounds like they'll be a bugger to get paid from
[12:09] <daftykins> well i got paid for what i did already :D justifying work to perform necessary updates, however...
[12:17] <daftykins> i think i'll discuss the process only in general terms so as not to give any answers away ;)
[12:21] <zxmoypi> it tech level 2:switch it off and throw it out :-P
[12:21] <daftykins> \o/
[12:21] <daftykins> nah, tonnes of services to migrate off to start
[12:22] <daftykins> makes me laugh so much that someone installed the backup software for backing up their server VM... inside the VM
[12:22] <daftykins> just... so many levels of failure
[12:23] <zxmoypi> i always put the backup not on the server. that way if server was destroyed you could turn the backup computer into a temp server at a pinch
[12:24] <zxmoypi> what could possibly happen to a server they'd say... under 2 foot of water, had a wall collapse on it, lightning strike...
[12:24] <daftykins> he told me the other day that he has an exact duplicate of the £4k HP server at home... made me wonder why he asked for new disks instead of grabbing one from that when the RAID was degraded and they were in danger
[12:25] <zxmoypi> but then he wouldn't have a backup
[12:27] <daftykins> but you could be safer waiting to a replace a disk that isn't live... and it isn't one - as the server is a VM atop the host the actual system doesn't even matter
[12:33] <daftykins> penguin42: morn
[13:18] <Chunkyz> Lmao


[00:17] <ScottK-laptop> Riddell: I'd appreciate it if you could accept kicker-taskbar-compiz in hardy-backports ...
[00:46] <Riddell> ScottK-laptop: accepted
[00:46] <Riddell> I think I've tracked down the no maximise button issue
[00:47] <Riddell> apachelogger: "Add kickoffrc as replacement for the favourites patch in workspace" have you tested that?
[00:47] <Riddell> it didn't work when I tried it
[00:48] <Riddell> (nor when suse tried it I presume by the existance of a kickoffrc)
[00:49] <apachelogger> Riddell: http://aplg.kollide.net/images/osiris/snapshot147.png
[00:50] <ScottK-laptop> Riddell: Thanks.
[00:50] <apachelogger> Riddell: worth testing, I had a lot of package revisions that day, that's also the reason I didn't drop the workspace patch yet.
[00:52] <Riddell> extra adept
[01:00] <seele> apachelogger: that's a nice logo for adept.. did the oxygen people make it or did it already exist?
[01:01] <apachelogger> seele: oxygen, but I don't like it for the installer
[01:01] <apachelogger> especially not considering the updater uses the same icon
[01:01] <seele> oh, that could be confusing
[01:02] <Riddell> the updater is adept
[01:02] <seele> hum.. should make some tea
[01:03] <Riddell> ooh, are you calling your evening meal "tea" now?
[01:04] <seele> Riddell: no.. i'm calling steeping some leaves in hot water tea :)
[01:05] <seele> although i'm getting hungry already even though dinner was only 2 hours ago.  might have to make a snack to go with it
[01:05] <seele> Riddell: besides.. i thought your "tea" was an early dinner, not late?
[01:07] <Riddell> around 6-ish, plus or minus an hour
[01:07] <Riddell> but as usual, us computer types tend to be later :)
[01:07] <seele> it's tought eating a meal and staying up for an additional 6 hours without anything for the rest of the evening
[01:08] <seele> especially when i tend to eat every few hours during the day
[03:23] <ScottK-laptop> Are we close to having our beta packages in place then?
[03:24]  * ScottK-laptop contemplates a dist-upgrade of the laptop.
[03:44] <rgreening> hey
[03:44] <rgreening> ScottK-laptop: I'm running latest intrepid now. no issues.
[03:45] <ScottK-laptop> I'd like to do my upgrade when we're pretty close to what we plan to use for beta so I can catch any upgrade issues.
[03:45] <ScottK-laptop> Do you know if anything else is planned?
[03:47] <rgreening> not that I've heard. I built an update to qt 4.4.3, but I think Riddell wants to wait until after beta to up it
[03:48] <nixternal> wasabi peeps!!!
[03:49]  * ScottK says what the heck and upgrades.
[03:49] <rgreening> 'lo
[03:49]  * nixternal says what the heck and doesn't upgrade :)
[03:49]  * rgreening smiles
[03:49] <nixternal> is Intrepid lookin' good yet?
[03:50] <nixternal> I have been using wmii lately and haven't been checking in on things...that is going to change in the next couple of months though...I am coming back, but to do more coding than anything else
[03:50] <nixternal> need to find new documentors!!!
[06:48]  * ScottK-laptop really hopes that was not a typical upgrade experience.
[12:14] <Riddell> all new alternate CDs up
[12:56] <Tonio_> Riddell: I'm currently working on policykit-kde, I can get a dialog when required, but it seems to ask for the root password by default
[12:56] <Tonio_> Riddell: I'm pretty sure there is a way to make it to work, maybe patch somehow.... I'm investigating
[12:57] <Tonio_> Riddell: appart from that I'm really surprized with packagekit, it works really nicelly
[13:18] <Riddell> desktop CDs up
[13:18] <Riddell> Tonio_: formidable
[13:22] <apachelogger> hm
[13:22] <apachelogger> vorian: bug 267182
[13:31] <Tonio_> Riddell: the problem seems to be that policykit reports bad permissions, problably due to bad request...
[13:31] <Tonio_> Riddell: POLKIT_RESULT_ONLY_VIA_ADMIN_AUTH_KEEP_ALWAYS is reported when my standard user has the permission.... certainly a problem with the UID or something
[13:31] <Tonio_> Riddell: shouldn't be that hard to fix :) still in the work
[13:35] <vorian> apachelogger: do we have time for fixor it?
[13:35] <apachelogger> vorian: dunno, do you?
[13:35] <apachelogger> maybe devfil does?
[13:35] <vorian> i guess
[13:35] <vorian> i just woke up
[13:36] <devfil> what?
[13:36] <apachelogger> bug 267182
[13:37] <devfil> apachelogger: ok, np
[13:37] <jtechidna> good morning all
[13:38] <apachelogger> hoy jtechidna
[13:38] <vorian> 09/30/08|08:42 < vorian> i guess
[13:38] <vorian> fuck
[13:38] <jtechidna> ha
[13:39] <jtechidna> Riddell: didja receive my adept patch?
[13:39]  * apachelogger pokes Riddell with bug 275997
[13:40] <apachelogger> Riddell: please remove the kwinrulesrc from kds
[13:42] <apachelogger> jtechidna: what is bug 217654 about?
[13:42]  * apachelogger doesn't really get the problem
[13:43] <jtechidna> apachelogger: empty Path= in the .desktops
[13:43] <apachelogger> hm
[13:43] <apachelogger> is that actually invalid?
[13:44] <apachelogger> oh 1.1 published
[13:44] <jtechidna> I probably should have checked that before opening a shitton of bugs
[13:44] <apachelogger> neato
[13:44] <apachelogger> jtechidna: yus
[13:45] <jtechidna> so, freedesktop.org?
[13:48] <apachelogger> jtechidna: http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-1.1.html
[13:48] <apachelogger> I think we should poke them
[13:49] <apachelogger> -(~/src/deb/mysql:$)-> desktop-file-validate /usr/share/applications/kde4/kate.desktop
[13:49] <apachelogger> /usr/share/applications/kde4/kate.desktop: warning: key "InitialPreference" in group "Desktop Entry" is a reserved key for KDE
[13:49] <apachelogger> /usr/share/applications/kde4/kate.desktop: warning: value "" for key "Path" in group "Desktop Entry" does not look like an absolute path
[13:49] <apachelogger> warning, not error
[13:49] <apachelogger> Path is type string
[13:49] <apachelogger> and the spec says
[13:49] <apachelogger> "-(~/src/deb/mysql:$)-> desktop-file-validate /usr/share/applications/kde4/kate.desktop
[13:49] <apachelogger> /usr/share/applications/kde4/kate.desktop: warning: key "InitialPreference" in group "Desktop Entry" is a reserved key for KDE
[13:49] <apachelogger> /usr/share/applications/kde4/kate.desktop: warning: value "" for key "Path" in group "Desktop Entry" does not look like an absolute path
[13:49] <apachelogger> actually it says "Values of type string may contain all ASCII characters except for control characters." :P
[13:49] <jtechidna> poke whom?
[13:50] <apachelogger> now that could be "values of type string must contain any ASCCI chracters except for control chracters"
[13:50] <apachelogger> but it is not
[13:50] <apachelogger> like "Values of type numeric must be a valid floating point number as recognized by the %f specifier for scanf in the C locale."
[13:51] <apachelogger> jtechidna: I'd suggest poking<EMAIL_ADDRESS>[13:52] <apachelogger> but I interpret the spec that you don't necessarily need to have any value for string keys
[13:53] <apachelogger> jtechidna: you could file a bug report at https://bugs.freedesktop.org/
[13:53] <apachelogger> stating the problem and that the spec doesn't clearly state what happens if a key with value string is empty
[13:55] <Tonio_> Riddell: hum, policykit-kde seems to work well in fact
[13:56] <Tonio_> Riddell: unless I'm wrong, I don't understand how the gnome one works
[13:56] <Tonio_> Riddell: packagekit by default only let the admin user install a package
[13:56] <Tonio_> which means root I guess
[13:56] <Tonio_> Riddell: any idea how packagekit detects what is admin and what is not ?
[13:56] <Tonio_> Riddell: this i the default authorization : POLKIT_RESULT_ONLY_VIA_ADMIN_AUTH_KEEP_ALWAYS:
[13:57] <Tonio_> Riddell: according to packagekit-kde, that means root auth is required, which'll fail since root has no password
[13:57] <Tonio_> Riddell: policykit gnome then asks for the user's password, which sounds wrong, but works...
[13:58] <Tonio_> Riddell: technically policykit-kde works, just I think we have to make it clear what is 'admin' according to policykit
[13:59] <Tonio_> Riddell: who may know a bit of policykit on the gnome side ?
[14:22] <Riddell> Tonio_: pitti's name comes to mind for policykit
[14:32] <ScottK-laptop> In KDE3 if you mouse over an item for an open app in Task Manager you get a tooltip with what the app is.  In Intrepid KDE4 I don't get the tooltip.  Bug? Feature? Some setting I need to change?
[14:34] <rgreening> Riddell: updating qt 3.3.9 shortly. Assuming you still need it done
[14:47] <rgreening> Riddell: can't find a 3.3.9 release... was there one for the copyright update? not sure there was
[14:48] <rgreening> anyone having an issue with update-notifier-kde not running on startup or failing shortly after startup?
[15:01] <jtechidna> ScottK-laptop: Was present in 4.0, but broke and never got fixed because of something Qt-ish in the 4.1 cycle
[15:01] <jtechidna> The feature is already back in 4.2 trunk
[15:02] <ScottK-laptop> jtechidna: Is there any way we can backport a patch to 4.1 to fix it?  It a regression from KDE3 at this point and a rather huge one for my typical workflow.
[15:04] <jtechidna> ScottK-laptop: Dunno, since I think it was a Qt issue it might rely on Qt-copy. I'm not sure though.
[15:04] <ScottK-laptop> Riddell: Do you know about this?  Can we fix it for Intrepid?  ^^^
[15:06] <jtechidna> We could probably ask #plasma or the plasma-devel ML how extensive the changes would be for a backport
[15:06] <ScottK-laptop> Would you?  I think it'll be a big deal for a lot of people.
[15:07] <rgreening> How hard would it be to port synaptic to Qt? I rather like synaptic as compared to adept 3
[15:08] <apachelogger> there once was kynaptic
[15:08] <apachelogger> it was crap
[15:08] <jtechidna> ScottK-laptop: I'll get on it in a bit, I haz economics hw to finish up first
[15:08] <apachelogger> and I don't like syntpic either
[15:08] <apachelogger> then again I don't like adept very much
[15:08]  * apachelogger finds all package manager guis rather awful
[15:08] <ScottK-laptop> jtechidna: Thanks.
[15:09] <jtechidna> If we're lucky suse might even have something we can steal, \o/
[15:10]  * apachelogger finds suse patches overly dangerous
[15:11] <apachelogger> Riddell: please accept kgrubeditor
[15:11] <rgreening> anyone package wine yet?
[15:12] <ScottK-laptop> If by WINE, you actually mean WINE then yes.  If you mean a winecfg replacement, I don't think so.  yuriy had some thoughts on that a while ago.
[15:12] <rgreening> was talking about wine 1.1.5
[15:13] <jtechidna> last stable was 1.0, which is what they're sticking with for Intrepid iirc
[15:13] <ScottK-laptop> Talk to yokozar on #ubuntu-motu about it.
[15:14] <rgreening> ok.
[15:14] <jtechidna> there is a 3rd party ubuntu repo that gets the 1.1.x updates
[15:14] <gnomefreak> is kde3 avail. in intrepid?
[15:14] <ScottK-laptop> Which yokozar is the also the guy that runs it.
[15:14] <rgreening> gnomefreak: no
[15:14] <ScottK-laptop> gnomefreak: Not as a complete desktop.  Some pieces are.
[15:14] <gnomefreak> thanks thats what i thought
[15:14]  * jtechidna disappears for 15 min
[15:18]  * apachelogger pokes claydoh
[15:18] <nixternal> mornin' krazy people
[15:19] <apachelogger> "I agree that this is a very important bug to fix. Kubuntu has an image problem as it is and something like this making it through would only make things worse."
[15:19] <apachelogger> oh
[15:19] <apachelogger> seriously!
[15:19] <claydoh> apachelogger: what did I do this time ;)]
[15:19] <apachelogger> claydoh: bug 275218
[15:19] <apachelogger> do you use imap?
[15:19] <claydoh> nope
[15:19] <apachelogger> do you get a backtrace?
[15:19] <apachelogger> if not, run kdebugdialog
[15:19] <apachelogger> turn all debug on
[15:19] <claydoh> kk
[15:19] <apachelogger> start kmail from console and trigger the issue, get the output pasted
[15:34] <Riddell> ScottK-laptop: I don't know anything about task manager tooltips I'm afraid
[15:35] <ScottK-laptop> OK.  Thanks.  Maybe jtechidna will turn something up.
[15:36] <Riddell> rgreening: hmm, you're right, there is no 3.3.9, I was told there would be
[15:36] <rgreening> kool. thought I was losing it
[15:36] <rgreening> :P
[15:39] <Riddell> rgreening: well, beta candidate CDs need testing if that leaves you at a lose end :)
[15:39] <rgreening> I may just do that. I was thinking on how best to test.
[15:40] <rgreening> didn't want to lose all my settings in Intrepid.. may have to backup (or is there a vm way to do it?)
[15:40] <claydoh> apachelogger: I just get a freezeup http://paste.ubuntu.com/52482/
[15:40] <apachelogger> getdents64(37, /* 10 entries */, 4096)  = 312
[15:40] <apachelogger> close(37)                               = 0
[15:40] <apachelogger> access("/usr/share/myspell/dicts/en-GB.aff", F_OK) = -1 ENOENT (No such file or directory)
[15:40] <apachelogger> nice and cosy
[15:41] <apachelogger> uh yeah, it's broken
[15:41] <apachelogger> \o/
[15:41] <Riddell> rgreening: you can try virtualbox, dunno how well that works
[15:41]  * apachelogger thinks a missing dict shouldn't take kmail down
[15:42] <apachelogger> Riddell, rgreening: works pretty well
[15:42] <Riddell> rgreening: also you should be able to install to an existing partition, it'll wipe /usr etc but should keep /home
[15:42] <davmor2> Riddell: new version supports 64bit and works quite well according to heno :)
[15:42] <rgreening> true.. could try that
[15:42] <claydoh> apachelogger: so can I install a different one ?
[15:43] <claydoh> who needs en-gb, us yanks have our own eh?
[15:43] <apachelogger> well
[15:43] <apachelogger> the thing is kmail shouldn't be using en-gb
[15:43] <apachelogger> kmail shouldn't even have it's own spell check setting
[15:43] <claydoh> true
[15:44] <Riddell> rgreening: just make sure not to tick the format box if installing over an existing partition
[15:44] <apachelogger> hm
[15:45] <rgreening> Riddell: kk
[15:45] <apachelogger> claydoh, rgreening: please paste ls -lah /usr/share/myspell/dicts/
[15:46] <rgreening> apachelogger: http://paste.ubuntu.com/52485/
[15:46] <apachelogger> Oo
[15:46] <claydoh> http://paste.ubuntu.com/52486/
[15:47] <apachelogger> claydoh: -rw-r--r-- 1 root root  28K 2008-09-16 10:36 en_GB.aff
[15:47] <apachelogger> shouldn't be crashing for you
[15:47]  * apachelogger doesn't have this file at all
[15:47] <apachelogger> claydoh: run `strace kmail --nofork` and trigger the crash
[15:47] <apachelogger> paste the last couple of lines
[15:47] <ScottK-laptop> Riddell: I'm looking at the Intrepid uninstallables and it appears to me that kdeedu is to demote libkiten4 and libkiten-dev to Universe.
[15:48] <apachelogger> claydoh: ah forget about that
[15:48] <apachelogger> rgreening: can you reproduce the hang?
[15:48] <claydoh> ok
[15:48] <apachelogger> bug 275218
[15:48] <apachelogger> technically it should be working for rgreening
[15:48] <rgreening> lm check
[15:49] <rgreening> nope. Kmail is solid for me
[15:49] <Riddell> ScottK-laptop: I don't follow
[15:51] <apachelogger> claydoh: try sudo apt-get install --reinstall myspell-en-us myspell-en-gb
[15:51] <ScottK-laptop> Riddell: Maybe it was done already, but it's showing up on http://people.ubuntu.com/~ubuntu-archive/testing/intrepid_probs.html as uninstallable.  When I tested it installs with Universe enabled and not if Main.  It's only rdepend is in Universe.
[15:53] <claydoh> apachelogger: it removes hunspell-en-us
[15:53] <apachelogger> um
[15:53] <apachelogger> claydoh: replace myspell-en-us with hunspell-en-us
[15:54] <claydoh> but it works installing myspell-en-us and -en-gb :)
[15:54] <apachelogger> ok
[15:54] <claydoh> I can email
[15:54] <Riddell> ScottK-laptop: mm, right
[15:54] <apachelogger> this is no kmail bug
[15:54] <apachelogger> or actually it is but it is not at the same time
[15:55] <claydoh> is hunspell the default one to use?
[15:55] <rgreening> I have all 3 packages installed on my system. Not sure which apps brought them in. Do we need a dep update for Kmail and one of the spell packages
[15:56] <apachelogger> claydoh: no idea, mysql-en-gb is default and huspell-en-us is as well
[15:56] <apachelogger> too mysterious
[15:56] <apachelogger> rgreening: no
[15:56] <apachelogger> the problem is that for some reason the package don't get installed properly
[15:56] <apachelogger> maybe only upon upgrad even
[15:57] <apachelogger> that's the reason your ls is different from claydoh's
[15:57] <rgreening> claydoh, do you have language-support-writing-en installed?
[15:57] <rgreening> ok
[15:57] <rgreening> so, I need to really test on a clean install to dup
[15:58] <claydoh> apachelogger: no
[15:59] <rgreening> claydoh: was that in response to my Q? regarding language support?
[15:59] <Riddell> ScottK-laptop: ok, demoted and added to excludes to stop it wanting to be rescued into main
[15:59] <claydoh> apachelogger: yes, it is not installed
[16:00] <claydoh> deps on hunspell-en-us
[16:00] <apachelogger> claydoh, rgreening: that is not the problem
[16:01] <apachelogger> dpkg -L will show that the symbolic link and the file it links to are both in huspell-en-us/myspell-en-gb
[16:01] <claydoh> sorry rgreening
[16:01] <claydoh> wrong tabbing skillz here
[16:01] <apachelogger> for some reason teh installation goes wrong which only leaves the link
[16:02] <ScottK-laptop> Riddell: The only other KDE one, kleopatra needs the dirmngr MIR approved, which as pitti mentioned will take some thought.
[16:02] <apachelogger> now usually kmail would just not know about $dict if there is no file for $dict, but in this case there is a dict file (the symbolic link), kmail tries to open the dict file and goes wocka because the file it links to is not available (as seen in the claydoh's ls)
[16:02] <ScottK-laptop> Riddell: Optionally we could unseed kleopatra?
[16:04] <Tonio_> Riddell: found the issue for policykit-kde
[16:04] <Tonio_> Riddell: doesn't deal with the concept of admin users
[16:04] <Tonio_> only uses root by default
[16:05] <Tonio_> Riddell: I have some kde3 code that works with this, I'll port that to the current kde4 one
[16:05] <Tonio_> Riddell: contrib day on thursday so I expect to have something that works then
[16:07] <rgreening> apachelogger: which package? I can look at it
[16:07] <apachelogger> openoffice.org-dictionaries
[16:07] <rgreening> kk
[16:08] <Tonio_> Riddell: but I know you'll believe it when you see it ;)
[16:09] <apachelogger> claydoh: please add a comment to the upstream KDE bug, saying that the issue is that kmail chocks if a symbolic link goes to $nowhere, please also link to the bug report on launchpad ... I added 2 comments explainig the situation.
[16:11] <claydoh> apachelogger: ok, im on it
[16:12] <rgreening> apachelogger: is it one
[16:12] <apachelogger> rgreening: one what?
[16:14] <rgreening> doh.. typo.
[16:17] <rgreening> apachelogger: waht I was trying to ask was which particular part of the package fails (all links, some links, is it consistant - if you know)
[16:18] <jjesse> morning :)
[16:18] <apachelogger> all I know is that for both myspell-en-gb and huspell-en-us only the links get installed
[16:18] <apachelogger> ahoy jjesse
[16:18] <jjesse> ahoy apachelogger
[16:20] <jjesse> wasn't talk like a pirate day last week?
[16:20] <rgreening> on the oo package, there is no hunspell-en* but there is a myspell-en*
[16:20] <rgreening> apachelogger ^
[16:22] <jtechidna> ScottK-laptop, Riddell:
 jtechidna: not too hard.. add the Plasma::ToolTIpManager and Plasma::ToolTip classes to libplasma
[16:22] <apachelogger> rgreening: where does huspell-en-us come from?
 jtechidna: then add the tooltip code to the panel
 jtechidna: that code doesn't really touch anything else, so it would be pretty eays
[16:22] <rgreening> seperate package it seems... 1 sec lmc
[16:24] <claydoh> which is the correct package for kubuntu? hunspell or myspell?
[16:24] <apachelogger> rgreening: https://edge.launchpad.net/ubuntu/+source/hunspell-en-us
[16:24] <claydoh> reinstalling either one works for me
[16:25] <claydoh> so I can recommend the correct on in K -f-n
[16:25] <claydoh> and the kde bug report
[16:38] <vorian> !info kpovmodeler intrepid
[16:42] <Riddell> Tonio_: bon chance
[16:43] <Riddell> jtechidna: hmm?
[16:43] <jtechidna> Riddell: looks like taskmanager tooltips are feasible
[16:43]  * jtechidna is taking a stab at it
[16:44] <Riddell> cor
[16:45] <rgreening> apachelogger: I don't think the ooo package is at fault... at least It doesn't install hunspell-en* as it's seperate.
[16:46] <apachelogger> rgreening: it installs myspell-en-gb which was the actual crash cause for me
[16:46] <rgreening> oh... hmm.. lmc
[16:46] <rgreening> I have that package
[16:47] <apachelogger> and still both mysell and hunspell weren't installed properly as documented in the log I attached
[16:48] <Tonio_> Riddell: basically the current kde4 code is based on the pardus kde3 one ported
[16:48] <rgreening> k. I'll check in pbuilder env... see what happens
[16:48] <Tonio_> Riddell: pardus is still maintaining its kde3 codebase so I have to port the changes to kde4.... not an easy job
[16:48] <Tonio_> Riddell: but would be nice to get that done :)
[16:49] <Riddell> Tonio_: mm, sounds fiddly
[16:49] <Tonio_> Riddell: fiddly ? what does this mean ?
[16:49] <Riddell> "Requiring dexterity to operate"
[16:49] <Tonio_> Riddell: most of the code is the same, a good coder could get that done in one or 2 days.... it'll be way longer for me, but I'll try to get it done
[16:49] <Tonio_> Riddell: sure it is :)
[16:50] <Tonio_> Riddell: maybe if I can find another developper to help....
[17:01] <apachelogger> jtechidna: stop taskmanagering and continue backporting
[17:02]  * jtechidna haz idea, he can taskmanager while backports are building :D
[17:02] <apachelogger> jtechidna: actually
[17:02] <ScottK> jtechidna: That's be REALLY great.
[17:02] <apachelogger> jtechidna: go redo kdegraphics
[17:02] <apachelogger> we still have 4.1.1 in intrepid
[17:03] <jtechidna> uff
[17:03] <jtechidna> apachelogger: we have new tarballs in the magic directory?
[17:03] <apachelogger> yus
[17:03] <jtechidna> I suppose I should just check
[17:03] <jtechidna> :P
[17:16] <jtechidna> gah
[17:17] <jtechidna> forgot to make an Intrepid pbuilder
[17:18] <jtechidna> so while that's going on
[17:18] <jtechidna> How do I add entirely new files to a patch with quilt?
[17:20] <jtechidna> quilt add $file doesn't seem to add the new files to the patch
[17:24] <rgreening> apachelogger: I just built the package and looked at the resulting deb. It's fine. In fact, the deb in the repo is correct also... so, not sure why a symlink would be missing.
[17:25] <apachelogger> not the symlink is missing, the real file is missing
[17:25] <apachelogger> and the part where the deb actually contains the files is also show using dpkg -L in my exhibit-collection.txt :P
[17:33] <rgreening> apachelogger: I extracted the deb and it had the correct files (link and real file)
[17:38] <rgreening> apachelogger: I even remove the en* files and reinstall... works... not sure why your setup and mine is diff in this regard
[17:39] <apachelogger> maybe update-openoffice-dicts messed up
[17:47] <rgreening> maybe...
[17:47] <rgreening> it's not in the myspell or hunspell dict debs... at least with what I tried.
[17:47] <rgreening> hehe dict deb
[17:48]  * rgreening needs to get a life after finding that last line funny
[17:49] <rgreening> apachelogger: what triggers update-openoffice-dicts
[17:49] <apachelogger> rgreening: postinst/postrm
[17:50] <rgreening> hmm.. ran it manemually. no probl
[17:51] <apachelogger> well, not now, maybe it did in the last couple of days
[17:51] <rgreening> hmm... could be... Only way to verify would be to do a live CD
[17:52] <rgreening> and install lang packs and test
[17:52] <apachelogger> well
[17:52] <apachelogger> where does that exec come from
[17:52] <apachelogger> and did that package get updated recently
[17:52] <rgreening> I suspect it's a glitch/hiccup... I'd like to see someone duplicate it in a fresh install
[17:53] <rgreening> hmm
[17:53] <ScottK> jtechidna: I'll be offline for the next several hours, but let me know if you need a tester/uploader for the tooltip fix.
[17:53] <rgreening> I never had the issue at all, and I havew been updated constantly (several times a day while test building). And I use Kmail exclusively for everything
[17:54] <jtechidna> ScottK: I have the patch ready right now I believe, but I'll need to wait until kdegraphics is done to see how badly I maimed plasma
[17:54] <rgreening> jtechidna: me2
[17:55] <jtechidna> rgreening: would you like to test out the patch? I'll pastebin it
[17:55] <rgreening> sure thing
[17:55] <ScottK> jtechidna: OK.  Leave me a link to a debdiff or the patch and I'll look into it later.
[17:55] <jtechidna> have a good day
[17:55] <a|wen> ScottK: thx for the upload yesterday
[17:56] <jtechidna> rgreening: http://paste.ubuntu.com/52523/
[17:56] <rgreening> kool.
[17:56] <a|wen> ScottK: i'll try to see if the maillist bug in kdepim is replicaple today
[17:58] <rgreening> Hey, is there a package that can test the integrity of installed files belonging to packages (i.e. look for missing files - casuging package to be broken)? If not, we should write something. It would help probably resolve some extraneous bugs that crop us when users much their system up
[17:58] <apachelogger> rgreening: it doesn't really matter if it reappears in a new installation it certainly does for updates
[17:58] <rgreening> much/muck
[17:58] <a|wen> if anyone has anything that needs to be tested on gutsy or in relation to a gutsy -> hardy upgrade please send it ... i'll be doing such an upgrade in an hour or two
[17:59] <rgreening> apachelogger: hmmm... Ok, let me test. I built an updated package. I can test the theory 4 you
[18:16] <ScottK> a|wen: You're welcome.  Thanks for looking after the 3.5.10 stuff.
[18:16] <a|wen> no problem
[18:21] <ScottK> rgreening: If you're up for something QT'ish, could you have a look at bug 261380
[18:22] <rgreening> sure
[18:23] <apachelogger> Bug #269880
[18:23] <claydoh> rgreening: I think i will do a fresh install here of the daily I used, I think it was from friday
[18:23] <claydoh> rgreening: to see if i get the kmail bug
[18:23] <apachelogger> rgreening: login and check the .xsession-erros
[18:23] <claydoh> I did over the weekend, it worked for a day then it stopped again
[18:24] <apachelogger> rgreening: it should probably tell what is going on
[18:24] <claydoh> or try a newer one and see if it doesn't
[18:29] <ScottK> rgreening: Thanks.  pitti was interested in seeing it dealt with.
[18:31] <rgreening> ScottK: kk
[18:34] <rgreening> brb... reboot
[18:37] <Riddell> ScottK: do we want kleopatra?
[18:41] <rgreening> apachelogger: works fine on logout/login... but not on boot. something is causeing it to crash (python2.5 prob possibly)
[18:44] <rgreening> apachelogger: I think this may be related:  Bug #212388
[19:05] <rgreening> ScottK: Regarding bug 261380, we mirror debians package. How different do we want to be in this respect for this package? Should we file upstream and get them to change? Not sure, there may be a reason for their reasoning...
[19:09] <rgreening> Riddell: Is that patch in kdebase-workspace for kwin/compisite from the kwin11.1 suse guys? Cause I'm getting the repaint issue all over again today.
[19:19] <smarter> uh oh
[19:19] <smarter> Riddell: http://pastebin.com/m5badf8a6
[19:20]  * smarter thinks pyqt needs a rebuild
[19:21] <smarter> Riddell: firefox gives the same error when started, except if GTK2_RC_FILES is not set, so gtk-qt-engine probably needs a rebuild too
[19:32] <davmor2> Riddell: you around still?
[19:33] <rgreening> apachelogger: Confirmed... update-notifier-kde fails to run if there's a waiting crash file entry. See bug: 269880
[19:33] <rgreening> bug 269880
[19:35] <jtechidna> rgreening: I messed something up in the old patch
[19:35] <jtechidna> http://paste.ubuntu.com/52557/
[19:36] <rgreening> cool
[19:36] <jtechidna> without my fix cmake will fail after like a minute
[19:36] <rgreening> heh
[19:45] <rgreening> is there a way to force an application crash (i.e. so apport catches it)? Need to test something..
[19:51] <jtechidna> rgreening: close a folderview plasmoid
[19:52] <rgreening> lol.. lmt
[19:52] <davmor2> I noticed an interest flaw.   I did get a crash in using twitter plasmoid, that achieved my end result. bug 269880 confirmed
[20:00] <apachelogger> hmmm
[20:01] <apachelogger> ScottK: why do we need kleopatra again?


 I was wondering that. :)
[15:02] <greg-g> last day in DC for me
[15:04] <rick_h_> greg-g: back to west coast wheee


[06:53] <didrocks> good morning
[07:00] <duflu> Morning didrocks, seb128
[07:01] <didrocks> hey duflu
[08:59] <willcooke> top o' the mornin
[08:59] <willcooke> sunny today
[09:00] <didrocks> hey willcooke
[09:00] <didrocks> *unsunny* here :p
[09:01] <Laney> hey
[09:01] <Laney> YES! SUNNY!
[09:01] <seb128> hey willcooke, Laney
[09:01] <willcooke> didrocks, do you have the storms as well?
[09:01] <seb128> sunny friday!
[09:01] <willcooke> hey seb128 Laney
[09:01] <seb128> re didrocks, hey duflu
[09:02] <duflu> Hi willcooke, Laney, seb128 again
[09:02] <willcooke> ar'noon duflu
[09:03] <Laney> moin seb128 willcooke duflu
[09:26] <duflu> Laney, was I correct yesterday in guessing your desktop uses Nvidia?
[09:27] <Laney> It does
[09:28] <duflu> Laney, yeah I've been meaning to deduplicate those bugs. I think you will find at least one relating to your fallback not working (https://bugs.launchpad.net/ubuntu/+source/gdm3/+bugs?field.tag=nvidia)
[09:30] <Laney> Seems likely
[09:30] <Laney> I might have a look into it a bit later on
[09:52] <didrocks> willcooke: well, big wind, but no storm
[10:20] <willcooke> story of my life
[10:23] <didrocks> lalala lala lalalala
[10:57] <andyrock> morning all!
[10:57] <didrocks> hey andyrock
[12:01] <andyrock> seb128: https://github.com/micheleg/dash-to-dock/pull/848
[12:01] <gitbot> micheleg issue (Pull request) 848 in dash-to-dock "SRU fix for LP: 1769383" [Open]
[12:01] <andyrock> I'll update the bug description
[12:01] <andyrock>  to make it SRUable
[12:03] <andyrock> seb128: also we need to ask Trevinho to add commits and tags once it's released
[12:43] <andyrock> seb128: bug updated!
[12:59] <seb128> andyrock, thx
[13:47] <popey> I'm on 18.04. On 18.10 (or future plans?) is it possible to have different scaling factors on each display?#
[13:48] <popey> (I just got a HIDPI display and when I change the scale it seems to affect all displays, oddly).
[13:51] <willcooke> popey, you could try in the wayland session, I think that will let you apply different scaling factors
[13:51] <popey> :( wayland on nvidia isn't fun
[13:52] <willcooke> T_revinho is working on fractional scaling in X this cycle.  I /think/ that lets you apply different scaling to each screen
[13:54] <popey> Neat!
[15:35] <Trevinho> morning
[15:35] <Trevinho> andyrock: hey
[15:35] <andyrock> Trevinho: morning
[15:36] <andyrock> not sure seb128 is around atm
[15:36] <andyrock> Trevinho: how is Mexico?
[15:38] <Trevinho> andyrock: Mexico is always amzing... But I'm in Cuba now :)
[15:38] <willcooke> hey Trevinho
[15:38] <Trevinho> hi willcooke
[15:40] <andyrock> Trevinho: say hi to your sweet half ❤
[15:41]  * andyrock meant your OTHER sweet half
[15:43] <Laney> Marco "carbon emissions" Trevisan ✈✈✈✈✈✈✈✈✈✈✈✈
[15:43] <Laney> hi 😘
[15:44] <Trevinho> Laney: heeeeey, yeah... I made the global warm to be real. Otherwise someone doesn't believe it's true. So need to stress :-D
[15:45] <Trevinho> andyrock: ahahaha, thanks
[15:49] <andyrock> 🤣
[16:30] <jbicha> seb128: re LP: #1805426 there is a bug (webkit?) causing GOA to not work in (some?) VMs
[16:32] <jbicha> hmm, I guess my comment isn't relevant here though
[16:42] <jbicha> Laney: I guess we can upload nautilus with tracker dependency now?
[16:43] <Laney> jbicha: if the bugs are Fix Committed, if not then you need to go back to the MIR team
[16:43] <Laney> If it were me I'd wait and do it with 3.30 all at once though
[16:44] <Laney> will need an MIR for the desktop icons of course
[16:44] <jbicha> Laney: I'll let you handle it
[16:44] <Laney> but that one could be seeded later on
[16:46] <Laney> thx
[16:52] <k_alam> seb128: Hi, can you review few unity patches ? they are small
[17:09] <seb128> k_alam, hey, not today, I'm about to call it a week
[17:09] <seb128> on that note
[17:09] <seb128> good w.e desktopers!
[17:09] <willcooke> see you seb128
[17:10] <seb128> willcooke, enjoy the w.e!
[17:10] <willcooke> you too
[17:10] <seb128> andyrock, did you need me for something earlier when you said I was not around, I see no context ... anyway let me know, I let IRC open and read the backlog later
[17:10] <seb128> but if it can wait for monday it's probably for next week :)
[17:11] <seb128> k_alam, same for your reviews
[17:11] <andyrock> seb128: it can wait! we wanted to discuss about the possibility to move ubuntu-dock branches under our git
[17:12] <andyrock> but let's discuss it mon/tue
[17:13] <kenvandine> willcooke: i have yelp integration working in snaps :)
[17:21] <Laney> this cafe is blasting out christmas tunes
[17:21] <Laney> NO
[17:22] <k_alam> Alright.
[17:22] <willcooke> yelp?
[17:23] <kenvandine> willcooke: yeah, for help
[17:23] <willcooke> kenvandine,
[17:23] <willcooke> oops
[17:23] <kenvandine> never worked before
[17:23] <kenvandine> i have a patch for snapd that fixes it
[17:23] <willcooke> ohhhhhhhhhhhhh
[17:23] <willcooke> Oh wow
[17:23] <willcooke> neat!
[17:23] <Laney> nice
[17:24] <kenvandine> it's been bugging me for ages
[17:24] <kenvandine> now to get this landed :)
[17:29] <willcooke> :)
[18:14] <willcooke> night all, have a good weekend


[00:18] <dslip_work> howdy guys, im playing around with supybot & the ubuntu supybot plugins. I am wondering if anyone here has some experience in configuring the encyclopedia
[00:19] <bazhang> !plugins
[00:19] <persia> You may find #ubuntu-bots-devel a better forum for your question
[00:20] <dslip_work> ok, just thought as a user, might not be the right place
[00:22] <dslip_work> !plugins
[00:32] <persia> Just be gentle about how you ask :)
[19:59] <NeoRanger> hola!!
[19:59] <NeoRanger> alguno que hable español me puede ayudar??
[20:01] <AlanBell> !es


[08:18] <adrien> \o
[08:32] <adrien> is there a way to get a serialized output from apparmor profiles? I'd like to see which paths are covered (I don't need exact data, only approximate)
[08:33] <adrien> I've see -p to only preprocess profiles which might be enough to grep with the paths that I am interested in but I'm wondering if there's a cleaner way
[11:41] <adrien> I finally had another look at erlang/rabbitmq-server and the TLS configuration appears to be simply forwarded to erlang/tls without going through code which means that any code change would have to be done in erlang instead and I'm not proficient in erlang
[18:32] <tsimonq2> adrien: jjohansen or sarnold may know the answer to your AppArmor question. That's a good one, let me know what you find.
[18:35] <jjohansen> adrien: so currently apparmor_parser -p is probably your best bet, there is wip to be able to expose more controls around the profile dump (different levels of processing) but nothing that is available atm
[18:36] <jjohansen> at least not cleanly, there are the -D flags, but their dumps can change (its not a fixed format) and they are fairly messy
[18:37] <jjohansen> apparmor_parser --help=D
[18:37] <jjohansen> will give the full list supported by a give parser
[18:41] <jjohansen> apparmor_parser -D rule-exprs would be the next closest thing to -p, it late stage dumping what the rules get converted to before the statemachine build
[18:41] <jjohansen> it comes after includes, variable expansion, rule dedup, etc. It has a certain order to it, but exactly what depends on the dedup phase and that has changed over time, and not all rule types have always supported dedup, etc.
[18:41] <jjohansen> and a single rule might expand into multiple rule-exprs
[18:41] <jjohansen> so it probably not what you are looking for
[18:45] <georgiag> --debug might be helpful as well
[18:46] <jjohansen> but as with dump, its messy and not a fixed format
[18:47] <jjohansen> debug also can vary based on how the parser is compiled, as some of the output will only happen when DEBUG is set at build time
[18:47] <jjohansen> but most it doesn't
[19:02] <adrien> thanks, these all look interesting; I'm not sure which one I'd settle on right now and I guess I'll know when I start using that at scale
[19:03] <adrien> for context, I am interested in finding out which packages ship server programs which communicated over TCP and do TLS, and maybe other protocols
[19:03] <adrien> I have some heuristics but more heuristics is better (and I'll also expand the scope but as you can imagine, there are already quite a few package that match this)
[20:15] <plugwash> hi, the autopkgtest documentation mentions a file called big_packages, but it doesn't say anything about how to view said file or request changes. Can anyone elaborate?
[20:18] <plugwash> ok, I just reread the page and saw the git repo, still leaves the question of how to request changes.
[20:21] <vorlon> plugwash: MP
[20:23] <plugwash> do you mean MR? if so where? (the repo i've found doesn't appear to be on a gitlab instance)
[20:23] <vorlon> merge proposal; the repository is in launchpad, are you familiar with launchpad code hosting?
[20:26] <vorlon> plugwash https://code.launchpad.net/~ubuntu-release/autopkgtest-cloud has some info at the top about how this works
[20:38] <plugwash> hmm, I've cloned the repo, but I can't find big_packages, looking at the cgit url it looks like it's on it's own branch, but I don't seem to have that branch in my clone
[20:38] <vorlon> oh sorry one sec
[20:39] <vorlon> that's simply the wrong repo I mangled urls when trying to translate
[20:39] <vorlon> https://code.launchpad.net/~ubuntu-release/autopkgtest-cloud/+git/autopkgtest-package-configs
[20:55] <plugwash> ok I've made and pushed a commit, how do I turn that into a merge proposal?
[20:57] <bdmurray> when you did the push you should have seen a url for creating an MP
[20:58] <bdmurray> https://code.launchpad.net/~plugwash/autopkgtest-cloud/+git/autopkgtest-cloud/+ref/main or there is a propose for merge link there
[20:58] <bdmurray> In the MP it would be helpful to point a failure log
[21:47] <bdmurray> plugwash: Do you suspect that there are more packages that might need moving to big_packages?
[21:51] <plugwash> I would not be at all surprised but i'm not going to read every log to find out.
[21:52] <bdmurray> plugwash: there is a tool called retry-autopkgtest-regressions that aids in searching log files but I'll do that
[22:17] <rbasak> plugwash: hello! Long time! Thank you for your help!
[22:57] <bdmurray> liushuyu: what did you do to test the regression potential of gdb e.g. "may break ARM64 execution"?


[00:02] <pitti> cjwatson: my OEM test install hangs at the finish installation stage with 'Disabling netinst CD in sources.list...'
[00:03] <pitti> ah, nevermind; it just got stuck doing apt-get update
[00:04] <EvanCarroll> hrm
[00:10] <keescook> pawalls: okay, cool; thanks.  :)
[00:16] <slangasek> stgraber: ok, fundamentally there seems to be a problem with the tracker's link checker; even after switching the build number and waiting for cdimage.u.c to sync, I still get told for all images that "This build wasn't found on cdimage.ubuntu.com"
[00:16] <slangasek> gnyaah
[00:16] <slangasek> l-u-m FTBFS
[00:17] <slangasek> ... because of the merged -rt support
[00:19] <ogra_cmpc> any xfs pro around ?
[00:19] <ogra_cmpc> /usr/sbin/debootstrap: 317: cannot create /home/ogra/chroot-livecd/test-dev-null: No such device or address
[00:19] <ogra_cmpc> seems i cant create any devices on my xfs partition
[00:19] <ogra_cmpc> its not mounted with nodev or so
[00:24] <cjwatson> ogra_cmpc: hmm
[00:24] <cjwatson> let me see if I can reproduce that here
[00:24] <ogra_cmpc> it works fine on the /boot partitioni have
[00:27] <cjwatson> I introduced that debootstrap check quite recently; it might be buggy
[00:27] <cjwatson> could you put 'set -x' at the top of /usr/share/debootstrap/functions and get a shell trace?
[00:28] <ogra_cmpc> sure
[00:28] <cjwatson> ENODEV, though, that's just weird
[00:28] <cjwatson> not a documented return code from mknod(2)
[00:29] <ogra_cmpc> cjwatson: http://paste.ubuntu-nl.org/49089/
[00:32] <ogra_cmpc> root@ceron:~# mkdir test
[00:32] <ogra_cmpc> root@ceron:~# mknod test/test-dev-null c 1 3 || echo "failed"
[00:32] <ogra_cmpc> root@ceron:~# echo "blah" >test/test-dev-null
[00:32] <ogra_cmpc> bash: test/test-dev-null: No such device or address
[00:32] <ogra_cmpc> root@ceron:~#
[00:32] <cjwatson> ogra_cmpc: any other mount options I should know about?
[00:32] <ogra_cmpc> ogra@ceron:~$ cat /proc/mounts |grep " / "
[00:32] <ogra_cmpc> rootfs / rootfs rw 0 0
[00:32] <ogra_cmpc> /dev/md0 / xfs rw,sunit=128,swidth=256,ikeep,noquota 0 0
[00:33] <cjwatson> xfs, home of mount options nobody else recognises
[00:33] <ogra_cmpc> heh
[00:33] <ogra_cmpc> well, i didnt specify any options at all
[00:33] <ogra_cmpc> its the default teh installer choose
[00:36] <cjwatson> seems to WFM on a fresh XFS partition
[00:37] <cjwatson> s/partition/filesystem/
[00:37] <cjwatson> /home/cjwatson/xfs.disk on /mnt type xfs (rw,loop=/dev/loop0)
[00:37] <cjwatson> sunit and swidth are md things, ikeep and noquota aren't things the installer sets AFAICS, maybe defaults?
[00:37] <ogra_cmpc> hmm
[00:38] <ogra_cmpc> it seems teh xfs deeply ties into teh raid0 below
[00:38] <cjwatson> it's still a weird error though
[00:38] <ogra_cmpc> the suinit and switdh parameters seem to adjust values for the raid striping
[00:39] <cjwatson> might be worth checking dmesg for any errors there
[00:39] <cjwatson> it really looks like it's mounted with something that implies nodev, but I can't see what
[00:39] <ogra_cmpc>    39.130673] Filesystem "md0": Disabling barriers, not supported by the underlying device
[00:39] <ogra_cmpc> well, that should only affect speed
[00:40] <ogra_cmpc> nothing else intresting in dmesg
[00:40] <ogra_cmpc> no fresh errors in any logs either
[00:41] <cjwatson> kernel version?
[00:41] <ogra_cmpc> ogra@ceron:~$ uname -a
[00:41] <ogra_cmpc> Linux ceron 2.6.24-2-generic #1 SMP Fri Dec 14 00:02:38 GMT 2007 i686 GNU/Linux
[00:41] <ogra_cmpc> todays :)
[00:41] <cjwatson> I'm still on 2.6.22, FWIW
[00:41] <cjwatson> so that could explain the difference
[00:42] <ogra_cmpc> i got a .22 on it but i wont go in teh basement and reboot now, to tired ...
[00:42] <ogra_cmpc> hmm, i could fiddle wit grub remotely :)
[00:45] <ogra_cmpc> cjwatson: yep, seems to be a kernel based issue
[00:45] <ogra_cmpc> 2.6.22 works fine
[00:52] <pawalls> keescook, ping
[01:56] <keescook> pawalls: pong!
[02:04] <pawalls> keescook, Patch uploaded and confirmed to fix the OOPS when mounting NFSv4
[02:17] <keescook> pawalls: excellent, so, here's the weird part -- I'm able to mount with nfsv4 without crashes.  :(  Is the failing configuration special in some way?
[02:19] <keescook> pawalls: ah, nm, it seems to be partial hang.
[02:19] <keescook> I'll get stuff spun up -- thanks for sorting out this patch!
[03:27] <IntuitiveNipple> Is there a reason that bluez-utils doesn't build/install sdpd (Bluetooth Service Discovery Protocol daemon)? Because of this, remote devices can't discover services making connections impossible in some cases.
[03:28] <StevenK> IntuitiveNipple: In Hardy?
[03:29] <IntuitiveNipple> I'm using Gutsy, but looks like it's carried forward into Hardy too.
[03:29] <IntuitiveNipple> I've been tracking the changelogs, looked through the bugs, etc., and now working with the source. Trying to find out why it is not built
[03:30] <StevenK> Does it pose security problems if it is?
[03:36] <IntuitiveNipple> It poses a usability problem if SDP isn't available to remote devices - they can't discover any services to connect to! I'm just checking things out with Marcel Holtmann so I can be sure what/why etc :)
[03:38] <Burgundavia> IntuitiveNipple: ask pitti and mjg59
[03:40] <IntuitiveNipple> I think it's more of a 'changing target' issue with the bluez-utils userspace applications. Once I've got a definitive answer I'll post a bug-report if needed.
[03:40] <StevenK> I don't think I like the idea of a daemon broadcasting what I'm running over Bluetooth
[03:41] <IntuitiveNipple> If the BT device isn't discoverable, it ain't available, but when the device is discoverable, I want the darned thing to tell my devices what it can do!
[03:42] <Burgundavia> IntuitiveNipple: I am going to guess it is a security issue
[03:42] <persia> IntuitiveNipple: Might be nice to have a configuration tool to allow exposure of desired services without broadcasting to anyone within 10 metres.
[03:44] <IntuitiveNipple> It appears maybe it isn't. It looks like, along with the other bluez* deamons, the functionality has been incorporated into the hcid daemon, and by default Gutsy/Hardy both configure it to operate the internal SDPD server. The problem is, it isn't exposing the services (on my tests anyhow) even though I've customised the 'class' setting in /etc/bluetooth/hcid.conf as required.
[04:46] <slangasek> Burgundavia: ribbit
[04:48]  * Fujitsu squishes slangasek under his foot.
[04:49]  * Hobbsee tries to remember what a fast X actually feels like
[04:49]  * Fujitsu hugs XAA.
[04:49]  * Hobbsee would hug it, except for the random, exploding crashes
[04:50]  * Fujitsu just has the one or two a day.
[04:55] <Farquad> anyone know if a music player exists that would allow me to add files to a playlist on one computer, then have another node pc play those files when i click play? (a remote controlled client)
[04:55] <Fujitsu> This isn't a support channel.
[04:55] <persia> Farquad: Yes, but you likely want to ask which of them is good for your use case, and how to use them in #ubuntu or #ubuntu-xx.
[04:57] <Farquad> i wasnt asking for support, i was trying to find out if something like this already existed
[04:57] <Hobbsee> which is a support related question, not a developmen tone...
[04:58] <Hobbsee> i think there is, though.  i don't remember what it's called, but i expect google, etc, could help there
[05:03] <Farquad> sorry to interrupt all the conversations going on in here
[05:37] <Hobbsee> note to self:  don't replace current X driver, in an X session.
[05:37] <Fujitsu> That shouldn't normally do much...
[05:38] <Hobbsee> no, but if you end up copying it over to what it's directly using..it appears to mangle your X
[05:38] <StevenK> It should be mmap()'d if it's using it
[05:41] <Hobbsee> unless compiz screwed it over, or something.  *shrug*
[05:43] <Fujitsu> Hah.
[05:45] <Hobbsee> oooh...
[05:45] <Hobbsee> *this* is what fast X feels like
[05:45] <Fujitsu> New driver works?
[05:45] <slangasek> yes, replacing the X driver from within X isn't supposed to break anything
[05:46] <Fujitsu> slangasek: That's what I thought, or upgrades would be a bit difficult.
[05:46] <StevenK> Until you restart X at least. :-P
[05:46] <slangasek> the driver is already loaded in memory, unpacking the new one just means the driver on disk doesn't match the one that's running (due to the magic of POSIX file deletions)
[05:48] <Hobbsee> Fujitsu: no, but i switched from exa to xaa again
[05:48] <Fujitsu> Ahh.
[05:48] <Hobbsee> slangasek: yeah well.  that's what i thought should happen.
[05:48] <Hobbsee> until my screen went bang.
[05:49] <slangasek> seems more plausible that it was StevenK emitting X-interference
[05:49]  * StevenK looks innocent.
[05:50] <Burgundavia> slangasek: rabbit
[05:52] <slangasek> Burgundavia: hiya. were you still going to have time to work on alpha2 release notes? :)
[05:53] <Hobbsee> keep in mind, he'll shoot you if you don't do them
[05:55] <slangasek> now, now, I very rarely shoot people for things they /haven't/ done
[05:55] <Hobbsee> no time like the present to start, then
[05:56]  * Fujitsu thinks slangasek unleashes the Canonical-issue doomsday device in that case.
[06:42] <warp10> Hi all!
[06:48] <musther> Hello
[07:03] <Burgundavia> slangasek: sadly real life intervened, so no
[07:08] <slangasek> ok
[07:09]  * slangasek scribbles something quickly in crayon
[07:26] <dholbach> good morning
[08:03] <Hobbsee> morning pitti!
[08:03] <pitti> Good morning
[08:04]  * pitti yawns
[08:04]  * Hobbsee force feeds pitti some coffee
[08:05] <pitti> argl coffee!
[08:05]  * pitti redirects Hobbsee to some tea
[08:05] <sivang> hi all
[08:10]  * Hobbsee force feeds pitti a mix of coffee and tea, then.
[08:10] <Hobbsee> heya sivang!
[08:10] <pitti> hey sivang
[08:12] <Fujitsu> Hobbsee: That sounds even more revolting than normal coffee. Spoiling perfectly good tea...
[08:12] <Hobbsee> Fujitsu: there is no good tea.
[08:12]  * pitti celebrates the release of apport 0.100
[08:12] <dholbach> Hobbsee: pfffft
[08:12] <dholbach> pitti: ROCK ON :)
[08:12] <StevenK> pitti: My upload of gimp broke :-(
[08:13] <StevenK> As in, it FTBFS
[08:13] <Fujitsu> Hobbsee: Oy. <3 tea.
[08:13] <Fujitsu> pitti: What's new?
[08:13] <slangasek> StevenK!
[08:13] <pitti> Fujitsu: primarily that it doesn't spill core files everywhere with our new kernel
[08:13] <StevenK> slangasek: Hrm?
[08:14] <slangasek> StevenK: I see you uploaded libofa?
[08:14] <StevenK> slangasek: Right
[08:14] <Hobbsee> StevenK: run.  run now.
[08:14] <slangasek> StevenK: you broke kubuntu
[08:14]  * sivang hugs pitti Fujitsu Hobbsee dholbach StevenK
[08:14]  * Hobbsee hugs sivang
[08:14] <sivang> Hobbsee: thanks, I needed that
[08:14] <dholbach> hey sivang
[08:14]  * Fujitsu hugs sivang.
[08:14] <pitti> Fujitsu: the rest are just fixes to the retracers which were rolled out long ago
[08:14]  * dholbach hugs sivang back
[08:14] <sivang> hey you dholbach my good o' friend :)
[08:14] <Fujitsu> pitti: Aha.
[08:15] <slangasek> StevenK: we're now straddling a package name change for fftw3->libfftw3-3, and the packages conflict and kubuntu needs things depending on both of them
[08:15] <pitti> Fujitsu: but apport is now compatible with a vanilla upstream kernel >= 2.6.24, that's great
[08:15] <sivang> dholbach: I'm sorry for not responding for the patch apply request for hubackup, I've been through a bit like hell during the last couple of months but I'm back in shape
[08:15] <StevenK> slangasek: Right, I'm still cleaning up that mess.
[08:15]  * sivang enjoys the hugging
[08:15] <dholbach> sivang: it's great to hear you're back!
[08:16] <sivang> thanks! =)
[08:16] <Fujitsu> pitti: Oh, nice.
[08:16] <StevenK> slangasek: If you want some packages pushed up the queue, bug me with their source name
[08:16] <slangasek> StevenK: does this mean you have a libtunpimp upload pending, or should I go ahead and upload this no-change rebuild?
[08:16] <sivang> dholbach: I need to apply the branch with the patch there waiting, and then move on to rewrite the backend to use rdiff backup instead of dar
[08:16] <StevenK> slangasek: Ah, libtunepimp. Go ahead with that, I'll follow later tonight with another batch of rebuilds.
[08:16] <dholbach> sivang: ok cool
[08:17] <sivang> and ofcourse, the joy of helping merges, fixing packages etc etc
[08:17] <Hobbsee> StevenK: and risk being killed again?
[08:17] <sivang> dholbach: are you by any chance a CC person ?
[08:17] <StevenK> Not me not being killed.
[08:18] <slangasek> hmm, or should I change libtunepimp so that it's not linking to fftw at all, since it's not using it :P
[08:18] <dholbach> sivang: yes, but I think you can renew your ubuntumembers membership yourself
[08:18] <slangasek> nah, that can be my next upload
[08:20] <sivang> dholbach: it won't let me since it expired, I was too busy and offline to notice the emails
[08:20] <dholbach> sivang: taking a look
[08:20] <sivang> dholbach: thanks
[08:21] <slangasek> StevenK: so is there a reason you uploaded libofa in the middle of a milestone freeze? <smiles sweetly>
[08:21] <StevenK> It wasn't a milestone freeze when I uploaded it.
[08:21] <dholbach> sivang: renewed it
[08:21] <StevenK> It required curl to get fixed and then it was given-back
[08:21] <slangasek> StevenK: timestamp says Dec 19
[08:22] <slangasek> freeze started on Tuesday
[08:22] <sivang> dholbach: thank you!
[08:22] <StevenK> Ah
[08:22] <Hobbsee> StevenK: hint:  blame timezones
[08:22] <StevenK> slangasek: In which case, it completly slipped my mind, sorry
[08:22] <slangasek> right
[08:23] <StevenK> Maybe a little of what Hobbsee said, too
[08:23] <slangasek> note to self to always send out a u-d-a mail at the start of any freeze
[08:23] <StevenK> Yeah, that'd help
[08:23] <sivang> ah, so we're in a freeze now? but probably universe is as usual still open ?
[08:23] <slangasek> StevenK: except I know what way the clock runs, so it was /definitely/ Wednesday for you when you uploaded it ;)
[08:24] <StevenK> Bah, out-smarted again :-P
[08:24] <Hobbsee> slangasek: australian clocks are different.
[08:24] <Hobbsee> slangasek: they run backwards, as we're upside down.
[08:24] <slangasek> that's right, the coriolis force makes them.. .bah
[08:24] <StevenK> Haha
[08:24] <slangasek> anyway
[08:25]  * StevenK runs off to get din-dins
[08:25] <slangasek> at least as much my fault, for thinking I could skimp on announcing a self-imposed freeze
[08:25]  * persia requests that slangasek add a small note about universe on the reminder note to announce freezes.
[08:26]  * sivang wonders how he can catch up with all protocl and workflow changes since last time, or has the DistroPolicyTracker been implemented yet? :-))
[08:26] <slangasek> persia: and miss out on our monthly game of "what does this mean for universe"? ;)
[08:26] <slangasek> persia: yes, ok
[08:26] <persia> slangasek: Thank you :)
[08:26] <sivang> slangasek: heh
[08:26] <persia> slangasek: Feel free to ping me if you need text :)
[08:27] <slangasek> libtunepimp ubuntu2 uploaded
[08:28]  * sivang wonders if http://blog.vaxius.net/?p=19 has a bug reported against it, probably needs a patch revert on the SLUB for folks who have ATI cards
[08:35] <slangasek> StevenK: btw, you know libfftw3-dev still Provides: fftw3-dev?
[08:41] <pitti> (just FAOD, our buildds consider pure virtual package dependencies, so we could even just remove the NBS one)
[08:42] <slangasek> I just did that
[08:42] <slangasek> :)
[08:43] <pitti> sivang: policy> Ubuntu development policies are documented at wiki.ubuntu.com/UbuntuDevelopment; some months ago I documented all the freezes, too, and cleaned them up a bit; it's linked from that page
[08:44] <TheMuso> So with all this new xorg stuff, how is one supposed to tell xorg about one's monitor, if they happen to be using it through a KVM that prevents DDC/monitor probing? I see dpkg-reconfigure xserver-xorg doesn't include monitor options any longer for setting resolutions/refresh rates.
[08:44]  * TheMuso has just done an alternate install with the latest image and run into my above issue.
[08:45] <slangasek> TheMuso: uh, I think step 1) is "file a bug on xserver-xorg"? :)
[08:46] <tjaalton> TheMuso: displayconfig?
[08:46] <TheMuso> slangasek: Ok, I thought removing monitor options from dpkg-reconfigure was intentional.
[08:46] <tjaalton> it is
[08:46] <slangasek> well, ok
[08:47] <tjaalton> but yes, it seems that vmware and KVM have issues with it
[08:47] <tjaalton> but I'm not sure how it worked before
[08:47] <tjaalton> TheMuso: bug 172821
[08:47] <ubotu> Launchpad bug 172821 in xorg-server "[hardy] only get 800x600 in vmware" [Medium,Confirmed] https://launchpad.net/bugs/172821
[08:48] <pitti_> tjaalton: hm, just booted my desktop, X failed with "could not find read-edid blabla"; missing dependency?
[08:49] <pitti_> tjaalton: ooh, I bet that's just because -nvidia-new is uninstallable
[08:49] <tjaalton> right :/
[08:49] <pitti_> and then the failsave X kicks in and fails, too
[08:49] <sivang> pitti_: oh wow, cool :) finally
[08:49] <TheMuso> Ok, so in displayconfig-gtk, how am I supposed to set resolution/refres rate, if the combox boxes have nothing in them?
[08:50] <pitti_> FSVO "failsafe" :)
[08:50] <tjaalton> TheMuso: now that's another problem :)
[08:50]  * TheMuso is in the screen tab
[08:51] <tjaalton> I'll install gutsy on vmware to see how it got it
[08:51] <TheMuso> tjaalton: Remember, I am using my monitor through a KVM that prevents proper monitor probing.
[08:52] <slangasek> TheMuso: what model is that so I know not to get it when I go shopping next month? :)
[08:52] <slangasek> the kvm model, I mean
[08:52] <tjaalton> TheMuso: oh KVM, I thought you meant the virtualization software :)
[08:52] <TheMuso> slangasek: Couldn't tell you at the moment, and I'd have to get sighted assistance to tell me anyway.
[08:52] <slangasek> TheMuso: ok, please don't go to the trouble then
[08:52] <TheMuso> Needless to say, I'll be saving up for a better one.
[08:53] <tjaalton> TheMuso: in that case please file a bug on xorg-server
[08:53] <TheMuso> I liked the fact that it was 4 ports when I got it, and I was assured, dispite not being able to confirm it, that it supported DDC/probing.
[08:53] <TheMuso> tjaalton: Ok.
[08:53] <tjaalton> TheMuso: so you get a crappy resolution with it?
[08:53] <TheMuso> tjaalton: 800x600
[08:54] <tjaalton> yeah..
[08:54] <TheMuso> Yet my monitor is capable of 1680x1050
[08:54] <persia> TheMuso: You may be able to fool displayconfig-gtk if you can download the edid file from somewhere.
[08:54] <TheMuso> persia: edid?
[08:55] <TheMuso> I could also temporarily plug the monitor in directly.
[08:55] <TheMuso> tjaalton: on xorg-server, or xserver-xorg?
[08:56] <tjaalton> TheMuso: the former, it's the source package for xserver-xorg-core
[08:56] <TheMuso> right
[08:56]  * TheMuso goes to do just that.
[08:56] <tjaalton> TheMuso: also, if you have one please attach the good Xorg.0.log
[08:56] <persia> TheMuso: The data read-edid would be getting from the monitor, giving resolution, refresh rates, etc.
[08:56] <TheMuso> persia: RIght.
[08:57] <TheMuso> tjaalton: I can get that from another machine on the same KVM that is correctly configured to work with the monitor.
[08:57] <tjaalton> TheMuso: did it work OOTB?
[08:57] <TheMuso> OOTB?
[08:57] <tjaalton> out-of-the-box
[08:58] <TheMuso> tjaalton: No, I ran dpkg-reconfigure xserver-xorg, this is on hardy, a little while back.,
[08:58] <TheMuso> As I said, KVM not supporting monitor probing.
[08:58] <tjaalton> TheMuso: oh right
[08:58] <tjaalton> yep, and since you can't select a valid resolution you're doomed
[08:58] <TheMuso> Yep.
[09:00] <tjaalton> TheMuso: so, I'm not sure yet if it can be fixed by the server, but at least it should be possible to force the resolution using displayconfig-gtk or similar
[09:01] <TheMuso> Ok
[09:02] <TheMuso> tjaalton: Off hand, is there any bug that is similar, so I'm not creating a dup?
[09:02] <tjaalton> TheMuso: not that I remember
[09:02] <persia> tjaalton: displayconfig-gtk reacts poorly to not having a valid edid and not being able to get one from the monitor.
[09:02] <TheMuso> tjaalton: ok thanks
[09:02] <TheMuso> filing now
[09:03] <tjaalton> persia: yeah, I realize that, but perhaps it could be extended somehow
[09:04] <persia> tjaalton: Right now it asks for an EDID if it can't get one, and generally flails when given the wrong one.  Perhaps defining a generic set for 10 or 15 standard sizes as fallbacks?
[09:05] <TheMuso> or allowing the user to enter the info manually.
[09:06] <TheMuso> WHen I usually run dpkg-reconfigure xserver-xorg, I enter monitor refresh rates, and select resolutions manually.
[09:07] <TheMuso> Bug 177852
[09:07] <ubotu> Launchpad bug 177852 in xorg-server "Unale to manually configure monitor resolution and refresh rate with latest xorg-server in hardy." [Undecided,New] https://launchpad.net/bugs/177852
[09:08] <tjaalton> TheMuso: thanks
[09:09] <TheMuso> tjaalton: np.
[09:24] <kagou> Good morning
[09:34] <pitti> hi kagou
[09:34] <kagou> hey pitti, what's up ?
[09:38] <StevenK> slangasek: I got told this after the 46 uploads I did made the change.
[09:40] <slangasek> StevenK: haha
[09:40] <slangasek> StevenK: well, you get to merge them next release cycle ;
[09:40] <slangasek> )
[09:40] <ion_> Heh
[09:40] <StevenK> Or get a shedload of mail saying "You have lots of merges, can I do them all?"
[09:40] <pitti> argh, these reboots between .24 and .22 are unnerving, brb
[09:41] <slangasek> to balance things out, I'll send you a mail saying "You have lots of merges, can you do them all?"
[09:41] <StevenK> Hah
[09:43] <geser> good morning
[09:43]  * slangasek moos
[09:47] <dholbach> hey pitti, hey mvo
[09:48] <mvo> hey dholbach!
[09:48]  * pitti hugs dholbach
[09:48]  * dholbach hugs pitti and mvo
[09:48] <pitti> dholbach: just rebooted :)
[09:48] <pitti> .24 still has a few wrinkles
[09:57] <geser> Hi pitti
[10:01] <ulaas> anybody interested with install problems (gutsy) on an intel c2duo imac?
[10:07] <ulaas> anybody interested with install problems (gutsy) on an intel c2duo imac?
[10:09] <ion_> Is it just me, or does it echo in here?
[10:09] <ulaas> u?
[10:11]  * Fujitsu notes that it does echo, and that this isn't a support channel.
[10:13] <seb128> echo echo echo
[10:13] <ulaas> easy! :) i know that this is not the support channel. i just thought that people here might be more interested than in #ubuntu
[10:13] <mvo> ohce
[10:14] <seb128> hey mvo
[10:15] <mvo> hey seb128
[10:30] <mjj29> so, my dbus-java build from yesterday was retried, and the b-d installed fine
[10:31] <mjj29> but it still failed because the buildd is not using a UTF-8 locale
[10:32] <slangasek> sounds like a source bug on your end to me ;)
[10:32] <mjj29> (the tests have utf8 string literals to check that utf8, which is the defined format for dbus strings, works; java interprets string literals in the current locale)
[10:33]  * Fujitsu wonders if python-apt can be used to poke around in source caches too.
[10:33] <mjj29> and the tests are run at build time to check for regressions
[10:33] <mjj29> I'm not sure how best to fix this
[10:33] <slangasek> mjj29: there are various examples of packages in the archive that build-depend on locales and generate a copy of locales that they need locally; your package should either do this, or not expect utf8 support
[10:33] <mjj29> slangasek: is there an easy way to find one of these to crib from?
[10:34] <slangasek> mjj29: grep-dctrl -FBuild-Depends locales ? :)
[10:34] <mjj29> slangasek: thanks
[10:35] <slangasek> ipolish looks like a pretty straightforward one
[10:37] <TheMuso> tjaalton: Re the bug I filed, I've just connected the monitor directly, and re-run displayconfig-gtk. The bug has the relevant log and info.
[10:43] <slytherin> pitti: There are several java libs/apps which need to be moved to universe. I have logged a tracking bug which is confirmed by geser. Is there any chance it will get processed today?
[10:43] <tjaalton> TheMuso: ok thanks
[10:53] <pitti> slytherin: yes, can do; however, I just recently promoted a few because OO.o needs them; where's the bug?
[10:54] <slytherin> pitti: bug 176139
[10:54] <ubotu> Launchpad bug 176139 in libtoolbar-java "Please move package to universe" [Wishlist,Confirmed] https://launchpad.net/bugs/176139
[10:56] <pitti> slytherin: ah, from multiverse to universe; that's fine
[10:56] <pitti> slytherin: will get to it in a minute
[10:57] <soren> What's the story about all the different db4.x? I remember we were trying to get rid of one or more of them from main..
[10:57] <slytherin> pitti: Thanks. :-)
[10:57] <pitti> soren: right; if you happen to upload something that can be moved to 4.6 (libdb-dev), please do
[10:57] <pitti> that will cut down the mass-rebuilds later
[10:59] <soren> pitti: I figured as much. I wonder why apache is still built against db4.4..
[10:59] <pitti> soren: not sure; packages which use on-disk transactions are a PITA to migrate, but apache doesn't sound like something that would use them
[11:00] <soren> pitti: Not transactions, no. Rewrite rules.
[11:00] <soren> pitti: ...and they are even worse, as they can be scattered all over the place.
[11:00] <pitti> soren: anyway, if grep -r DB_TXN doesn't bring up anything, then it's safe to move
[11:01] <pitti> (that's a sufficient, but not necessary condition, BTW)
[11:01] <soren> pitti: Oh, apart from transactions, the binary formats are compatible?
[11:01] <pitti> soren: yes; the API might have changed slightly, but most packages I stumbled across just build fine with any version
[11:02] <soren> pitti: Oh, it *builds* fine, I think. The thing I'm worried about are the existing databases of rewrite rules people might have  suddenly stop working.
[11:02] <pitti> soren: the db format itself didn't change, just the transaction log
[11:03] <soren> pitti: Ah, cool. Thanks.
[11:04] <soren> Mithrandir: Can you think of any particular reason why apache must be built against db4.4 ?
[11:05] <thom> has svn changed?
[11:05] <thom> that's always the problem child for apache
[11:06] <soren> thom: Ah..
[11:06] <soren> thom: Not that I know of.
[11:08] <thom> well, that's the one. apr and svn and apache2 need to be in lockstep
[11:08] <soren> Sure. And php, too (which was what I was actually looking at).
[11:08] <thom> otherwise there is wailing and gnashing of teeth
[11:09] <pitti> so we can change them all at the same time?
[11:17] <soren> pitti: I have no clue what would be required to make subversion work with db4.6.
[11:18] <thom> soren: well, it rather depends what the upgrade path is for a db4.4 db to a db4.6 db
[11:18] <soren> pitti: ...but yes, upgrading the all at the same time is the (only) way to go, I believe.
[11:19] <soren> thom: Well, according to pitti, it's only the transaction log that changed, so we'd need to rebuild against db4.6 and make sure that anything that's using libsvn is restarted, otherwise we're in trouble, I suspect.
[11:20] <thom> then rebuilding should be fine, since apache restart will get mod_svn and i assume that the subversion package will restart any long running svnserve processes
[11:21] <thom> check that though
[11:22] <sivang> slomo !
[11:22] <slomo> hi sivang
[11:23] <pitti> hey slomo, how are you?
[11:24] <slomo> pitti: i'm fine, thanks :) and you? :)
[11:25] <pitti> bit stressed, but good (need to find some christmas presents still, though)
[11:25]  * soren decides not to change subversion, apache2, *and* php5 to a new db4.x version on the last day before holiday.
[11:26] <siretart> slomo && sivang ! :)
[11:26] <siretart> slomo: did you have the chance to look at ffmpeg from experimental yet again?
[11:27] <soc> hi
[11:27] <slomo> siretart: works good for me :)
[11:27] <soren> What happened to the alpha, by the way?
[11:28] <soc> does someone know the plans for ati gpus in 8.04?
[11:28] <soc> which driver will be used as a default?
[11:28] <StevenK> pitti: If you have a sec, I want to discuss the gimp SRU. The one I uploaded FTBFS, what is the next step, aside from test building more. :-(
[11:28] <soc> and will the fglrx version in the repos be updated?
[11:28] <slomo> siretart: imho can go to unstable
[11:28] <soc> because 7.11 contains a nasty meory-leak
[11:28] <siretart> slomo: I have rebuilt the archive against the new ffmpeg, but didn't do larger tests yet
[11:28] <siretart> slomo: did you try it on ppc as well?
[11:29] <pitti> StevenK: just upload a fix
[11:29] <slomo> siretart: nope, only x86... and i didn't do larger tests yet but only "used" it :)
[11:29] <siretart> I think sam wants to have another look at the altivec patches before letting it into unstable
[11:29] <thom> soren: heh, seems sensible
[11:29] <siretart> slomo: how do you feel pushing it to hardy?
[11:30] <StevenK> pitti: Suggest for version number, since I seem to loose at picking them.
[11:30] <pitti> StevenK: ...7.10.1?
[11:30] <pitti> 7.11 would be bad :)
[11:31] <slomo> siretart: well, get it into unstable and sync :)
[11:31] <StevenK> Heh, yes
[11:31] <StevenK> pitti: 7.11 is what dch did by default :-)
[11:32] <siretart> slomo: I fear that this will take some more time, and won't make it before hardy freeze
[11:32] <siretart> having it tested in hardy would help here, otoh
[11:34] <siretart> slomo: how about this: we modify mplayer to use its internal ffmpeg, and build a shared ffmpeg library from it, and link the world against that?
[11:34] <slomo> siretart: then better get the experimental ffmpeg to hardy
[11:34] <slomo> siretart: it's from the same day anyway, no? :)
[11:35] <siretart> slomo: exactly for this reason. the 'build ffmpeg from mplayer' approach would leave us with 2 versions of ffmpeg and additional flexibility
[11:35] <slomo> i don't see any advantage in this... but if you think it's better... :)
[11:36] <slomo> bbl
[11:36] <siretart> slomo: wait a sek!
[11:36] <siretart> hm. too late
[11:49] <geser> pitti: have you an idea how an .orig.tar.gz can vanish during build? http://launchpadlibrarian.net/10082300/buildlog_ubuntu-hardy-i386.mush_7.2.5unoff2-25_FAILEDTOBUILD.txt.gz
[11:50] <geser> it builds fine in a hardy pbuilder so perhaps a give-back should be tried
[11:51] <cjwatson> that looks like the package is assuming that its .orig.tar.gz is present in .., which isn't necessarily true on a buildd
[11:51] <cjwatson> I think that's a bug in the package, and it's going to have to find some other way to do the same thing
[11:52] <pitti> whoa, how strange
[11:52] <cjwatson> perhaps using pristine-tar to regenerate the .orig.tar.gz?
[11:52] <zul> hello
[11:52] <pitti> but how can this happen in dpkg-deb?
[11:53] <cjwatson> it's not
[11:53] <cjwatson> read mush/debian/rules
[11:53] <pitti> ah, ok
[11:53] <cjwatson> dpkg-deb is just the previous thing that's done
[11:55] <geser> cjwatson: thanks for the explanation
[11:55] <StevenK> pitti: gimp uploaded, please accept at your leisure.
[12:14] <geser> pitti: as build-depending on sun-java[56]-* seems to work now, please give-back: lucene2 libglazedlists-java jbidwatcher javassist glassfish. Thanks
[12:14] <pitti> geser: \o/ done
[12:16] <Fujitsu> geser: ooh, how'd you manage that?
[12:16] <geser> Fujitsu: infinity did some black magic on the buildds
[12:17] <pitti> Fujitsu: debconf preseeding for the license question
[12:17] <Fujitsu> Ahh.
[12:18] <Fujitsu> I think batik wants that too.
[12:18] <Fujitsu> (giving back, that is. It b-d on some JRE)
[12:18] <slytherin> geser: How is it working?
[12:19] <slytherin> geser: I mean build-depends on sun-jdk?
[12:20] <geser> Fujitsu: I don't think j2sdk1.4 uses the same debconf question
[12:20] <geser> slytherin: if it builds with the sun-java packages updating the build-depends should allow it to get build on the buildds
[12:22] <slytherin> I think then batik build can be fixed. But I will be very much interested to have batik 1.7 when it releases as it compiles with GCJ. :-)
[12:22] <geser> slytherin: any date known for the new release?
[12:23] <slytherin> nope
[12:28] <pitti> tjaalton: hm, xserver-xorg-driver-all wants to go to universe; was this dependency deliberately dropped?
[12:29] <pitti> oh, it's called -video-all nwo
[12:29] <tjaalton> pitti: no that's a new transitional package
[12:29] <pitti> so we should seed it for dapper upgrades
[12:29] <tjaalton> requested by mvo
[12:29] <pitti> ok, seeding; thanks
[12:30] <mvo> pitti: having it in main helps dapper->hardy upgrades
[12:30] <mvo> (and having it at all :)
[12:30] <mvo> thanks pitti (and tjaalton for adding it!)
[12:32] <pitti> committed
[12:33] <jpatrick> hmm, could someone tell me why I've just gotten a "Accepted: pulseaudio 0.9.6-1ubuntu2~feisty1 (source)"?
[12:33] <pitti> jpatrick: because you or someone else from the backporters team requested a feisty backport
[12:33] <jpatrick> ah, ok
[12:36] <pitti> ArneGoetje: FYI, fontforge is depwaiting on libspiro-dev; that needs a MIR, or we demote fontforge to universe (which might be adequate)
[12:39] <stgraber> slangasek: You can rename builds on the tracker (through the milestone management page), the download info page is to be completely reworked as soon as we have a .manifest file on cdimage (parsing the cdimage isn't a good idea at all :))
[12:40] <stgraber> your last night problem was certainly some hardcoded gutsy in the cdimage parser, I'll have a look and get that fixed
[12:42] <stgraber> slangasek: it was indeed some hardcoded "gutsy", I changed them to hardy and it seems to work again
[12:49] <dholbach> MOTU Q&A session in 11 minutes in #ubuntu-classroom
[12:52] <cjwatson> dholbach: I think I'm off your sponsoring hitlist now
[12:53] <pitti> mjj29: ah, I saw your dbus-java commits, thanks
[12:53] <dholbach> cjwatson: I just noticed - thanks a lot for that, you ROCK!
[12:53] <dholbach> cjwatson: and thanks for your input in the MOTU Meeting
[12:54] <Keybuk> seb128: hmm, that was odd; xchat-gnome's lock ups were permanent this morning
[12:56] <seb128> Keybuk: did you try removing pulseaudio?
[12:56] <Keybuk> yes, that's how I got online :-)
[12:56] <Keybuk> oddly enough, this seems to have also made flash sounds work again -- I'm not sure that this is a good thing
[12:59] <seb128> I'm wondering why xchat-gnome hangs when pulseaudio is used though
[13:06] <ogra> Keybuk, you likely need libflashsupport for flash sound with pulse (not sure if tahts also needed for non networked pulse sound though, we need it in ltsp since we use pulse there)
[13:07] <Keybuk> ogra: is that packaged?
[13:07]  * ogra wonders why the binary wasnt built yet ... it was accepted a while ago
[13:07] <ogra> Keybuk, yes, but no binary it seems
[13:10] <jpatrick> pitti: is it normal that that backport should be marked as uploaded by me?
[13:11] <ogra> Keybuk, https://launchpad.net/ubuntu/hardy/+source/libflashsupport/1.9-0ubuntu1
[13:12] <Keybuk> jpatrick: if you requested it, yes
[13:12] <jpatrick> Keybuk: I did not. Nor have I ever touched pulseadio
[13:12] <jpatrick> pulseaudio*
[13:13] <seb128> did you approve the request?
[13:13] <jpatrick> No
[13:13] <seb128> what upload do you speak about?
[13:13] <jpatrick>  pulseaudio 0.9.6-1ubuntu2~feisty1
[13:14] <seb128> no idea about this one, when did you get a mail about the upload?
[13:15] <cjwatson> sounds like somebody made a mistake when doing the backport
[13:15] <cjwatson> it's a manual process ...
[13:15] <dholbach> can somebody give me a debian policy reference to why things like        #!/usr/bin/env python          are discouraged?
[13:15] <jpatrick> yes, I did get a mail about it
[13:16] <dholbach> we're just discussing it in #ubuntu-classroom (MOTU Q&A session)
[13:16] <dholbach> http://www.debian.org/doc/packaging-manuals/python-policy/ch-python.html  comes close to the topic
[13:17] <seb128> dholbach: the page seems to have all the required informations
[13:18] <dholbach> ok... so do you know of a "standard list of interpreters"?
[13:18] <persia> seb128: What about non-python use of env?  Is there a general policy, or is it interpreter-specific for python?
[13:19] <seb128> persia: similar situation I would say
[13:19] <persia> seb128: makes sense.  Thanks.
[13:19] <seb128> when using env you are not sure the system version of the interpreter is used
[13:20] <seb128> you are welcome
[13:21] <ogra> ogra@ceron:~/devel/livecd-rootfs/trunk$ grep sanitize livecd.sh
[13:21] <ogra>     I)	UINUM=$(sanitize int "$OPTARG");;
[13:21] <ogra>     m)	OPTMIRROR=$(sanitize url "$OPTARG");;
[13:21] <ogra>     S)	USZ=$(sanitize int "$OPTARG");;
[13:21] <ogra> does anyone have a clue what sanitize is ?
[13:22] <ogra> its no internal function in the script and not sourced anywhere
[13:22] <ogra> (so using -m breaks)
[13:32] <Chipzz> seb128: I'ld say that page does not have all the required information
[13:33] <Chipzz> dholbach: using /usr/bin/env has a big drawback as opposed to just specifying the path (which IMHO you should)
[13:33] <dholbach> Chipzz: thanks we clarified it in the meantime
[13:33] <Chipzz> dholbach: using /usr/bin/env makes it impossible to specify command-line arguments or switches to python (or perl) for example
[13:34] <Chipzz> dholbach: I was not finnished yet ;)
[13:34] <Chipzz> now I am ;)
[13:35] <Robot101> so are there metacity bling packages yet? :)
[13:35] <dholbach> thanks Chipzz
[13:36] <seb128> Robot101: they are called compiz ;-)
[13:37] <Chipzz> dholbach: a simple example in the perl case is #!/usr/bin/perl -w (although you can also do that with use warnings)
[13:37] <seb128> Robot101: otherwise the new version is not uploaded yet but will be likely today
[13:38] <seb128> I'm working on glib and gvfs now though
[13:39] <^sa^> hello. i have some problems about the configuration of my wifi
[13:39] <Chipzz> persia: ^^^ in case your interested (and non-python use of env should be discouraged IMHO)
[13:39] <^sa^> (first of all sorry for my bad english :P i'm italian)
[13:39] <Chipzz> s/your/you're/
[13:39] <Robot101> seb128: I want a window manager, not compiz. :P
[13:40] <persia> Chipzz: Yes.  I saw it.  I'm not a fan of env, more curious about things like #!/usr/bin/make in a script in /usr/bin/
[13:40] <^sa^> the problem is that my wlan works perfectly on the live cd but not on the installed ubuntu
[13:40] <Chipzz> persia: make requires -f :)
[13:40] <jdstrand> ^sa^: no problems with your english, but this is not the right channel.  you'll get more help on #ubuntu
[13:41] <Chipzz> persia: so far make it's impossible to use env in the first place :)
[13:41] <Chipzz> s/far/for/
[13:41] <^sa^> i've gone in ubuntu-it and they couldn't help
[13:41] <^sa^> we tryed almost everything
[13:41] <^sa^> so i supposed it's a bug and i come here to report it
[13:42] <jdstrand> ^sa^: https://bugs.launchpad.net/
[13:42] <cjwatson> ogra: introduced in r29; ask lamont what he was thinking? :)
[13:42] <^sa^> or maybe you have a soluction
[13:42] <^sa^> what can i do?
[13:42] <Chipzz> ^sa^: although this is not a bug report channel, you could ping asac; he may be able to help?
[13:42] <Chipzz> (hopes he won't get asac's wrath over him now :P)
[13:43] <^sa^> ok but i dont know what to write. can't you help me?
[13:43] <Chipzz> no I cannot ;P
[13:43] <^sa^> what should i post in the website?
[13:43] <Chipzz> I'm not an expert wrt wireless drivers
[13:43] <cjwatson> Chipzz: he's on holiday
[13:43] <jdstrand> me either :(
[13:44] <Chipzz> cjwatson: ah, I wanted to ask you about something :)
[13:44] <lamont> cjwatson: context?
[13:44] <lamont> ah.  livecd
[13:45] <Chipzz> cjwatson: wrt to the bug about ubiquity window being to big to fit on small screens (since you're mentoring that bug); what do you think about the recent GTK+ patches wrt natural size as a solution to that bug?
[13:45] <jdstrand> ^sa^: you may find some answers in the link I gave.  If not, report the bug.
[13:45]  * persia is suspicious of "Natural size", having a 200DPI display on one device.
[13:45] <cjwatson> Chipzz: that should go to evand nowadays. It may help, certainly, but I haven't looked at them in any detail; the timezone page will still need to be shrunk I expect
[13:46] <cjwatson> persia: I don't think that's what it means ...?
[13:46] <cjwatson> it's about pixel-level sizing of widgets, not much to do with DPI
[13:46] <Chipzz> persia: it's about widgets not taking up the maximum space they could possess
[13:47] <persia> cjwatson: Ah.  I misunderstood "natural" then.  I feared real-world measurement, which is annoying for handhelds.  Thanks for the clarification.
[13:49] <lamont> cjwatson: no clue on sanitize.
[13:50] <Chipzz> persia: the relevant discussion is at http://mail.gnome.org/archives/gtk-devel-list/2007-November/msg00145.html in case you're interested
[13:51] <persia> Chipzz: Thanks.  That's much clearer than the API docs I was reading :)
[13:51] <Chipzz> cjwatson: anyway, you may want to add a comment on that bug (https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/38442) in case you're not mentoring it anymore? ;)
[13:51] <ubotu> Launchpad bug 38442 in ubiquity "Ubiquity dialogues too large for 800x600 display" [High,Confirmed]
[13:53] <Chipzz> cjwatson: anyway, I added a comment to the bug with a link to the relevant discussion on gtk-devel ;)
[13:54] <Chipzz> (that's a lot of anyways :P)
[14:09] <ion_> The newest fontconfig seems to have a problem with lcdfilter being set as legacy in config.
[14:10] <ion_> Ah, the syntax has changed to lcd_filter=lcdfilterlegacy.
[14:17] <Ubulette> ion_, yes, you need the new libcairo to go with it
[14:19] <seb128> ion_: do you get any error on ugprade or something?
[14:21] <ion_> seb128: Yes, about a config file i created.
[14:22] <seb128> ion_: does that break the update?
[14:22] <ion_> seb128: Nope, they were just warnings.
[14:23] <seb128> ok, so that's alright
[14:23] <ion_> Whatever updated fontconfig caches was printing them.
[14:23] <ion_> Yeah
[14:25] <geser> pitti: please give-back: sleepd wmbattery python-xlib qbankmanager pnscan pmx pica ounit mrwtoppm. Thanks
[14:36] <Mithrandir> soren: db4.4 for apache> svn?
[14:36] <soren> Mithrandir: Yes, thom filled in the blanks.
[14:36] <soren> Mithrandir: Thanks, though.
[14:38] <slytherin> pitti: ping
[14:43] <seb128> slytherin: you should give some context so maybe somebody else can reply
[14:44] <slytherin> As just asked the question on MOTU channel. It has more do to with moving a -doc package from multiverse to universe.
[14:52] <tkamppeter> Anyone can help me on a problem with a a package which we auto-sync from Debian?
[14:52] <persia> tkamppeter: Which package?
[14:52] <tkamppeter> It is about bug 177359, python-cups
[14:52] <ubotu> Launchpad bug 177359 in python-cups "python-cups needs update (system-config-printer.py crashed with SIGSEGV in PyObject_Malloc())" [Medium,Triaged] https://launchpad.net/bugs/177359
[14:53] <tkamppeter> Tim Waugh, upstream author of python-cups and system-config-printer has fixed this bug upstream in python-cups.
[14:55] <persia> tkamppeter: Three choices: 1) backport the changes (likely wasted effort). 2) Work with debian for an update, and request a sync (freeze exception).  3) update the package directly, and make sure Debian uses the same orig.tar.gz.
[14:55] <persia> tkamppeter: Depending on your relationship with the Debian maintainer, one of 2) or 3) is likely easiest.
[15:00] <tkamppeter> persia thanks, Otavio Salvador has offered me collaboration on system-config-printer (git write access at alioth). So I will option 3 and I think he will overtake it (is a straight upstream update, no patches, no changes in debian/).
[15:00] <persia> tkamppeter: Excellent :)
[15:02] <tkamppeter> persia, package is already build, was trivial
[15:02]  * persia blesses upstreams that prepare releases for painless updates
[15:03] <tkamppeter> Haver pitti and doko already left for Christmas?
[15:04] <pitti> re
[15:04] <pitti> was at a phone call
[15:04] <pitti> give me some more minutes to write down my brain status, then I'll catchup
[15:05] <pitti> geser: done
[15:05] <tkamppeter> hi pitt, can you upload some packages into main for me today? python-cups and system-config-printer?
[15:05] <pitti> hm, slytherin left already
[15:05] <pitti> tkamppeter: can you please mail me the URL? I'll try to make it (sorry, still 100 things to get done)
[15:06] <tkamppeter> pitti, I will do so.
[15:06] <persia> pitti: slytherin is investigating, and filed a bug about the multiverse -> universe bit.
[15:14] <tkamppeter_> pitti, python-cups is ready now, biff.
[15:16] <seb128> pitti: did you do something to esd?
[15:25] <pitti> persia: ok, thanks
[15:26] <pitti> seb128: define something? (no, not recently, except for demoting it)
[15:27] <seb128> pitti: I was trying to pbuild the new rhythmbox but libgnome is not installable because it depends on libesd0 or libesd0-alsa which are not available
[15:27] <seb128> pitti: you demoted those then, which explains the issue
[15:27] <pochu> seb128: rhythmbox is mine! :P
[15:27] <pochu> seb128: are you doing it?
[15:27] <pitti> argh, I meant to demote the esound *binary*
[15:27] <seb128> pochu: already uploaded
[15:28] <seb128> pochu: sorry
[15:28] <pochu> heh
[15:28] <pitti> seb128: sorry, fixing
[15:28] <pochu> seb128: no worries, I didn't start it yet ;)
[15:28] <pitti> done
[15:28] <seb128> pitti: danke
[15:29] <seb128> pochu: usually I would have updated the wiki but I wanted that to be done before my holidays
[15:30] <pochu> seb128: do you start them today?
[15:33] <seb128> pochu: yes, after work
[15:34] <seb128> pochu: I expect I'll still be reading mails etc during holidays though
[15:34] <pochu> Merry Christmas then ;-)
[15:38] <geser> pitti: could you also move commons-httpclient from multiverse to universe (a new task in bug #176139) (one binary is already in universe)
[15:39] <seb128> pochu: thanks, to you too ;-)
[15:40] <pitti> geser: done
[15:43] <tkamppeter_> pitti. system-config-printer is now prepared for a crash-free Christmas (4 crashers fixed + 1 in python-cups), see your mail.
[15:43] <pitti> cool :)
[15:43] <pitti> so people can print out all their greeting cards and present labels :)
[15:44] <tkamppeter> Yes, and they can set up their printers which they get as present (at least if the person who has given the present has read OpenPrinting's Christmas list before).
[15:55] <pitti> if they are using hardy anyway
[15:55] <pitti> oh, gone again already
[15:56] <keescook> mjg59: congratz on the phd submission.  :)
[15:56] <mjg59> Thanks!
[16:08] <bigon> is that normal that libc6-amd64 package in installed on my 32bit system?
[16:12] <geser> bigon: I've seen it in my i386 installations too
[16:13] <pitti> bigon: no, that's a bug
[16:13] <bigon> ok
[16:23] <pitti> keescook: do you happen to have an opinion about http://launchpadlibrarian.net/10983343/php5_5.2.3-1ubuntu6.3.dsc.diff ?
[16:23] <pitti> keescook: that's a proposed SRU for php in gutsy, to switch from db4.5 to db4.4
[16:24] <pitti> keescook: that would be in sync with libsvn1 (also 4.4 in gutsy), but I'm a bit nervous about doing that to a stable release
[16:26] <pitti> well, it was always *meant* to link against 4.4 at least
[16:43] <keescook> pitti: well, I've seen a number of db4 issues in php5 that I haven't figured out yet
[16:43] <keescook> pitti: if that solves the crashes that I can't reproduce, then I'm all for it.  ;)
[16:45] <keescook> pitti: I have concerns over php applications that used db4.5  (mediawiki?) but again, I haven't been able to reproduce the issues (173817)
[16:46] <pitti> keescook: sounds like another damned if you do/damned if you don't issue
[16:46] <pitti> (and just reinforces my desire to get rid of the duplication in hardy)
[16:51]  * keescook nods
[17:44] <seb128> pitti: could you give a retry to rhythmbox on all arches? It failed due to the esound to universe
[17:46] <pitti> seb128: done
[17:46] <seb128> pitti: danke
[18:02] <seb128> pitti: rhythmbox failed again the same way, are you sure you promoted libesd*?
[18:02] <pitti> yes, I am
[18:02] <seb128> hum
[18:02] <pitti> the second time I was sure that I used the right commands
[18:03] <pitti> libesd0-dev | 0.2.38-0ubuntu4 |         hardy | amd64, hppa, i386, ia64, lpia, powerpc, sparc
[18:03] <seb128> how long ago was that?
[18:03] <pitti> hm, esound is back in main
[18:03] <pitti> WTH?
[18:03] <pitti> seb128: publisher finished about 10 minutes ago
[18:03]  * pitti gives back again
[18:03] <seb128> ah ok
[18:03] <seb128> thanks
[18:03] <seb128> I though that was some hours ago already
[18:04] <pitti> so, if they all land in universe again now, we have a soyuz bug
[18:04] <pitti> I could have attributed the first failure to my wrecked brain today, but not the second one
[18:13] <dholbach> Merry Christmas and all the best in 2008 to everybody!  Thank you!
[19:24] <shaya> wondering if anyone is working on integrating new fglrx drivers into lrm, impt as they now work on firegl cards (think thinkpads)
[19:30] <sladen> shaya: look at the change logs of the relevant package and find out who has worked on it recently
[19:30] <sladen> shaya: then you can ask them directly
[19:31] <shaya> BenC: you here? :)
[19:31] <BenC> shaya: hardy has latest ati drivers, IIRC
[19:34] <shaya> new ones came out yesterday
[19:34] <shaya> latest package is 12/19
[19:35] <shaya> http://ati.amd.com/support/drivers/linux/linux-firegl.html
[19:38] <BenC> shaya: will be after new year most likely
[19:38] <shaya> ok
[23:09] <TheMuso> slangasek: Thanks a bunch for 1) making ubuntustudio alpha images, and 2) announcing them in the main alpha 2 announcement.
[23:12] <slangasek> TheMuso: my pleasure; unfortunately I don't believe we got any ISO tests of them prior to release, which makes me nervous.  going forward, aside from getting images into a testable state farther in advance, what's the best way to tap you guys about getting them tested before release?
[23:13] <slangasek> TheMuso: (also: would you care to test them now to confirm that it really boots? :/)
[23:13] <TheMuso> slangasek: Well there are a few of us who are testing the dailies regularly, and I've been making sure our seeds are up to date, and we have no uninstallable packages leading up to alpha2, so if the installer gets tested elsewhere, and same with GNOME, that covers us for the most part.
[23:14] <TheMuso> slangasek: I don't have long till I have to get ready to head out, but I'll sync and see if they do boot and install, but I'm reasonably confident that they will be ok.
[23:14] <TheMuso> We are trying to get more community help for testing, but some people in our dev group haven't really bene pulling their weight.
[23:15] <slangasek> TheMuso: right, sounds good
[23:16] <slangasek> TheMuso: in terms of release management and release confidence, if people are testing dailies it would be good to have the results documented on https://iso.qa.stgraber.org; which means it would also be good if I have a designated point of contact that I can notify when candidates are published there
[23:16] <TheMuso> slangasek: And as it is, -rt didn't land for alpha 2 for us, so kernel wise, theres nothing to test, but once -rt lands for later alphas, then we really need to be sure we get good testing, particularly with apps that need such a kernel.
[23:16] <slangasek> sure
[23:16] <TheMuso> slangasek: Right.
[23:16] <TheMuso> -rt as in for 2.6.24
[23:16] <slangasek> yes
[23:17] <slangasek> I know -rt, it caused us some problems during the milestone prep :)
[23:17] <TheMuso> I saw that.
[23:18] <TheMuso> slangasek: As it seems you and I tend to be around at similar times, I am happy to be pinged aobut candidate images in the future. Even if I'm not around, I am idling on IRC< so will get the ping, and test at my earliest convenience.
[23:18] <slangasek> ok
[23:19] <TheMuso> I try at least once a day to check the state of our images, usually right after the latest gets built.
[23:19] <slangasek> right - in the case of a milestone, the time when it gets built becomes variable :-)
[23:19] <TheMuso> I am aware of that.
[23:20] <TheMuso> So around alpha times, I do tend to check more often where possible.
[23:20]  * slangasek nods
[23:30]  * TheMuso kicks off a test install of ubuntustudio, and goes to get ready.
[23:45] <tjaalton> slangasek: hmm, bug 173008 (mentioned on the relnotes) should be fixed now
[23:45] <ubotu> Launchpad bug 173008 in xorg "keyboard selection (dvorak) not preserved after install in hardy" [Medium,Confirmed] https://launchpad.net/bugs/173008
[23:46] <tjaalton> sorry for not closing it in time