[00:10] <emgent`nl> heya
[00:10] <kirkland> slangasek: ping
[00:12] <slangasek> kirkland: moo
[00:13] <kirkland> slangasek: hiya, i have a small grub-installer patch that I'd really, really like to see on the next iso's...
[00:13] <kirkland> slangasek: http://people.ubuntu.com/~kirkland/grub-installer/grub-installer.debdiff
[00:14] <kirkland> slangasek: seeing as the freeze and all, i thought i might bump your direction
[00:14] <slangasek> kirkland: well, currently the "next isos" are slated to be the ones /after/ alpha-5
[00:14] <kirkland> slangasek: oh...  are we under a freeze right now?
[00:14] <slangasek> kirkland: no bug number; can you explain here what's broken?
[00:14] <slangasek> kirkland: yes, alpha-5 tomorrow
[00:16] <kirkland> slangasek: refresh http://people.ubuntu.com/~kirkland/grub-installer/grub-installer.debdiff
[00:16] <kirkland> slangasek: bug number inserted
[00:16] <kirkland> slangasek: the grub install multiple MBRs to a RAID mirror is not working as designed, because my previous patch was calling findfs()
[00:16] <kirkland> slangasek: that finds the filesystem, not the device
[00:17] <slangasek> ah
[00:17] <kirkland> slangasek: what i needed to call was mapdevfs()
[00:17] <slangasek> by "filesystem", I guess you mean "mount point"?
[00:17] <kirkland> slangasek: right, misread on my part by what those functions did
[00:17] <slangasek> ok
[00:17] <kirkland> slangasek: turns out the determination i need is actually already done further up in the code
[00:17] <slangasek> if we aren't yet advertising this as a feature of alpha-5, I think it's better to hold it until after tomorrow
[00:17] <kirkland> slangasek: bootfs_nodevfs=$(mapdevfs $bootfs)
[00:18] <slangasek> but I'm happy to upload it then
[00:18] <kirkland> slangasek: okay
[00:18] <kirkland> slangasek: it will make it into the next daily iso build in that case?
[00:18] <slangasek> yes
[00:18] <kirkland> slangasek: I don't particularly care where it's in alphaX ...  just that i get an iso soon with the updated udeb that I can test
[00:18] <slangasek> can you post the debdiff to the bug, and subscribe me?
[00:19] <kirkland> slangasek: sure, i'll do the bzr branch monkey business too
[00:19] <slangasek> even better :)
[00:23] <kirkland> slangasek: or perhaps not...  bzr is not responding atm, something about an upgrade, perhaps
[00:49] <ericholscher> when is the package freeze for 8.10?
[00:53] <slangasek> ericholscher: there's no freeze that we refer to as a "package freeze"; we're currently in Feature Freeze, meaning that package changes for introducing new features, instead of for fixing bugs, need to be approved
[00:53] <Spets> https://wiki.ubuntu.com/IntrepidReleaseSchedule
[00:53] <ericholscher> okay
[00:54] <slangasek> ericholscher: django 1.0 is on my radar, fwiw
[00:54] <ericholscher> ojay ;)
[00:54] <ericholscher> okay*
[00:55] <ericholscher> thanks much for reading my mind :)
[00:55] <slangasek> well, your channel list, but ok ;)
[00:56] <slangasek> (plus, people coming into the channel within an hour of the django 1.0 release and asking about freezes makes it easy to guess, don't it?)
[00:58] <lool> haha
[00:58] <lool> slangasek: Heh can i get Chrome in intrepid?
[00:58] <jcristau> slangasek: pfft. you mean within an hour of the xserver 1.5 release.
[00:58] <slangasek> lool: twitch
[00:59] <slangasek> jcristau: is there anyone I don't know by name who would be asking for an xserver 1.5 freeze exception? :
[00:59] <slangasek> )
[00:59] <jcristau> slangasek: ok, probably not
[03:16] <ScottK> slangasek: There's already a bug open asking motu-release for an FFe for django 1.0.  My response up until now has been wait until it's released.
[04:20] <slangasek> ScottK: yep, saw it :)
[05:07] <slangasek> ScottK: a python-django freeze exception has already been requested for lenny, on the Debian side, so it should be available pretty soon...
[05:08] <ScottK> slangasek: Trunk in the DPMT svn has already been at least partially updated.
[05:21]  * NCommander needs to request a freeze exception for swfdec so we can get a new upstream version in
[05:22] <RAOF> NCommander: Did'nt I see 0.7.4 in intrepid-changes this morning?
[05:23] <NCommander> Oh, it might have just gotten updated
[05:23] <NCommander> I didn't check yet
[05:23] <NCommander> (I just noted that there was a new upstream out, I didn't see if it was packaged yet)
[05:59] <wgrant> Hmmm. Did something change with font antialiasing over the past 24 hours or so.
[06:00] <RAOF> I think it might have, yes.  And for the worse.
[06:08] <philwyett> wgrant: Text in dialog boxes, specifically file text?
[06:11] <wgrant> philwyett: Specifically every bit of text.
[06:11] <philwyett> wgrant: Not got that many issues text issues.
[06:12] <wgrant> Firefox and Thunderbird are almost painful to look at.
[06:12] <philwyett> nvidia driver and display configuration is broken. However I am going to do an Alpha 5 install before reporting up to 20 bugs. :-/
[06:14] <RAOF> I think this might be different between the nouveau/nvidia cases.
[06:19] <philwyett> I am on nv and have one set of issues. Installing nvidia 177 driver an doing 2 reboots to get it to activate, I then have a whole set of new issues. :-D
[06:20] <philwyett> Installing the nvidia driver on one box this morning did not call for reboot as it should :-/
[06:21] <RAOF> Why should it call for a reboot?
[06:22] <philwyett> Install requires requires a a reload of X and it is done via reboot thrugh the restricted drivers desktop app. Or always has done before now. :-)
[06:23] <philwyett> -requires
[06:23] <RAOF> Just logging out is sufficient ;)
[06:23] <philwyett> I know this.
[06:23] <RAOF> Or, at least, should be now.
[06:24] <philwyett> But the app doesn't even tell you that!
[06:27] <philwyett> Doing the updates this morning. After I decided quick reboot as two X components had been updated (just be cautious). Going for a reboot just restarted X the first time. This is why I am waiting for Alpha 5 and do a fresh install and look at the cases I have collected before reporting things and creating bugmail.
[07:11] <pitti> Good morning
[07:47] <_Genius_> quiero colaborar con el proyecto ubuntu
[07:47] <_Genius_> programo en C/C++
[07:47] <_Genius_> help
[07:48] <_Genius_> :(
[07:49] <lifeless> _Genius_: check the topic:
[07:49] <lifeless>  Development of Ubuntu (not support, not application development on Ubuntu)
[07:57] <dholbach> good morning
[07:57] <persia> _Genius_: Also, you may find that https://wiki.ubuntu.com/ContributeToUbuntu answers most of your questions, and that the rest are better asked in English in #ubuntu-motu
[08:00] <NCommander> persia, as an aside, did the TB (or was it MC) determine if the AGPL is free or non-free?
[08:01] <persia> NCommander: Generally license freeness falls to the archive-admins, although it might be escalated to the TB in questionable cases.
[08:01] <persia> I've not heard of any determination in one way or the other for AGPL
[08:02] <NCommander> persia, I heard it went to the TB, obviously they can't come to a conclusion
[08:02] <persia> NCommander: I wouldn't come to that conclusion, but rather that if it went to the TB, it has yet to appear on the agenda for a TB meeting, and so may be in queue for deliberation.
[08:03] <NCommander> ah
[08:03]  * NCommander decides to blog
[08:06] <slangasek> is that last sentence in some way connected to the preceding ones?
[08:12] <cjwatson> I believe somebody did ask the TB before bothering to wait for a determination from ubuntu-archive, yes
[08:13] <mdke> fwiw, Mark and mdz have both expressed the view that it is free
[08:14] <persia> Raw foolishness and impatience.  Best to wait until there is an AGPL package uploaded, and see in which component it ends up in as the result of NEW.
[08:15] <mdke> the CC and TB were approached after the individual apparently discussed the issue with MOTU but couldn't get to a conclusion. He was obviously not told about that potential procedure
[08:15] <cjwatson> in the last shallow analysis I did, it looked like it was probably free but that there were some practical concerns and wording problems with the licence
[08:15] <mdke> or if he was, he skipped it :)
[08:15] <cjwatson> but that's not an Official Statement
[08:17] <mdke> well, Mark and mdz form a majority of the TB, so I suspect that's enough to decide the issue. But if people have concerns about the licence that are enough to warrant potential exclusion from main, then it's worth bringing them to the TB's attention
[08:19] <NCommander> cjwatson, so how are you doing tonight?
[08:22] <cjwatson> undercaffeinated
[08:25] <NCommander> cjwatson, sounds about right. I'm currently rebootstrapping Ubuntu from scratch
[08:25] <NCommander> (at some point, the insanity of it all will kick in)
[08:26] <pitti> ScottK: can you please seed clamav and spamassassin, so that they don't generate a lot of noise in component-mismatches? TIA
[08:29] <soren> pitti: Wow, they've been promoted already? Neat.
[08:29] <pitti> just finished the review, yes
[08:29] <pitti> it's really s/ScottK/server team/, so whoever feels like it, please go ahead
[08:30] <gnomefreak> anyone know if we added/removed support for "intex rtl8139D" nic from kernel?
[08:30] <mdke> cjwatson: I've copied ubuntu-archive into that agpl thread, so if you push my email through the moderation queue, they can chip in on it
[08:30] <cjwatson> meh, wonder why bug 264337 is happening
[08:30] <cjwatson> mdke: ok
[08:37] <pitti> bryce: please add screen-resolution-extra to the ubuntu desktop seed
[08:38] <pitti> bryce: or make it a dependency of something adequate, whatever is more suitable
[08:39] <bryce> pitti, I don't actually know how to add stuff to a seed, but I can add it as a dependency
[08:39] <pitti> bryce: well, I can help yuo with the seeding; but let's first discuss which is better
[08:39] <pitti> bryce: which package shuold depend on it?
[08:39] <bryce> gnome-control-center.
[08:40] <pitti> I guess it isn't called from the menus, but from the xrandr capplet?
[08:40] <pitti> right
[08:40] <pitti> that makes sense then
[08:40] <bryce> correct; I've already uploaded the patch that calls the s-r-e script if it exists
[08:40] <soren> cjwatson: Would I be abusing germinate's blacklisting functionality if I just want to add all the binaries from a single source package bar a single one? "%clamav + !clamav-milter" looks a lot nicer than listing the 9 "good" packages from clamav.
[08:45] <slangasek> soren: I immediately have to wonder why blacklisting anything is required, instead of just seeding clamav-milter
[08:45] <pitti> soren: you certainly shouldn't explicitly seed its dependencies
[08:46] <pitti> soren: i. e. you should never seed something like libclam4
[08:46] <slangasek> oh, that's to blacklist clamav-milter?
[08:46]  * slangasek stands on his head
[08:46] <seb128> pitti: hum, apport is buggy apparently, it doesn't tag crasher for retracing
[08:46]  * NCommander takes pictures of slangasek on his head
[08:46] <NCommander> good morning slangasek
[08:46] <pitti> soren: seeding clamav will pull in libclamav, clamav-freshclam, etc.
[08:46] <NCommander> how goes it?
[08:47] <seb128> pitti: see bug #264301 bug #264360 bug #264362
[08:47] <pitti> seb128: ugh
[08:47] <slangasek> NCommander: well enough, though I'm led to suspect that you're deliberately using timezone-inappropriate greetings
[08:47] <seb128> pitti: they are nowhere in the retracer logs so I think they didn't get tagged at all
[08:47] <seb128> hey NCommander
[08:47] <NCommander> slangasek, I just don't support i18n natively yet
[08:48] <NCommander> hola seb128
[08:48] <seb128> pitti: should I manually tag those or do you want to have a look first?
[08:48] <pitti> seb128: I have a look first
[08:48] <pitti> seb128: it does have apport-crash, so in general tagging seems to work
[08:48] <NCommander> seb128, so how goes your $TIME_OF_DAY
[08:48] <seb128> NCommander: good, waking up and having coffee
[08:49] <seb128> pitti: that's worth noting that those are crashes in python applications, not sure if that makes a difference
[08:49] <NCommander> seb128, nice, I need to get some sleep, I've been rebuilding Ubuntu's base packages manually so I'm starting to loose my mind
[08:49] <seb128> lol
[08:49] <seb128> NCommander: 'night ;-)
[08:50] <seb128> NCommander: btw how is the gtkmm 2.13 update going? ;-)
[08:50] <NCommander> seb128, not yet, I still need to wait for my statically linked GCC to finish
[08:50] <NCommander> seb128, still waiting on pangomm ;-)
[08:50] <pitti> seb128: improbable, but possible, of course
[08:50] <seb128> NCommander: did you open the upstream bug about the license? and you have pangomm locally so nothing prevent you to work on the update so it can be uploaded when pangomm is accepted
[08:50] <NCommander> seb128, I have it locally, and let me file the bug first
[08:51] <NCommander> seb128, I've discovered the absolute "joy" of bootstrapping Ubuntu from scratch
[08:52] <pitti> seb128: oh, crap, I got it
[08:52] <pitti> PackageArchitecture: all
[08:52] <pitti> seb128: you were right
[08:52] <seb128> ah ;-)
[08:52] <seb128> pitti: I retag those and let you fix apport then, thanks ;-)
[08:52] <cjwatson> soren: err. just bear in mind that that means that *no* other seeds in the same collection will be allowed to include clamav-milter
[08:52] <pitti>         a = report.get('PackageArchitecture', report.get('Architecture'))
[08:52] <pitti>         if 'CoreDump' in report and a:
[08:52] <cjwatson> it's a very big hammer
[08:52] <pitti>             if a != 'all':
[08:52] <soren> pitti: *facepalm* Of course. You're absolutely right.
[08:53] <NCommander> seb128, I can't find the pangomm module in their bugzilla
[08:53] <seb128> pitti: any reason you special cased arch all there?
[08:53] <pitti> soren: however, what's so evil about -milter that you want to blacklist it?
[08:53] <pitti> seb128: bzr blame'ing
[08:53] <seb128> NCommander: http://bugzilla.gnome.org/enter_bug.cgi?product=pangomm, you already opened bugs on it
[08:53] <soren> pitti: ISTR ScottK saying something about leaving it out of main for some reason.
[08:53] <pitti>   * apport/crashdb_impl/launchpad.py: Check PackageArchitecture for 'all', to
[08:53] <pitti>     not set a retracer tag 'need-all-retrace'.
[08:54] <soren> pitti: Perhaps I should just leave this all to him.
[08:54] <pitti> seb128: ^
[08:54] <seb128> ah
[08:54] <pitti> soren: right, it shouldn't be in main, but that doesn't mean we have to blacklist it
[08:54] <seb128> pitti: should I open a bug so you can keep track of the issue?
[08:54] <pitti> soren: if we just seed clamav, the binary, then only the transitive dependencies will be pulled in
[08:54] <pitti> seb128: if you wish, but I'm fixing it right now
[08:54] <seb128> ok so no need
[08:55] <soren> pitti: That was sort of the question I was asking :) I wasn't sure of the severity of the blacklisting, but if we only just add clamav, everything should be fine.
[08:56] <NCommander> seb128, I can't find the file that's GPL specific
[08:56] <seb128> NCommander: look to your debian/copyright, you noted it
[08:56] <NCommander> I feel like I'm loosing my own mind :-)
[08:56] <seb128> NCommander: something tell me you are making no effort tonight ;-)
[08:57] <NCommander> seb128, No, plenty of effort, I'm pioneering a PIE aspect of Ubuntu
[08:57] <seb128> NCommander: too much effort maybe then ;-)
[08:57] <NCommander> seb128, http://bugzilla.gnome.org/show_bug.cgi?id=550789
[08:57] <seb128> NCommander: thanks
[08:58] <NCommander> seb128, no problem. kees has wanted to -fPIE the architecture for ages, but it requires a hell of a lot of work to be done, to the point that I felt rebootstrapping from scratch was the "easiest" way to go
[08:58] <NCommander> ^amd64
[09:00] <NCommander> seb128, now that its noted, can you approve pangomm through NEW on ubuntu :-)
[09:00] <seb128> NCommander: I'll sponsor the upload and ask somebody else to have a look, it's bad taste to approve it's own uploads ;-)
[09:01] <NCommander> I thought it was already uploaded O_o;
[09:03] <pitti> seb128: testing the fix now; please go ahead and retag
[09:03] <seb128> pitti: ok, thanks
[09:03] <seb128> NCommander: no this GPL thing stopped me
[09:03] <NCommander> seb128, so now that upstream been pinged, and the copyright file is good, no issues?
[09:04] <seb128> NCommander: it should be alright, I'll upload
[09:04] <NCommander> Sweet, my maintained packages count goes up :-)
[09:14] <slangasek> cody-somerville: do you know whether anyone's testing the xubuntu candidate images for alpha-5 yet?
[09:14] <directhex> pitti, thanks for sorting #262719
[09:15] <pitti> directhex: thanks for writing the MIR
[09:15] <cody-somerville> slangasek, I've poked in #xubuntu-devel
[09:15] <cody-somerville> I'll download and burn right now
[09:15] <slangasek> cool
[09:16] <pitti> seb128: yay, bug 264626
[09:16] <seb128> pitti: don't have access
[09:16] <pitti> seb128: ^ argh, sorry; well, it got the tag now
[09:16] <seb128> good ;-)
[09:16] <directhex> pitti, better news: i've been chatting with upstream and debian, and mono itself should be able to drop ubuntu patching post-intrepid
[09:17] <pitti> seb128: oh, the i386 screen has an open chroot login; were you going to work in it?
[09:17] <seb128> pitti: yes, I'm updating the i386 retracer and I'm looking on the amd64 why those retracing give broken stacktraces
[09:17] <pitti> seb128: the amd64 one, too (wget CoreDump.gz
[09:17] <pitti> seb128: ok, thanks, I won't mess with it then
[09:18] <NCommander> directhex, SCORE
[09:18] <pitti> directhex: rock
[09:18]  * NCommander hugs directhex
[09:19] <RAOF> directhex: No more crazy evolution-sharp-build-breaking livecd patches?  Woo!
[09:19] <directhex> RAOF, apparently that's already turned off in current intrepid packages
[09:20] <RAOF> I thought NCommander reworked it so that it wasn't so break-my-build crazy.
[09:20] <directhex> the only current diffs between what's in pkg-mono svn and ubuntu are the arg_max bug (changed upstream, or debian will need to worry about it when new libc lands post-lenny, whichever is sooner) and gda2 dependency hacking (which upstream has promised to port to gda3 asap)
[09:20] <seb128> pitti: the i386 retracer is available, should I restart it or do you want to test something?
[09:21] <NCommander> RAOF, the patch is still needed until unionfs is completely dead, so I rewrote the patch as not to be stupid and have a stack exploit.
[09:21] <pitti> seb128: no, please go ahead and restart
[09:21] <seb128> pitti: done
[09:21] <directhex> RAOF, he did! except now apparently aufs doesn't need it
[09:21] <NCommander> directhex, at the time, the livecd was still unionfs :-)
[09:21] <RAOF> Hm, which reminds me.  There's an easy to fix gtk-sharp memory leak that I should get debdifing.
[09:21] <cjwatson> we have at least one critical problem with aufs, so don't count your chickens
[09:21] <NCommander> s/was/still is/g
[09:21] <directhex> cjwatson, well the patch is still there if need be, it's just off in 00list
[09:22] <RAOF> ...which would go faster if my ISP didn't think 50 bytes/sec was blazing fast!
[09:22] <NCommander> RAOF, what, you have AOL?
[09:22] <directhex> right, i have a minibus to catch
[09:22] <StevenK> RAOF: For an Australian ISP, that's too fast
[09:23]  * cody-somerville is downloading at 1.4mb/s :-)
[09:23] <tseliot> mvo: have a look at my reply here: https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/247376
[09:23] <tseliot> mvo: I'll be glad to help
[09:23]  * RAOF is usually able to download at ~1Mb/sec
[09:25] <RAOF> Urgh.  Does anyone else feel like doing what should be a simple cherry pick from upstream svn for this gtk-sharp memory leak?
[09:27] <mvo> tseliot: thanks, that sounds reasonable, I will look into it later today
[09:29] <tseliot> mvo: ok
[09:30] <NCommander> RAOF, sorry, already have my own lack of sanity "issues"
[09:31] <seb128> oh, mvo is back
[09:31]  * seb128 hugs mvo
[09:31] <mvo> hello seb!
[09:31]  * mvo hugs seb128
[09:32] <RAOF> NCommander: Bah!  Do my bidding!  Oh, well.  I'll go and do some washing up then.  Presumably gtk-sharp2 will have finished checking out by then.
[09:32]  * pitti hugs mvo, hey mate!
[09:32] <NCommander> RAOF, lol
[09:33] <cody-somerville> slangasek, fail. I ran out of disk space :P
[09:33]  * mvo hugs pitti
[09:36] <dholbach> hey mvo!
[09:36] <dholbach> hey seb128!
[09:38] <seb128> hello dholbach
[09:40] <mvo> hey dholbach!
[09:51] <directhex> oh, the other one that should make people happy is the planned changes to mono packaging that should yield a large disk space reduction (no precise figures yet, but we're talking the region of 40% smaller install size for f-spot/tomboy with dependencies)
[09:52] <pitti> directhex: wannahavewannahave!
[09:52] <directhex> pitti, not until post-intrepid. sorry.
[09:52] <pitti> directhex: sure, but it's great to hear; what will change?
[09:54] <directhex> pitti, in short, 2 main things: .NET 2.0 apps like tomboy will no longer require any .NET 1.1 components to install (libmono-*1.0-cil things), and libmono{1,2}.0-cil will be split into its constituent components, as there's no reason to pull in things like sqlite dependencies because you want to use Mono.Posix for i18n
[09:58] <directhex> oh, and i forgot the third one: stop depending on libmono0, it's totally not needed by anything except libuno-cil
[09:59] <mcasadevall_> directhex, what depends on libmono0?
[09:59]  * mcasadevall_ has gotten creative w.r.t. to cross-bootstrapping gcc
[10:02] <directhex> mcasadevall_, currently? lots of things. libmono-system*-cil for one (System is the main namespace, and mandatory, so libmono0 is currently always pulled in). also mono-utils and libmono{1,2}.0-cil (useful Mono-originated libraries)
[10:02] <mcasadevall_> explicately or via dpkg-shlibs?
[10:05] <directhex> via a flaw in ${cli:Depends} i think.
[10:31] <pitti> mpt: so I did a mockup of the jockey UI changes we talked about; do you have a minute to have a look at it? I'm not quite sure how to improve the layout, especially where to put the "Install" button
[10:31] <mdz> cjwatson: I just had a poke at the current daily desktop ISO, and the F4 menu in gfxboot doesn't allow me to navigate with up/down arrow keys in KVM.  Do you know if it works outside of KVM?
[10:31] <pitti> mpt: http://people.ubuntu.com/~pitti/tmp/main.glade is the glade
[10:33] <cjwatson> mdz: WFM in kvm with -k en-us
[10:34] <mdz> cjwatson: me too, with -k en-us
[10:35] <cjwatson> mdz: usual kvm bug, then. gfxboot itself is working fine
[10:35] <mdz> cjwatson: ok, thanks
[10:35] <mdz> cjwatson: I wonder what will happen when I try to use the alpha keys with -k en-us
[10:35] <mdz> when X is using us(dvorak)
[10:38] <cjwatson> IME changing the console keymap after that sort of works a bit but not quite. The KVM bug definitely needs to be fixed
[10:38] <pitti> mpt: http://people.ubuntu.com/~pitti/tmp/jockey-new.png is a corresponding screen shot
[10:39] <pitti> mpt: the install button is new and a response to your suggestion that clicking on an item in the driver list should not enable the driver, just update the info
[10:56] <Company> pitti: i like that screenshot
[10:56] <Company> pitti: it's a nice dialog that says "your hardware sucks, no matter what you chose"
[10:57] <Treenaks> Company: The German buttons help with that as well ;)
[10:57] <Treenaks> "Wait.. why are those German? Something must be wrong with my graphics card"
[10:58] <Company> Treenaks: i know glade too well to still be bothered by those buttons
[10:58] <Company> my hacking makes me miss out on all the fun
[10:59] <Treenaks> ;)
[11:06] <MortenB> How many hours until alpha 5 is out?
[11:12] <cjwatson> MortenB: we can't give you an answer to questions of that form, because milestones are not scheduled to the hour; it depends on how well testing goes
[11:13] <MortenB> ok
[11:14] <cjwatson> wow, yes, something *has* put fonts into ugly mode
[11:18] <ogra> just make braile the defult output ... solves all font probs
[11:18] <ogra> *braille
[11:23] <pitti> cjwatson: me too
[11:23] <ogra> cjwatson, fyi the cheese/gstreamer fix on the cmpc works ... but only if i apply both of them
[11:23] <ogra> which means two SRUs :(
[11:31] <ScottK> pitti: Thanks for all the Spamassassin/Clamav MIR getting done so quickly.  Personally, I not doing anything with seeds until after Alpha 5 releases ..
[11:32] <ScottK> pitti and soren: The rationale for not promoting the milter is that it's not needed for the use case we wanted to support and it's not (AFAICT) much used in Ubuntu so it'd be hard to get it well tested.
[11:32] <pitti> ScottK: you're welcome
[11:34] <verwilst> euh, the flashplugin-nonfree in hardy-backports
[11:34] <verwilst> <IP_ADDRESS>+<IP_ADDRESS>5ubuntu1~hardy1+really<IP_ADDRESS>ubuntu2
[11:34] <ScottK> Of course this means I can't approve the FFe for clamav 0.94 anymore, so I need to get to work.
[11:34] <verwilst> seems to be 9.0 still?
[11:34] <ScottK> verwilst: Yes.  Tried 10.0 and it didn't go so well.
[11:35] <ScottK> Had to revert it.
[11:35] <verwilst> oh
[11:35] <verwilst> what went wrong?
[11:35] <verwilst> 9 still crashes like crazy :)
[11:36] <verwilst> damned proprietary c**p
[11:36] <verwilst> :)
[11:36] <ScottK> At the time, 10 was substantially worse on Hardy.
[11:36] <verwilst> the rc was a lot better though
[11:36] <ScottK> There's a bug open in hardy-backports if you really care for the details.
[11:37] <verwilst> <IP_ADDRESS>9 is the latest
[11:38] <ScottK> The bug in hardy-backports is the place to have the conversation if you're interested.
[11:39] <verwilst> euh which of the 167 bugs is it? :)
[11:39] <verwilst> 162 sorry
[11:40] <ScottK> verwilst: Bug 235135
[11:41] <ScottK> If you want to start the process of testing the newer version feel free to make it not invalid and document your work.
[11:41] <kelemengabor> hi mvo
[11:41] <mvo> hi kelemengabor
[11:41] <kelemengabor> would you please comment on this bug: https://bugs.launchpad.net/ubuntu/+source/app-install-data-ubuntu/+bug/254628
[11:42] <mvo> kelemengabor: yes, I will do that after lunch
[11:42] <kelemengabor> thanks :)
[11:42] <mvo> kelemengabor: thanks a lot for your initial version of the script!
[11:42] <verwilst> ScottK: https://bugs.launchpad.net/ubuntu/+source/flashplugin-nonfree/+bug/257403 looks promising
[11:43] <ogra> asac, i cant upload attachments to LP anymore ... FF only offers me dirs, not files ?
[11:43] <ogra> (intrepid)
[11:43] <ScottK> verwilst: Yes, that'd have to be done first.  Then a backport.
[11:43] <asac> ogra: when started?
[11:44] <ogra> well, its a while ago that i uploaded my last patch via the web ui
[11:44] <ogra> just noticed it now
[11:44] <ogra> there are no files in the fileselector at all
[11:44] <ogra> only dirs
[11:45] <ogra> system was updated yesterday last
[11:45] <verwilst>     File name: npwrapper.libflashplayer.so    Shockwave Flash 10.0.0 d569, installed here ;
[11:45] <verwilst> let's see if it works as great as i think it will ;)
[11:45] <verwilst> ( from his ppa )
[11:47] <asac> verwilst: remember that nspluginwrapper istn really at its best atm ;)
[11:47] <verwilst> asac: what do you mean?
[11:47] <asac> verwilst: nspluginwrapper 1.1.0
[11:47] <asac> is hot crack ;)
[11:47] <verwilst> asac: is that a good or a bad thing? :)
[11:48] <verwilst> what's improved since the 0.9 thing that hardy has?
[11:48] <asac> verwilst: are you on i386?
[11:48] <verwilst> yip
[11:48] <asac> verwilst: 1st. its available on i386
[11:48] <asac> (which wasnt the case in hardy)
[11:48] <cjwatson> is bugs.edge.launchpad.net refusing to take bug comments for anyone else?
[11:48] <verwilst> euh?
[11:48] <asac> 2nd. it supports windowless plugins
[11:49] <verwilst> 0.9 doesnt?
[11:49] <asac> e.g. flash 10 supports windowless mode now ... so nspluginwrapper had to follow
[11:49] <verwilst> so nspluginwrapper became the de facto standard of flash-containment? :)
[11:50] <asac> verwilst: thats the idea.
[11:51] <asac> verwilst: let me know what your experiences are with that wrapper
[11:51] <directhex> nspluginwrapper was completely farked in hardy
[11:51] <directhex> as in "just plain dies every few seconds if you use compiz"
[11:51] <asac> directhex: you sure that wasnt flash?
[11:52] <directhex> in the end i gave up & switched to a binary 32-bit firefox in /opt
[11:52] <directhex> asac, yes, sure
[11:52] <verwilst> asac: so i should install it too
[11:52] <verwilst> or is it in backports?
[11:52] <asac> directhex: you could try to move /usr/lib32/libflashsupport.so away
[11:52] <asac> verwilst: are you on hardy?
[11:53] <verwilst> yeah
[11:53] <verwilst> i took the deb from https://launchpad.net/~psyke83/+archive
[11:53] <asac> ok ... then you dont have 1.1.0 anyway
[11:53] <verwilst> ( for flash )
[11:53] <verwilst> ah ok :)
[11:54] <verwilst> flash was hell for my girlfriend :)
[11:54] <verwilst> switched her to ubuntu from windows
[11:54] <verwilst> and during first thing she did, she had a firefox crash
[11:54] <verwilst> around 10-15/day
[11:55] <directhex> flash is hell generally
[11:55] <verwilst> it was pretty embarrassing
[11:55] <verwilst> after a few weeks, i did the nspluginwrapper stuffs
[11:55] <directhex> of course, i wonder how many people will beat me with a pole if i suggest silverlight instead
[11:55] <verwilst> which made it pretty under control
[11:55] <verwilst> silverlight _is_ open sourced..
[11:55] <verwilst> which is its only advantage though..
[11:56] <directhex> moonlight is. silverlight isn't
[11:56] <verwilst> oh yeah sorry
[11:56] <verwilst> i was talking about moonlight
[11:56] <directhex> any objections to a moon package?
[11:57] <asac> verwilst: so are you using nspluginwrapper for i386 from mozillateam ppa or something homebrew?
[11:58] <asac> ogra: try to downgrade xulrunner-1.9 please
[11:59] <asac> to <IP_ADDRESS>+* (you probably have <IP_ADDRESS>+build3)
[11:59] <asac> Note: i dont see that problem :(
[11:59] <directhex> oh, that was something i was gonna ask. will xul-dev 1.8 and 1.9 ever be installable side by side? it makes a difference to moonlight packaging
[12:00] <ogra> persia, any objections if we dont update denemo in intrepid ?
[12:01] <asac> directhex: the -dev packages conflict intentionally
[12:01] <persia> ogra: None at all, as long as you push it to universe.
[12:01] <ogra> that way we can just get a MIR for libaubio and are done with it for now (indeed postponing the change/decision to intrepid+1)
[12:01] <ogra> persia, no need for that
[12:01]  * persia looks at libaubio rdepends
[12:03] <directhex> ooh, actually, i can get around it by using firefox-2-dev
[12:04] <persia> ogra: Are you planning on pulling all the libaubio2 dependencies as well?  I know rexbron was looking at freebob, but as far as I know no MIR exists yet.
[12:04] <ogra> persia, or dropping aubio
[12:04] <persia> And it's just freebob that I thought might be an issue.
[12:04] <ogra> from denemo
[12:04] <persia> ogra: Could do that I suppose.
[12:04]  * persia looks at denemo again
[12:04] <ogra> i'd like to go with the easiest option ...
[12:05] <persia> Wouldn't the easiest just be to drop denemo from the seed?
[12:05] <verwilst> flash will be open too sooner or later as well ;)
[12:05] <persia> All the feedback in the thread about it seemed to indicate that nobody used it, but I don't know how widely the mailing list is subscribed.
[12:05] <ogra> well, that would be a regression imho
[12:06] <persia> Yeah.  I'm just wondering if people are going to expect denemo to be able to render audio.  They could be pointed to mscore, but the results don't look as good when printed.
[12:07] <asac> james_w: when i want to use a specific build-dir and stuff like that for a certain tree on my system, how do i best configure that in builddeb.conf?
[12:07] <persia> Also, what about lilypond?  Are you expecting anyone to be able to render sheet music to a printer from denemo?
[12:08] <asac> james_w: could i say something like: path/to/intrepid/trees -> result-dir=/path/to/intrepid/results/
[12:08] <asac> ?
[12:09] <siretart> asac: what's the use-case of that? how many such branches do you have?
[12:09] <asac> siretart: i have a bunch of branches
[12:10] <asac> siretart: i have a bunch that is debian ... another that is intrepid ... another that is hardy
[12:10] <asac> and i dont want the results to end up in the same directory
[12:10] <asac> also i would like to use distinct build-areas
[12:10] <james_w> asac: ideally you could use locations.conf for that, but locations.conf isn't checked for builddeb's settings
[12:10] <james_w> asac: or perhaps it is now, let me have a look
[12:11] <asac> james_w: that would be cool ;)
[12:11]  * siretart has specified that on the command line up to now, but I agree that this is a bit cumbersome
[12:11] <asac> me too ... and i regularly forget it ;)
[12:11] <asac> my bzr bd line is already long enough ;)
[12:12] <james_w> asac, siretart: you can use local.conf, but it's a pain to set it for all branches if you have lots
[12:12] <siretart> asac: oh, try aliases
[12:12] <asac> siretart: i tried to ... but i always forget :)
[12:12] <siretart> asac: I often define ad hoc aliases in my interactive shell for such purposes
[12:14] <asac> siretart: thats a last resort. i just hoped that i can configure it magically so i dont need to think at all ;)
[12:15] <siretart> asac: even with locations.conf, you still have to configure them all one-by-one initially
[12:16] <asac> siretart: not if it does match patterns. ;) ... i usually have *.head branches (which track latest development)
[12:16] <asac> and .hardy ... for hardy
[12:16] <james_w> siretart: you can use policies to avoid that in some cases
[12:16] <siretart> asac: oh, does locations.conf indeed use patterns? that would indeed be helpful here
[12:16] <siretart> james_w: what is a 'policy' here?
[12:17] <asac> on top env could specify a different locations.conf
[12:17] <asac> so when i schroot -csid
[12:17] <asac> i can build my .head branches but those go to "sid" results then
[12:17] <james_w> siretart: you can specify a build-dir for /home/whoever/wherever/ and then a policy to recurse, so it is the same for all branches under that location
[12:18] <asac> james_w: how hard would it be to make that a pattern?
[12:18] <james_w> asac: no idea
[12:18] <asac> i usually want all my branches in the same directory
[12:18] <siretart> james_w: I see. well, I need to read the documentation about that then :)
[12:18] <james_w> asac: defining what wins is much harder though
[12:19] <asac> james_w: what wins? as usual: first match wins ;)
[12:19] <asac> or last match
[12:19] <asac> i dont mind :-D
[12:20] <asac> i think its the responsibility of the user to not have disambiguities
[12:24] <ramvi> [CUSTOMIZING LIVECD] I experienced some problems upgrading something when customizing the livecd. It's fixed now, the bug reports are saved somewhere though and is the first thing that greets a new user. Where are the bug reports saved? How can I stop them from appearing?
[12:26] <ramvi> nevermind, found it: /var/crash/
[12:29] <persia> ogra: To get back to the discussion, I think that denemo without any of libaubio, csound, or lilypond is a little crippled.  For my interests, lilypond is sufficient, but I wonder which goal you expect to solve.  Just screen entry of notes?
[12:30] <ogra> well, i dont know what you got last from me
[12:30] <ogra> i seem to fail to find jordans original mail
[12:30] <ogra> and the eudbuntu list only had a single reply
[12:30] <asac> ogra: would appreciate if you could do a quick downgrade test
[12:30] <ogra> from y user who said he uses ubuntustudio and is happy with it
[12:30] <ogra> *s/y/a/
[12:30] <asac> you are basically running the xulrunner 1.9 security upgrade so any regression is important to track
[12:30] <asac> ;)
[12:31] <ogra> which is not really helpful
[12:31] <cjwatson> asac: bug 262152 bites me on every reboot; I think we should do something about it for intrepid
[12:32] <ogra> persia, i would consider it a regression to drop denemo
[12:32] <ogra> but then, if its not used there is indeed no reason to keep it
[12:33] <ogra> asac, will do so as soon as i have a hand free
[12:33] <asac> cjwatson: lets milestone it then (though i still have that in my head ;))
[12:34] <cjwatson> thanks
[12:34] <ogra> could i ask an archive admin to give me a hint why my cheese upload to hardy-proposed is rejected ?
[12:35] <persia> ogra: I understand that dropping it without cause is a regression: I'm just curious which use case it's there for: without lilypond, it can't render sheets for printing, and without either libaubio or csound, it can't render audio.
[12:35] <ogra> the drescher mail talks about a md5 mistmatch ... but i definately pulled the source from the archive
[12:35]  * ogra wonders if he found a bug
[12:36] <ogra> c5f767bd9a55d2a515fd8960ec3523c0 1650728 gnome optional cheese_2.22.3.orig.tar.gz is definately the right md5 for whats in proposed
[12:36] <cjwatson> ogra: there's already a cheese 2.22.3-0ubuntu2 in the archive
[12:36] <ogra> not on -changes and i dont get it from apt-get source
[12:36] <cjwatson> it's not the .orig.tar.gz it's complaining about. (The unhelpful message from Launchpad has been fixed for the next rollout.)
[12:36] <cjwatson>     cheese | 2.22.3-0ubuntu2 | intrepid/universe | source, amd64, hppa, i386, ia64, lpia, powerpc, sparc
[12:36] <cjwatson> use 2.22.3-0ubuntu1.1
[12:36] <ogra> intrepid
[12:37] <ogra> sigh ... i didnt think about looking at intrepid ...
[12:37] <cjwatson> yes. it's still in the archive; you can't have different things called cheese_2.22.3-0ubuntu2 in hardy and intrepid
[12:37]  * ogra curses ... doing the same mistake again
[12:37] <cjwatson> of course, I had the benefit of locate(1) :-)
[12:37] <ogra> yeah, i had that with a former upload
[12:37] <ogra> isnt 1.1 for security only ...
[12:38] <cjwatson> no
[12:38] <ogra> that gets confusing over time i bet
[12:38] <ogra> ok
[12:38] <cjwatson> I've used that scheme for updates plenty of times
[12:38] <ogra> i always thought .n was limited to security ... assumptions assumptions :)
[12:38]  * ogra fixes the upload
[12:39] <persia> The wiki at one point indicated that all SRUs should use the same versioning as for security updates.  I'm not sure if that's the case today.
[12:40] <cjwatson> SRUs should simply use non-clashing version numbers. This means two things: firstly, don't clash with something that already exists; secondly, don't clash with something that might reasonably be expected to exist later (e.g. if you have 1.0-1 in hardy and Debian doesn't have a newer version for merging into intrepid, don't use 1.0-2)
[12:40] <cjwatson> beyond that, and especially if the next release along is already a known version, it really doesn't matter
[12:40] <ogra> yeah
[12:40] <cjwatson> (also, don't clash with something that *has* existed in the past, of course)
[12:41] <ogra> heh, indeed
[12:41] <pitti> persia: it was just a proposal of a scheme which is reasonably clash-free, but not a requirement
[12:41] <persia> pitti: Indeed.  I think the wiki has been fixed since, but at one point it indicated it was a requirement.
[12:42] <persia> I suspect it was the result of an overzealous editor, rather than being an official policy.
[12:49] <ogra> persia, ok, denemo dropped (though i'd still like to find that original mail of joardan)
[12:52] <persia> ogra: https://lists.ubuntu.com/archives/edubuntu-users/2008-August/004331.html : You could pull from the mbox archive if you need a local copy.
[12:54] <persia> ogra: Also, although we do Recommends-by-default, please don't remove the Recommends: on lilypond and csound, as for universe use, those are somewhat important for denemo to behave as expected.
[12:54]  * ogra doesnt get it
[12:54] <ogra> i'm the listadmin for edubuntu-users
[12:54] <ogra> why the heck dont i have that mail at all
[12:55] <persia> ogra: It was also sent to edubuntu-devel, if that helps you find it.
[12:56] <ogra> o match
[12:56] <ogra> *no
[12:57]  * ogra wonders if its time to drop evo ... :(
[13:01] <mpt> pitti, hi
[13:01] <pitti> hey mpt
[13:03] <mpt> pitti, buttons should always use Title Case
[13:03] <mpt> (unless you're programming for Windows Vista, which you're not)
[13:04] <pitti> argh no :)
[13:04] <mpt> pitti, good work removing the column headers
[13:04] <pitti> mpt: Show License button fixed
[13:04] <didrocks> hi
[13:04] <pitti> mpt: column headers?
[13:05] <pitti> mpt: this is just a glade mockup, so I cannot actually put demo contents into the driver list
[13:05] <mpt> pitti, yes, "Component", "Enabled", and "Status"
[13:05] <soren> When do we expect to lift the alpha freeze?
[13:05] <pitti> mpt: I didn't remove them, it's just the glade; if they shuold go, I can do that in the code
[13:05] <mpt> ah
[13:05] <didrocks> is there someone more or less in charge of the lm-sensors package?
[13:06] <mpt> pitti, why do the list and the description talk about "enable" and "disabled" while the button reads "Install..."?
[13:06] <mpt> What are we doing here, exactly?
[13:06] <pitti> mpt: the Install button will actually read "Enable" or "Disable", depending on whether the driver is currently enabled
[13:07] <pitti> mpt: and the Show License.. button will only appear for non-free drivers
[13:07] <mpt> pitti, do you need to do anything else to see the license, other than clicking that button?
[13:08] <pitti> mpt: main.glade updated to p.u.c.
[13:08] <pitti> mpt: I envisioned that clicking the button will produce a second dialog with a large scrollable text area and a close button
[13:08] <pitti> (unless you have a better ide)
[13:09] <mpt> pitti, in that case, you won't need to do anything else to see the license, other than clicking that button
[13:09] <mpt> Therefore, the button should not have an ellipsis
[13:09] <pitti> ok, done
[13:10] <asac> mpt: http://people.ubuntu.com/~asac/screenshots/plugin.alt.png ... can you tell me if its good enough just to have the radio buttons next to the plugin icon on top? or do i need to prefix it with "manage" or "Filter" or something?
[13:10] <asac> (the dialog would be called "Manage Content Plugins" or something i guess)
[13:10] <mpt> pitti, the driver description is missing its border -- it should have exactly the same border as the list does
[13:10] <mpt> asac, window titles should always use Title Case
[13:11] <asac> mpt: read what i wrote two lines above ;)
[13:11] <mpt> ah :-)
[13:11] <asac> mpt: i am mostly interested in the heading above the list ... just the plugin icon and then the radio thing?
[13:11] <mpt> asac, what's the icon for?
[13:11] <asac> or keep the word "Manage" or Filter or something
[13:11] <asac> mpt: thats the official "plugin" icon used in firefox
[13:12] <mpt> asac, yes, but what does it do in this window?
[13:12] <asac> mpt: nothing. its just an eye candy
[13:12] <mpt> asac, I suggest removing it then
[13:12] <pitti> mpt: hm, the normal TextView widget doesn't seem to have one
[13:13] <asac> mpt: atm i just want to know wehther the radio alone is enough ;)
[13:13] <mpt> pitti, I think that's because it's sometimes used for the entire contents of a window, in which case it shouldn't have a border beyond what the window manager already provides
[13:13] <pitti> mpt: maybe I shuold replace it with a GtkScrolledWindow container
[13:13] <mpt> pitti, but as a result, GTK programmers very often forget to add the border when it's *not* the entire contents of a window
[13:13] <mpt> It's quite unfortunate
[13:14] <amitk> what would it take to get kerneloops into the default install?
[13:14] <mpt> asac, I suggest "Show:", and putting that label to the left of the radio buttons rather than above them.
[13:14] <asac> okay
[13:15] <mpt> asac, also, radio button labels should always use sentence case. :-)
[13:15] <mpt> (e.g. "Plug-ins in use", not "Plug-ins in Use")
[13:15] <asac> and "All plugins" ?
[13:15] <mpt> right
[13:15] <asac> for me that always looks funny
[13:15] <asac> but well :)
[13:16] <pitti> mpt: main.glade updated on p.u.c.
[13:16] <pitti> mpt: I removed the ellipsis from Enable... too, for the same reason
[13:16] <asac> mpt: ok. and such a dialog would get a "Close" button ... not "Ok", right?
[13:17] <mpt> pitti, well done :-)
[13:17] <asac> (the changes apply instantly when you change the selection)
[13:17] <mpt> asac, what dialog?
[13:17] <asac> mpt: the dialog we are talking about?
[13:17] <pitti> mpt: btw, in the actual code, the Enable button will get the usual icon (just like in current jockey), and Show License shuold get the info symbol; unfortunately that's not possible in glade-3
[13:18] <pitti> mpt: do you think the enable button is too 'hidden'? shuold it be in the bottom button bar (where help and close is)?
[13:18] <mpt> asac, this isn't a dialog. It's an ordinary window, like Firefox's Add-ons and Bookmarks/History windows.
[13:19] <mpt> asac, so my next suggestion was going to be, remove all the padding between the edge of the list and the right, bottom, and left edges of the window. Like in a Nautilus window.
[13:19] <asac> mpt: preferences -> Close button ... addons -> no button
[13:19] <mpt> pitti, does that mean all the buttons will become the same height?
[13:20] <asac> mpt: yes thats on my list
[13:20] <asac> (padding)
[13:20] <pitti> mpt: yes (if not through the icon, I'll make sure it happens in the code, but I suppose setting an icon will fix it already)
[13:20] <pitti> I wish glade-3 would allow me to set a button icon with arbitrary text..
[13:20] <mpt> asac, so the part at the top with the radio buttons in it should have padding, but the rest should not. Like Nautilus's Trash window.
[13:21]  * asac never uses nautilus :-P
[13:21] <asac> let me look
[13:21] <asac> mpt: yes. i agree
[13:21] <asac> mpt: the other thing i wondera bout is whether the rows should get a title?
[13:22] <mpt> asac, however, because each item in the list can potentially contain an option menu, each item should have the normal padding.
[13:22] <asac> like "Content type" "Plugin"
[13:22] <mpt> Which means the rows will be quite a bit taller than they are now.
[13:22] <mpt> asac, good question, I was wondering about that
[13:22] <mpt> I'm not sure
[13:23] <asac> mpt: i dont understand the "normal" padding for the items
[13:23] <asac> you say that i should add an extra padding for the items?
[13:23] <asac> like 0.25em?
[13:23] <pitti> mpt: updated again, I fixed the expand/fill attributes, so that resizing the dialog DTRT
[13:23] <mpt> asac, as in 0.5em between the edges of the option menu and the edges of the cell that it's inside.
[13:25] <asac> ok ill try. what i ll do is ensrue that every element has a proper class so we can tweak all this through CSS
[13:25] <mpt> pitti, this is looking much better
[13:25] <asac> thanks for your input so far
[13:25] <pitti> mpt: so clicking on Enable would immediately start installation, instead of giving you the confirmation dialog with the detailled description
[13:25] <mpt> asac, I think column headers might well help some people understand which is the plug-in and which is the media type
[13:26] <asac> mpt: oh. still: close or no button to close? (preferences window has a button, while addons doesnt have one)
[13:26] <mpt> asac, especially since being a window devoted to plug-ins, people might expect that to be the first textual column
[13:26] <asac> mpt: right.
[13:26] <mpt> asac, no extra button, like the Add-ons window
[13:26] <asac> ok
[13:26]  * mpt starts to wish Glade had a "Revert" menu item
[13:26] <asac> mpt: are you using glade 3?
[13:27] <mpt> yep
[13:27] <pitti> mpt: there's undo in glade-3?
[13:27] <mpt> pitti, I mean to reload the file after I've downloaded each new revision of yours :-)
[13:28] <mpt> pitti, when you click "Enable", do you need to do anything else to enable the driver?
[13:28] <pitti> mpt: so if you are generally satisfied with which kind of information is displayed and the new installation workflow, I can change the code accordingly (moving buttons around is cheap afterwards, changing workflow less so)
[13:28] <pitti> mpt: no, that's why I removed the ellipsis
[13:28] <mpt> ah, so you did
[13:29] <pitti> mpt: well... it is conceivable that in the future particular handlers ask for more information, but I try to avoid that as much as possible
[13:29] <mpt> ok
[13:29] <pitti> mpt: and in that case I can still dynamically add the elipsis to the button
[13:29] <pitti> but in general you'll immediately get the progress window and install starts
[13:29] <mpt> nice
[13:30] <mpt> pitti, so yes, the interaction looks fine, though there are still a few things to fix in the layout
[13:30] <mpt> and the text
[13:30] <pitti> should the two label values be left-aligned?
[13:30] <mpt> How easy is it to change the text for each driver?
[13:30] <pitti> i.e . support status and license value
[13:31] <pitti> mpt: it's a matter of changing it in the particular handler .py file, or in the online driver db
[13:31] <mpt> thanks asac
[13:31] <pitti> but since it gets i18n'ed, the cost is not negligible, since it would break translations
[13:31] <mpt> true, that's always a problem
[13:32] <pitti> but all the nvidia specifics in that glade are just random examples, they won't be in the glade, of course
[13:32] <pitti> but having them there makes reviewing easier, I thought
[13:32] <mpt> pitti, I'm not sure about the alignment, that partly depends on the rest of the layout.
[13:33] <pitti> ATM the bottom half layout is pretty messy
[13:33] <mpt> yes
[13:33] <pitti> seems I really lack the talent to come up with something that looks friendly and standardized
[13:34] <mpt> afaict there are three issues remaining: (1) uses the word "enable" (an easy wording fix), (2) the "Enable" button looks very closely related to the support status when it isn't, and (3) there are three different button widths in quick succession.
[13:36] <pitti> mpt: what would you recommend instead of "Enable"? It's not install/uninstall, as you can have drivers which are installed, but disabled (i. e. not used)
[13:36] <mpt> Tentatively, "Use This Driver" and "Stop Using This Driver"
[13:37] <mpt> the latter's a little long
[13:37] <pitti> even the former is very long if I consider the German translation
[13:37] <mpt> so use whatever's the German for "Enable" instead then :-P
[13:38] <pitti> heh, yes, of course translators could do that :)
[13:39] <mpt> pitti, when would be the best time to tackle the layout? Now, or sometime later?
[13:39] <pitti> mpt: (3) I could fix the top two buttons by placing them into a vbox and using fill/expand, I suppose; but that wouldn't apply to the "close" button which is part of the standard dialog button bar
[13:39] <asac> German for Enable ... ist "enablen" ;)
[13:40] <pitti> asac: *cough*
[13:40] <pitti> asac: gedowngeloadet :)
[13:40] <asac> oh ... better "enaebeln" ;)
[13:40] <asac> hmmm
[13:40] <asac> "eneibeln" ;)
[13:40] <pitti> mpt: whenever you have time, I'm good with "now" (well, meeting in 20)
[13:40] <asac> pitti: we should finally stop being so picky about translations :)
[13:40] <pitti> asac: I have "Aktivieren"
[13:40] <mpt> pitti, yeah, I need to send in my activity report. ;-) How about after the meeting?
[13:41] <pitti> mpt: great; since it's only layout, I can start coding already
[13:41] <asac> pitti: which means: "activate" ;)
[13:41] <pitti> en_STARTREK: "Engage!"
[13:41] <mpt> Make it .so
[13:42] <ogra> asac, "enaebeln" is so not german ... änäbln is ...
[13:42] <pitti> I don't know you guys
[13:42] <ogra> it has the right umlauts at least
[13:42] <asac> ogra: i feel like an outsider in germany ... i refuse to type umlauts
[13:42]  * ogra giggles evlish
[13:43] <ogra> me too usually :)
[13:43] <asac> good
[13:44] <cjwatson> asac: so is libmbca dynamically loaded by network-manager?
[13:44] <cjwatson> I was trying to work out how a UI could be a shared library
[13:44] <pitti> asac: I think "Uuuuuuuuuund... ACTION!" is cool, too
[13:45] <asac> cjwatson: its a wizard library
[13:45] <asac> cjwatson: nm-applet will be patched to use that
[13:45] <cjwatson> right, ok
[13:45] <asac> (but i cant until we have that lib)
[13:46] <cjwatson> I've accepted it and the database; they should build shortly
[13:46] <asac> thanks
[13:46] <asac> pitti: "gib Gas!"
[13:46] <asac> ;)
[13:47] <asac> or "Ab dafür!"
[13:48] <mok0> I am building Google's new browser Chromium. Anyone wants to join in the fun of building a package?
[13:49] <cpufreak> gnarly
[13:50] <mpt> mok0, does it do anything more than run the test suite?
[13:50] <mok0> mpt: don't know yet
[13:50] <mpt> (or crash)
[13:51] <asac_> reconect
[13:51] <mok0> mpt: this is no ordinary run-of-the mill build. The tarball is 438 Mb
[13:52] <mok0> mpt: alone the debian/copyright will be ~1Mb I expect :-P
[13:52] <asac_> jcastro: would you mind to setup a "chromium" project as a top level project where googlechrome and V8 and other components live in?
[13:53] <mpt> mok0, wow, deja vu
[13:53] <mpt> "The Mozilla source runs 40 megabytes and 1 million-plus lines of intermingled C and C++ covering Windows and Mac and nearly every flavor of Unix, so diving into it is not an undertaking for those with weak hearts or slow computers. To build and use the free Mozilla source code for the free Mozilla browser, you will probably need to invest several thousand dollars in a new computer." -- Salon, 1998
[13:53] <asac_> jcastro: as subproject? e.g. we need more syncs (like for V8 et al)
[13:54] <mok0> Unfortunately, there is another package called "chromium" -- it's a game of some sorts
[13:54] <asac_> mok0: well. i want a launchpad project "chromium" ... not sure if that package already has a project ;)
[13:55] <mpt> mok0, exactly the same issue as epiphany vs. epiphany-browser
[13:55] <mok0> asac: Yeah good idea
[13:55] <dholbach> asac_: https://launchpad.net/googlechrome
[13:55] <asac_> dholbach: thast just the "chrome" subproject
[13:55] <_MMA_> mok0: Just a note: "ajmitch: 'Although many Chromium submodules build under Linux and a few unit tests pass, all that runs is a command-line "all tests pass" executable.'"
[13:55] <dholbach> ah ok
[13:55] <siretart> hey, chromium is a really fun game :)
[13:57] <mok0> Well Googles page on building it is scarce of info
[13:57] <ogra> seb128, my evo lost mails ... :(  (just found that by searching for one today)
[13:58] <seb128> how?
[13:58] <ogra> no idea
[13:58] <seb128> there was a mbox corruption briefly during the 2.23.90 time
[13:58] <seb128> is that new mails?
[13:58] <ogra> https://lists.ubuntu.com/archives/edubuntu-users/2008-August/004331.html
[13:58] <ogra> that one is missing
[13:58] <ogra> i know i read it when it came in
[13:59] <ogra> and today searchiv for it only revealed the one reply it had
[13:59] <ogra> *searching
[13:59] <seb128> probably got hit during the 1 day where the buggy version was available
[13:59] <ogra> not sure if there were more lost, but i'm sure i had that one
[13:59] <pwnguin> mok0: most of the chrome tarball is binary data
[13:59] <mok0> pwnguin: yikes
[14:00] <pwnguin> theres like two builds in there, and a ton of test data
[14:00] <ogra> seb128, well, i'll keep an eye on it ... cant fix or change it anyway i guess
[14:01] <asac_> pwnguin: they ship all .dlls they need
[14:01] <pwnguin> asac_: if you ship your own .dlls, are they really shared?
[14:01] <asac_> pwnguin: most likely not. but i think thats a common thing on windows
[14:01] <asac_> i heard about "dll-hell" ;)
[14:02] <pwnguin> dll hell was a versioning thing
[14:02] <pwnguin> (is?)
[14:02] <asac_> but isnt that the reason why everyone ships duplicate .dlls?
[14:02] <mok0> Hmm. Got ld error
[14:02] <pwnguin> mok0: chrome's source management tools kept crashing on me =(
[14:03] <mok0> pwnguin: Seemed to work for me
[14:03] <mok0> pwnguin: but the build doesn't like the default libnss3.so
[14:04] <asac_> mok0: default == the copy they are shipping or the intrepid one?
[14:04] <pwnguin> i wound up just building the tarball without updating
[14:04] <mok0> asac: In fact... the hardy one
[14:04] <asac> mok0: doesnt chromium ship their "own" nss copy?
[14:05] <ogra> asac, which version of xulrunner shall i test ?
[14:05] <asac> mok0: maybe its a versioning mismatch there?
[14:05] <ogra> <IP_ADDRESS>+build3+nobinonly-0ubuntu1 is installed
[14:05] <asac> ogra: the last <IP_ADDRESS>+build available
[14:05] <ogra> ok
[14:06] <asac> mok0: do you used the "repo_tools" ... or did you just get a full checkout of the chromium sources?
[14:06] <mok0> I did a full checkout
[14:06] <asac> mok0: so how is it failing?
[14:06] <mok0> http://pastebin.com/f480b3e30
[14:07] <asac> mok0: you dont have the build depends installed as it seems
[14:07] <asac> mok0: install libnss3-dev
[14:07] <asac> hmm incompatible
[14:07] <ogra> asac, _<IP_ADDRESS>+build1+nobinonly-0ubuntu<IP_ADDRESS> ??
[14:08] <mok0> asac: I have it
[14:08] <ogra> (8.04.3 seems a bit strange)
[14:08] <asac> mok0: what is getting linked there?
[14:08] <asac> ogra: yes
[14:08] <ogra> ok
[14:09] <asac> ogra: what is strange about that? its the third respin of 0ubuntu8.04.*
[14:09] <asac> err 0.8.04.* ;)
[14:09]  * ogra is running 8.10 :P
[14:09] <mok0> asac: Ydrk can't say my damn terminator session just crashed :-(
[14:09] <soren> 7win 19
[14:09] <soren> Garh...
[14:09] <asac> ogra: hmm. are you sure you are looking at intrepid?
[14:10] <asac> ogra: there should be a <IP_ADDRESS> build for intrepid
[14:10] <ogra> i'm looking at archive.ubuntu.com
[14:10] <ogra> there is no other <IP_ADDRESS>
[14:10] <asac> ogra: nah. look at launchpad :)
[14:11] <asac> ogra: only launchpad has history ;)
[14:11] <ogra> oh, right
[14:11] <asac> ogra: https://edge.launchpad.net/ubuntu/+source/xulrunner-1.9/<IP_ADDRESS>+build1+nobinonly-0ubuntu1
[14:11] <asac> for your convenience
[14:11] <ogra> thanks
[14:11] <asac> ogra: most likely you need xulrunner-1.9 and xulrunner-1.9-gnome-support binaries
[14:12] <mok0> asac: trying again...
[14:13] <mok0> asac: but it seems there are special libnss3 packages for firefox and thunderbird
[14:13] <asac> mok0: that was long ago
[14:13] <asac> like in feisty
[14:13] <mok0> This is where it fails: Linking Hammer/base/base_unittests ...
[14:14] <asac> mok0: that doesnt tell me "what" pieces it tries to link together
[14:14] <pwnguin> mok0: check the bottom of the build manual page
[14:15] <mok0> pwnguin: you mean the bison stuff?
[14:15] <pwnguin> i thought it sounded similar, but i guess not
[14:15] <ogra> asac, yep, that fixes it
[14:16] <ogra> the file type selector shows "all files" in the bottom right dropdown now ... it didnt show anything with the newer version and listed only dirs
[14:16] <mok0> pwnguin: What is strange is that they say: "On Ubuntu 8, you can fetch all of the above as follows: ...... apt-get install .... libnss3-dev"
[14:17] <pwnguin> mok0: you might ask in #chromium-linux
[14:18] <mok0> pwnguin: good idea
[14:18] <pwnguin> knock some sense into 'em ;)
[14:18] <mok0> heh
[14:19] <pwnguin> ubuntu 8
[14:19] <pwnguin> wtf
[14:24] <mok0> pwnguin: well that can't be used for packages
[14:28] <mterry> mvo: Is there a way to 'queue up' a package installation (not an update) so that next time the user is online, update-manager would prompt to install?
[14:34] <tkamppeter> seb128, do you know balachmar? He wants to work on bug 258421?
[14:35] <seb128> no I don't know him and dunno
[14:35] <persia> tkamppeter: He's new: just got excited by this developerweek.
[14:35] <tkamppeter> seb128, did you already have a look at bug 258421?
[14:35] <seb128> yes quickly before my holidays
[14:35] <seb128> but it's not obvious why you commented code to me
[14:36] <tkamppeter> persia, thank you, he talked to me yesterday here on IRC, but when I saw it he had already left.
[14:36] <persia> mterry: Not realy.  One could mark something to be installed by apt, so next time the user performed an upgrade it would install.
[14:37] <mterry> persia: But only if they did it from command line?
[14:37] <mterry> persia: How evil would it be to create some fake package with a version 0?  7th circle or merely 2nd?
[14:37] <persia> mterry: No.  You can do about anything you want with python-apt: just don't actually perform the install.
[14:37] <tkamppeter> seb128, what do you mean with "commented code to me"?
[14:38] <persia> mterry: Well, version 0 actually works, but it tends to break the archive tools: my experience with 0.0~foo is that the archive-admins won't touch the package, making it non-ideal.
[14:38] <tkamppeter> seb128, do you mean that I commented out some code? This code does not make sense with PDF.
[14:39] <mterry> persia: I'm not sure I follow.  I can mark something to be installed by apt.  OK.  How does user see that?  Does update-manager prompt?
[14:39] <mterry> persia: Re: version 0, I'm not talking about in a repo, but locally create/install a version 0 deb on the fly, so when update-manager runs, it prompts to download
[14:39] <seb128> tkamppeter: I just looked at the patch, will need to look at the code to have some context
[14:39] <persia> mterry: You *really* don't want to do that.
[14:40] <mterry> persia: (this is for if a user picks a language that isn't available at install time.  I'd like update-manager to prompt to download language packs)
[14:40]  * persia digs up the python-apt docs, having filed the information in deep storage
[14:43] <mrxmike> why is there no package for winexe in the repos!? > http://eol.ovh.org/winexe/
[14:43] <mrxmike> its a really handy tool!!
[14:44] <persia> mterry: I think what you want is to call markedInstall = true for a given package, but not commit.  From my understanding this should cause the apt-cache to update and indicate the package is to be installed.  Next time there is a commit of the apt-cache, it would install the package (for instance, in update-manager).  You'd want to test to see what that means for UI though.
[14:44] <persia> If you know you have access to a repo, you can commit immediately, and perform the install.
[14:45] <mterry> persia: OK.  Thanks for the pointer!  I'll dig/test
[14:45] <mvo> mterry: sorry, there is currently no way to make this kind of persistant marks for install in plain apt
[14:45] <jcastro> asac: what about chromium-browser for the big group? same solution people do for epiphany.
[14:45] <mvo> mterry: you can do stuff with "dpkg --set-selections" and then "apt-get dselect-upgrade"
[14:45] <persia> mvo: Marking for install won't carry over?
[14:45]  * ogra wonders if a simple dpkg --set-selections couldnt do that
[14:45] <mvo> persia: no, its not permanent
[14:45] <persia> ogra: It can, but that wouldn't be Python :)
[14:45] <ogra> ah, beats me
[14:45] <asac> jcastro: i dont see that we need to choose a different name unless chromium is already registered
[14:45] <persia> mvo: Why not?
[14:45] <mterry> mvo: It would be nice for above use case (prompt to download something that wasn't available at install time).  I tried -set-selections, but update-manager doesn't seem to care
[14:46] <jcastro> asac: ah ok, fair enough, I'm on it. :D
[14:46] <asac> jcastro: and its not really said that thats all "-browser" in the future. maybe chromium-project if we need a new name
[14:46] <mvo> mterry: we could teach update-manager to do something similar as dselect-upgrade, that would actually be useful for more things
[14:46] <mrxmike> anyon?
[14:46] <ogra> mterry, you need the dselect-upgrade call as well
[14:46] <mterry> ogra: Ah, I probably missed that
[14:46] <asac> jcastro: cool. and register its subprojects too :) ... like V8, breakpad ;)
[14:46] <mvo> mterry: right, let me check the code to see how much added work it is/will be
[14:46]  * ogra gives up ... mvo is to speedy :P
[14:46] <jcastro> asac: it is already (the game), so I'm going to go with -browser
[14:46] <jcastro> asac: right
[14:46] <asac> jcastro: please use -project
[14:46] <mvo> persia: good question :) it was never implemented in libapt I guess
[14:46] <jcastro> ok
[14:47] <asac> chrome is the browser
[14:47] <mvo> it would be cool if it would show up as "Previsously suggested installs" or something like that
[14:47] <mrxmike> i feel ignored :(
[14:47] <persia> mterry: You've found an enhancement bug :)  libapt ought set selections permanently, as with dpkg --set-selection.s.
[14:47] <asac> mvo: is it a bug that when you run apt-get upgrade the recommends get marked as seen? e.g. a subsequent dist-upgrade wont install them?
[14:48] <persia> mrxmike: I'm looking up a wiki page for you, but haven't found it yet.
[14:48] <jcastro> asac: should we have a new team for all this or just use mozilla team?
[14:48] <mrxmike> persia: ok, im patient ;)
[14:48] <ogra> mrxmike, https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
[14:48] <persia> Yes.  That's it :)
[14:48] <ogra> :)
[14:48] <asac> jcastro: i dont mind. i would certainly hand over the ownership when such a team is founded
[14:48] <mrxmike> ok im after it, thanks guys
[14:48] <asac> jcastro: so we can go like we did for googlechrome for now
[14:48] <mvo> asac: yes, that sounds like one, but its not trivial to fix :/
[14:49] <ogra> mrxmike, btw #ubuntu-motu is better for such stuff
[14:49] <asac> mvo: ok. thanks for confirming. so in the end recommends should be more strong about enforcing installs
[15:06]  * mok0 wonders if chromium could be built with our ubuntu version of Webkit
[15:08] <pwnguin> mok0: given that they appear to want to track webkit head, probably
[15:09] <pwnguin> it'd be a divergence from upstream though
[15:09] <mok0> pwnguin: agree
[15:10] <asac> wow. scons python part is _really_ CPU hungry
[15:10] <mok0> So, what's the status while I've been away, has a LP project been set up for GC??
[15:10] <asac> mok0: jcastro is on it. the imports will take a while for sure
[15:10] <mok0> asac: great!
[15:11] <broonie> asoc: There are some options you can twiddle if it's an issue
[15:12] <asac> broonie: which option?
[15:12] <asac> i am just running scons Hammer ;)
[15:13] <mok0> https://edge.launchpad.net/googlechrome
[15:13] <asac> mok0: yes. thats just "chrome" tthough
[15:13] <broonie> asac: Decider() in SConscript is one of them.
[15:13] <asac> mok0: we need more
[15:13] <mok0> Actually, it's not called Google Chrome, but Google Chromium
[15:13] <pwnguin> you sure?
[15:13] <asac> mok0: we create a chromium project now
[15:13] <asac> mok0: which hosts the several pieces: chrome, V8, ...
[15:14] <mok0> ah ok
[15:14] <asac> mok0: the project is called "chromium" ... the browser "chrome"
[15:14] <asac> thats my understanding at least
[15:14] <asac> (guessing from how the svn is structured)
[15:14] <pwnguin> so if i were to rebrand firefox as "chrome"
[15:15] <Darklock> ah, so that is why the debian games team wants to change chromium to chromium-bsu :->
[15:16] <asac> they want?
[15:18] <asac> broonie: since you probably know scons a bit ... how can i tell scons to show me the command line the is run for compiling, linking and such`
[15:18] <asac> ?
[15:21] <broonie> asac: I don't remember off the top of my head, sorry. Setting CC or LD to echo would work :/
[15:21] <mok0> Could it be built with ubuntu's scons instead of the local version?
[15:21] <asac> mok0: for me it works
[15:22] <asac> mok0: at least i end in the same nss error that you ;)
[15:22] <mok0> asac hehe
[15:24] <mok0> I filed bug 264713
[15:24] <pwnguin> these build instructions from google are a bit depressing
[15:25] <mok0> pwnguin: you mean the 64 bit stuff?
[15:25] <pwnguin> i mean the part where they have a version of scons in revision control?
[15:25] <mok0> pwnguin: yeah, that's not the way we like it
[15:26] <mok0> pwnguin: apparently, building with ubuntu's scons works
[15:26] <pwnguin> psh
[15:27] <mok0> pwnguin: we should find out which parts to pull out that are relevant for linux, and repackage that in the orig.tar.gz
[15:27] <pwnguin> i keep seeing references to cygwin on the windows side, and thus far ive tried to ignore whatever insanity that way lies
[15:35] <mvo> mterry: please give http://people.ubuntu.com/~mvo/tmp/update-manager-set-selections.diff a try
[15:35] <mterry> mvo: Will do, you speed demon, you
[15:45] <asac> mok0: are you on 64bit?
[15:45] <ScottK> If there's an archive-admin in the house, I'd really appreciate it if they would accept the subversion 1.5 backport in Hardy Backports.  I lot of people are wanting it due to archive format changes.
[15:45] <ScottK> It's Bug #247514
[15:46] <mterry> mvo: It shows up, but isn't checked by default.
[15:47] <Hobbsee> ScottK: looks done already.
[15:48] <mvo> mterry: ok, that is (for now) intentional
[15:48] <mok0> asac: yes
[15:48] <asac> mok0: thats the problem then
[15:48] <asac> mok0: try 32-bit
[15:48] <asac> mok0: everything is explicitly built with -m32 ... so the link against nss will fail
[15:49] <asac> and from what i can see the V8 engine isnt ready yet for 64-bit
[15:49] <mok0> asac: I am trying the guide on: http://groups.google.com/group/chromium-dev/browse_thread/thread/eeb1b3343b4cea6b?fwc=1
[15:50] <mterry> mvo: Oh.  Why?
[15:50] <asac> mok0: you can do that yes.
[15:50] <asac> mok0: but its hackish
[15:50] <mok0> asac: sure is. I filed bug 264713
[15:51] <asac> we probably need to include nss and nspr in ia32-libs and then add kind of -dev package for 32bits
[15:51] <mok0> :-)
[15:51] <asac> mok0: right. but you also need a new -dev, or am i wrong?
[15:51] <mok0> asac: yeah you do; in the guide you just make the symlinks manually
[15:51] <asac> or a pkg-config nss3-32 ;)
[15:51] <mvo> mterry: just to see if it works, if it gets stuff wrong, I don't wanted to mark it for install by default (as it may be wrong)
[15:52] <asac> mok0: let me know how far the build gets with those changes
[15:52] <mok0> asac: right
[15:53] <mterry> mvo: Fair.  Seems to work on my end.  If you end up satisfied with the result, please send me the final patch.  It would be useful for UNR (and eventually normal Ubuntu installer)
[15:55] <mvo> mterry: UNR?
[15:55] <mterry> mvo: Ubuntu Netbook Remix
[15:55] <mvo> aha, cool
[15:56] <mpt> pitti, what are the possible values of "Support status"?
[15:59] <mok0> asac: there's another issue with the missing symlink /usr/lib32/libstdc++.so
[16:04] <pwnguin> mok0: at some point, if everything you link to is 32bit, you're just building a 32bit binary
[16:04] <mok0> pwnguin: I know
[16:04] <mok0> pwnguin: wonder if it would build w/o the -m32 switch
[16:04] <pwnguin> you've got a round hole but chrome is the square peg
[16:05] <mok0> pwnguin: It's beginning to look like it...
[16:05] <mok0> I now have had a couple of issues that are not in the posting
[16:05] <pwnguin> even if it did all work and build, what then?
[16:05] <mok0>    /usr/bin/ld: cannot find -lgcc
[16:07] <mok0> pwnguin: then I get to run some unit tests :-D
[16:07] <pwnguin> ok, as long as you know where you're going ;)
[16:07] <mok0> pwnguin: it is still useful to get all the difficulties mapped out at this time
[16:07] <mok0> it would be great if the browser could appear in time for ii
[16:07] <pwnguin> what, you didn't like their listing?
[16:08] <pwnguin> ii
[16:08] <mok0> Intrepid Ibex...
[16:08] <pwnguin> if i were you, I'd shoot for ubuntu+2
[16:08] <mok0> Hah
[16:08] <pwnguin> as an optimistic goal
[16:09] <mok0> I am probably getting all psyked up here
[16:09] <seb128> mdz: hum, debian/patches/15_usplash.patch is still in the current gdm package I've here
[16:09] <mpt> mok0, your enthusiasm is appreciated, having more browsers is a good thing
[16:09] <mpt> but on Linux at least, Chromium isn't a browser yet :-)
[16:10] <mok0> pwnguin: I guess the problem is that ubuntu doesn't really have a 32 dev environment for x86_64...
[16:10] <mdz> seb128: oh! I accidentally downloaded 2.20.7-3 source when I wanted 2.20.7-0ubuntu5
[16:10] <pwnguin> ive willfully neglected x86_64
[16:10] <seb128> mdz: ah ;-)
[16:10] <mdz> seb128: there must be something else wrong then, it still doesn't start usplash on shutdown
[16:11] <pwnguin> mok0: does multiarch work yet?
[16:11] <mok0> pwnguin: multiarch?
[16:11] <pwnguin> sounds like no
[16:11] <mok0> pwnguin: don't know what it is
[16:11] <seb128> mdz: right, I noticed that too but I'm not sure what is wrong and if that's due to gdm or usplash
[16:11] <mdz> seb128: does it work for you?
[16:11] <seb128> mdz: no
[16:11] <mdz> seb128: sorry for the confusion
[16:12] <seb128> no problem
[16:12] <mdz> seb128: I think at least some of these bugs are dupes but it is hard to tell
[16:12] <seb128> right, it would require some investigation
[16:12] <seb128> too many bugs to look at everything in details
[16:12] <mdz> seb128: I have a fresh intrepid kvm, I'll have a look
[16:12] <mok0> mpt: I think GC is going to work great on Linux, given the multiprocess design
[16:12] <seb128> mdz: maybe try to install the hardy gdm and see if that makes a difference
[16:12] <pwnguin> mok0: im not sold on multiprocess
[16:13] <mok0> mpt: and with multicore machines it will really rock
[16:13] <mok0> pwnguin: why?
[16:13] <pwnguin> if threads are also called light weight processes, this means regular processes are "heavy"
[16:13] <mok0> pwnguin: I'm not really sold on threads :-)
[16:14] <mdz> seb128: I'll also try to find out why usplash pulsates on bot
[16:14] <mdz> boot
[16:14] <cjwatson> it might be better to examine the actual implementation rather than the name
[16:14] <mdz> it needs some love
[16:14] <mpt> pitti?
[16:14] <mok0> pwnguin: Linux is really quick at creating processes
[16:14] <mterry> mvo: With your patch, after I did an update (but didn't install the "Previous Selected" package), further runs of update-manager don't show the package anymore
[16:14] <mok0> pwnguin: especially after 2.6
[16:14] <mpt> ah, he's out
[16:14] <mterry> mvo: It prints it on the command line, but not in the UI
[16:15] <mvo> mterry: oh, interessting. let me check
[16:15] <pwnguin> mok0: there's cache considerations as well, and memory mapping costs
[16:16] <mok0> Hmm. Any suggestions for the missing -lgcc?? I have the feeling it's the last one needed
[16:16] <mok0> pwnguin: If you created 1000's of processes, it might be noticable, but not with something O(10) like a browser
[16:17] <mok0> pwnguin: In my winxp virtual machine, tab creating is instantaneous
[16:18] <mok0> pwnguin: ... and linux is faster at creating a process than winxp
[16:18] <pwnguin> exactly how many tabs do you open, and how often?
[16:18] <cjwatson> the "lightweight processes" name comes from OSes where creating processes has not been so ridiculously optimised
[16:18] <mok0> pwnguin: once a minute?
[16:18] <cjwatson> pwnguin: you're the one who brought up processes being heavyweight ...
[16:19] <jdstrand> pitti: hi!
[16:19] <pwnguin> theres more to life than being born. similarly, theres more to processes than creation
[16:19] <seb128> kees: $ find . -name *.build | xargs grep "warning: format not" | wc -l
[16:19] <seb128> 916
[16:19] <seb128> kees: that's my packaging directory
[16:19] <mok0> Threads make sense if you have a different type of process going on that you want to escape from, say a download window.
[16:20] <jdstrand> pitti: I recently saw that clamav was promoted to main, but was hoping that an enforcing apparmor would be a prerequisite for its inclusion
[16:20] <pwnguin> mok0: actually, processes make sense there, to me
[16:20] <pwnguin> the benefit of threads is shared address space
[16:20] <mok0> For GC, the processes for each tab are identical; then there's a process that manages it all
[16:20] <cjwatson> pwnguin: I think (a) you should hold off on serious comment until you've benchmarked, otherwise it's just blowing smoke (b) you may well find that the other benefits of memory separation between tabs outweigh some minor performance disadvantages
[16:20] <jdstrand> pitti: I talked with ScottK about it some, but this didn't happen before promotion.
[16:21] <mok0> cjwatson: easy, we are having a friendly chat here...
[16:21] <cjwatson> I don't think it's unfriendly to say that serious discussion of performance should be based on genuine data
[16:21] <cjwatson> that's an axiom of performance engineering
[16:21] <mok0> kk
[16:21] <jdstrand> pitti: my plan is to provide a debdiff for it, then ScottK will check it with amavis-new, and then a FFe for it
[16:22] <mok0> Anyway, I am impressed with GC
[16:22] <jdstrand> pitti: I think it's really important considering its history and the nature of what it does
[16:22] <mok0> But I need to get the -lgcc problem solved
[16:22] <pwnguin> cjwatson: before benchmarking, you should decide what's important to measure.
[16:23] <cjwatson> pwnguin: sure, but when faced with a case where somebody apparently has done the benchmarking, it makes sense to find out more about what they did rather than ignoring it
[16:23] <mok0> cjwatson: interestingly, when looking at the gossip of the Internet, people come to wildly different results comparing GC to IE8
[16:23] <pwnguin> has someone done the benchmarking?
[16:23] <cjwatson> Google, internally
[16:23] <cjwatson> (that much is fairly clear)
[16:23] <mok0> pwnguin: I've seen several referenced at digg
[16:23] <pwnguin> i didnt get that impression
[16:23] <pwnguin> ive seen some benchmarks of v8
[16:24] <mok0> pwnguin: I think Google wants to do STUFF with javascript...
[16:24] <iamfuzz> slangasek, ping
[16:24] <mok0> pwnguin: so they need a really fast engine
[16:25] <jdstrand> pitti: also, it was brought to my attention that dbgsym packages are not created when going through -security in dak. has asac mentioned this to you? (this was noticed with the recent ff et al updates)
[16:25] <iamfuzz> pitti, or ping
[16:25] <pwnguin> mok0: and if they test v8 standalone, how does that reflect on the thread versus process choice?
[16:25] <mok0> pwnguin: don't knpw
[16:26] <cjwatson> of course, the other major axiom of performance engineering is that correctness is more importance than performance
[16:26] <pwnguin> i tell students that, but deep down i know it's not true
[16:26] <cjwatson> Google may well simply have decided that correctness is unlikely to be achievable with threads when other people's code is concerned; I don't know many people who've read the POSIX threads spec who'd disagree :)
[16:26] <mok0> cjwatson: apparently, they've set up an automatic rendering system based on their cache of the internet
[16:27] <mok0> cjwatson: Given IE8 is also process based, it seems MS has come to the same conclusion
[16:27] <pwnguin> theres tons of research on bounding optimization problems while still terminating in our lifetimes
[16:28] <mvo> mterry: hm, strnage. that seems to work for me, what is the output of "apt-cache policy pkgname" for that pkgname you put into --set-selections?
[16:28]  * mok0 brain panic... rebooting
[16:28] <pwnguin> from what i can tell, google's decided that flash tanking a tab rather than a browser is worth the penalties in both CPU and RAM
[16:29] <pwnguin> I'm inclined to agree
[16:29] <cjwatson> they also included a bunch of stuff about fragmentation in their announcement though; I don't think the RAM penalties are as obvious as they seem in a naive analysis
[16:29] <pwnguin> that fragmentation stuff was bogus
[16:29] <ion_> pwnguin: AFAIU, the tab is actually a separate process from the plugins running in it.
[16:30] <mok0> What is libgcc_s ??
[16:31] <mok0> ls
[16:31] <mterry> mvo: http://pastebin.ubuntu.com/43371/
[16:32] <cjwatson> pwnguin: that's a very bold declaration given that mozilla developers have attributed memory problems at least partially to the same cause
[16:32] <kees> seb128: yup, there are a lot of warnings to dig through -- not all are security issues, but they're all bugs.
[16:32] <kees> seb128: and in many ways, there's a reason I only set that to a warning.  :P
[16:33] <seb128> kees: right, just giving you some datas before you consider settings that as an error ;-)
[16:33] <pwnguin> cjwatson: external fragmentation is a misfeature of conservative GC, but from what I've read, none of the major browsers use it for javascript
[16:33] <mok0> cjwatson: you mean, that the apparent memory leaks was in fact resulting from fragmentation (in mozilla)?
[16:34] <cjwatson> pwnguin: I don't think I mentioned JavaScript
[16:34] <cjwatson> http://blog.pavlov.net/2007/11/10/memory-fragmentation/ for example
[16:35] <kees> seb128: agreed :)
[16:35] <seb128> good ;-)
[16:35] <seb128> I've to go, see you later
[16:36] <pwnguin> cjwatson: i'm pretty sure the comic mentioned how their javascript engine was fast because of incremental gc
[16:36] <mok0> pwnguin: I don't think it was only that
[16:37] <cjwatson> pwnguin: javascript issues are separate from the benefits of separate processes for avoiding fragmentation
[16:37] <mok0> pwnguin: it is also using a JIT compilation
[16:38] <pwnguin> arg
[16:38] <pwnguin> how's this for ironic? http://www.google.com/googlebooks/chrome/ doesn't work right in chrome
[16:39] <mok0> ha
[16:40]  * mok0 boots up his winxp VM to test this assertion :-)
[16:41] <asac> the mozilla JS engine also gets JIT this round
[16:42] <asac> i think its not yet enabled by default in the latest 3.1 alpha, but you can enable it using a build flag afair
[16:43] <pwnguin> ok, well on rereading that fragmentation thing, it's kind of a bad argument that I misread. i thought it was talking about javascript, but it's about the general C++ problem
[16:43] <pwnguin> personally, i think processes is a bad solution, but if you need them anyways to isolate failure, i guess it's a neat win
[16:44] <mdz> cjwatson: bug 255008 seems to have regressed :-(
[16:44] <mok0> pwnguin: I don't see anything wrong with that comic...
[16:44] <mdz> slangasek: ^^
[16:45] <mpt> hi pitti
[16:45] <pitti> hi mpt
[16:46] <mpt> pitti, what are the possible values for "Support status"?
[16:46] <pitti> mpt: ATM I have
[16:46] <pitti> Tested by the %s developers
[16:46] <pitti> Third party driver, not tested by %s developers
[16:46] <pitti> Third party driver, tested by %s developers
[16:46] <ScottK> Hobbsee: I'd just uploaded it then, it may not have been there yet.  I have waiting for approval, but no indication it was accepted.
[16:46] <pitti> (wording improvements appreciated)
[16:47] <pitti> mpt: I want to differ between Ubuntu supplied drivers, ubuntu certified third-party drivers, and community drivers without any stamp on them
[16:47] <cjwatson> mdz: in kvm, or outside?
[16:47] <mpt> pitti, ok, next question: What are the possible values for "License"?
[16:47] <cjwatson> pwnguin: it's hardly a C++ problem
[16:47] <mdz> cjwatson: I tested in kvm, but a submitter of a dupe doesn't mention it being in kvm
[16:48] <pitti> mpt: "Free" and "Proprietary"; for the latter I enable the License button if the driver has a license text associated with it (as for e. g. the ones in openprinting.org)
[16:49] <mpt> pitti, I didn't know Free drivers showed up in this window at all
[16:49] <pitti> mpt: they are supposed to, yes
[16:49] <pwnguin> cjwatson: sure. the same problem can happen with malloc as it can with new ;)
[16:49] <mdz> cjwatson: and only when I forget the -k switch, argh
[16:49] <pitti> mpt: and in fact, with the recent addition of looking for drivers on openprinting.org, that actually works, too
[16:52] <mpt> neat
[16:54] <mpt> pitti, when a third-party driver has not been tested by the %s developers, is it always because it's proprietary? Or are there other reasons?
[16:54] <pitti> mpt: it's not tied to the license
[16:55] <pitti> mpt: if we have a driver in the ubuntu repo, it is the first case
[16:55] <pitti> mpt: if the driver is from openprinting.org, it is the third
[16:55] <mpt> ahhhh
[16:55] <pitti> mpt: erm, second case, I mean
[16:55] <mpt> So an openprinting.org driver might be Free, but not reviewed
[16:55] <pitti> mpt: and if our QA tests and blesses it, we can put a stamp on it and set it to the third case
[16:56] <pitti> mpt: exactly
[16:56] <pitti> mpt: we don't have a vehicle to bless drivers from openprinting.org, BTW, but we will with the upcoming online distro driver db
[16:56] <pitti> (nothing to worry about for intrepid, so we just have the first two strings for now)
[16:57] <mpt> I'm thinking of putting the review status into the description pane, similar to the maintenance status in Add/Remove Programs and Synaptic
[16:57] <pitti> mpt: it could also be a driver which a community member ships in a PPA
[16:57] <mpt> and wondering whether it would be appropriate to put the license info in there too
[16:57] <mpt> that would make it less visible
[16:57] <mpt> so more awkward for someone who really wants to have only Free drivers
[16:57] <pitti> mpt: entirely doable, of course, but I'd like to put an emphasis on at least the support status
[16:58] <pitti> mpt: btw, jockey has a mode to only present restricted or only free drivers
[16:58] <pitti> but not switchable in the UI yet, just a CLI argument
[16:58] <mpt> hm
[16:58] <pitti> mpt: they could become the first two lines in the description panel, but that wouldn't save a lot of space and might be more difficult to read?
[16:59] <mpt> pitti, I was thinking at the end, like with the maintenance status
[17:02] <pitti> mpt: hm, it might get scrolled off the visible text part
[17:02] <mpt> exactly
[17:03] <mpt> so if it's important stuff, it shouldn't be at the bottom like that
[17:03] <dholbach> Ubuntu Developer Week Sessions start now: #ubuntu-classroom
[17:03] <mpt> the question is how important it is
[17:03] <mpt> pitti, where a driver has been reviewed by Ubuntu developers, why would someone care whether it's an Ubuntu driver or a third-party one?
[17:04] <pitti> mpt: they probably wouldn't, right
[17:04] <pitti> mpt: so maybe we could drop the "Third party driver" part
[17:04]  * pitti is dragged to dinner, bbl
[17:04] <pitti> mpt: I'll catch up here later
[17:05] <mpt> ok, thanks for your answers :-)
[17:05] <pitti> mpt: thanks muchly for your input
[17:08] <IntuitiveNipple> I've just added sys file-system support to qemu/kvm, but to make it accessible to users it will need a udev group ownership set on /dev/bus/usb/* devices. I was wondering if "plugdev" would be an appropriate group, or create a new one? I don't think kvm/qemu should have to run as root to access USB devices.
[17:19] <anilg> is this the right place for an aptitude package question
[17:19] <anilg> a build issue.
[17:20] <LaserJock> what package(s) would be responsible for resume/suspend?
[17:20] <azeem> uh-oh :)
[17:21] <mpt> LaserJock, my almost-entirely-uninformed guess would be acpi-support
[17:21] <LaserJock> suspend/resume stopped working for me (requires hard reboot)
[17:21] <IntuitiveNipple> LaserJock: pm-utils ?
[17:21] <LaserJock> initially I thought maybe it was .26 -> .27 kernel issue but I reboot with with .26 and got the same thing
[17:22] <IntuitiveNipple> Laserjock: Do you have the uvcvideo module set to be unloaded on suspend? That's a well-known culprit :)
[17:23] <cjwatson> pitti: tested by the %s developers> you know that may be a translation problem?
[17:23] <LaserJock> IntuitiveNipple: how would I know?
[17:24] <LaserJock> the screen goes blank and the keyboard no longer responds, but it seems like it's still running (I see occasional hard drive LED flashes)
[17:25] <IntuitiveNipple> LaserJock: check /etc/default/acpi-support for  MODULES="uvcvideo" and similar
[17:26] <LaserJock> IntuitiveNipple: MODULES is empty
[17:26] <IntuitiveNipple> I've also found recently one of the USB drivers hangs things, so I add that too (commentary says USB drivers are unloaded, but they aren't any longer)
[17:26] <cjwatson> pitti: in French, something like "par les developpers d'Ubuntu" (or whatever the word for developers is) vs. "par les developpers de Fedora" ... at least potentially, not sure if French translators would actually translate it that way
[17:26] <IntuitiveNipple> LaserJock: does the PC have uvcvideo loaded ? If so, add it to that setting and it'll be unloaded on suspend
[17:27] <cjwatson> pitti: you'll also need to take into account cases where the word "Ubuntu" is translated
[17:27] <LaserJock> IntuitiveNipple: lsmod says ucvideo is loaded, I'll give it a try
[17:29] <IntuitiveNipple> Do we have a 'recommended' group for giving VMs access to system services?
[17:31] <LaserJock> IntuitiveNipple: yeah, that didn't help :)
[17:31] <IntuitiveNipple> LaserJock: Possibly the USB module I mentioned... let me dig out which one it is
[17:33] <IntuitiveNipple> LaserJock: I *think* it was "ehci_hcd" or "hci_usb", but I'd have to trawl to find it.
[17:33] <jdong> those hurt a lot more to unload :)
[17:34] <IntuitiveNipple> I only noticed it recently with a Hardy issue.
[17:34] <ogra> LaserJock, /etc/default/acpi-support isnt used since hardy anymore
[17:35] <LaserJock> don't tell me I have to edit some HAL .fdi file :-)
[17:35] <ogra> LaserJock, you want /etc/pm/config.d ... create a file in there (i.e. "default") and put in: SUSPEND_MODULES="uvcvideo"
[17:36] <ogra> that would unload uvcvideo on suspend and reload it on resume
[17:37] <IntuitiveNipple> ogra: Some systems do have it, especially those that upgraded. Best thing is to check if the /etc/rc2.d/S99acpi-support symlink is there
[17:37] <ogra> that would be a massive bug then
[17:38] <ogra> there should have been a transition from acpi-support to pm-utils
[17:38] <IntuitiveNipple> Laserjock indicated that the /etc/default/acpi-support file was present so the package appears to be installed
[17:38] <ogra> (but i dont maintain powermanagement stuff anymore luckily ... so i dont know if the transition went properly)
[17:38] <ogra> sure
[17:38] <ogra> but that doesnt mean its used
[17:39] <IntuitiveNipple> indeed, hence the rc2.d question. Thinking about it, he didn't say what release he's using :)
[17:41] <LaserJock> hmm, same
[17:41] <LaserJock> ogra: do you have to restart anything after making a file in /etc/pm/config.d/ ?
[17:41] <kees> dholbach: thank you again for harvest.  made finding fedora's un-upstreamed patches for dvd+rw-tools a snap.  :)
[17:41] <IntuitiveNipple> I have the pm-utils settings, with /etc/pm/config.d/modules_unloads with the contents SUSPEND_MODULES="iwl3945 r5u870 uvcvideo ehci_hcd"
[17:41] <dholbach> kees: gracias :)
[17:42] <dholbach> kees: or.... "thanks for the flowers"
[17:42] <ogra> LaserJock, no, pm-suspend will just use it
[17:42] <pitti> cjwatson: tricky indeed; we have a similar case in the dialog title, too; thanks for pointing out
[17:43] <pitti> jdong: known to me, and I mailed infinity about it the other day
[17:43] <pitti> iamfuzz: hi
[17:43] <kees> dholbach: hehe, you're welcome.  :)   actually, if I click on "mark reviewed", harvest falls over
[17:43] <kees> dholbach: i.e. I'm here: http://daniel.holba.ch/harvest/handler.py?pkg=dvd+rw-tools  and I'm clicking the wctomb patch
[17:44] <dholbach> kees: can you send a patch? .... bug report? :-)
[17:44] <dholbach> kees: I'll dive into it probably tomorrow or next week, quite busy
[17:45] <NCommander> kees, so I discovered a rather interesting pain in building a PIEd compiler due to circular dependencies on glibc, libgmp, and libgcc :-)
[17:45] <kees> dholbach: sure
[17:45] <dholbach> thanks kees
[17:45] <kees> NCommander: heh
[17:46] <NCommander> kees, I did make the right call though, GCC can't be built PIEd with your wrapper because of its bootstrapping methodology, you need to manually set the CFLAGS
[17:46] <mdz> does anyone know if there's a bug filed about the intermittent usplash pulsating during boot?
[17:46] <LaserJock> IntuitiveNipple: SUSPEND_MODULES="iwl3945 uvcvideo ehci_hcd" didn't work either
[17:47] <kees> mdz: I thought that was an intentional change by pitti during the fsck
[17:48] <IntuitiveNipple> LaserJock: There might be other modules responsible (check lsmod and guess!) or it might be that something else entirely is the cause. Might need to enable ACPI debugging
[17:48] <mdz> kees: was it?  it doesn't look right
[17:48] <mdz> and it happens even when no fsck is required
[17:48] <LaserJock> IntuitiveNipple: darn, I was hoping for an easy fix
[17:48] <mdz> pitti: is it true?
[17:49] <IntuitiveNipple> LaserJock: suspend/resume is rarely easy!
[17:49] <kees> mdz: I cannot confirm it was intentional, or that is is the fsck and it goes by very quickly, but that is what I suspect.
[17:50] <IntuitiveNipple> mdz: do you have a moment to give some guidance on LP bug #156085 (sys fs for kvm/qemu etc.) ?
[17:50] <mdz> IntuitiveNipple: how can I help?
[17:51] <mdz> kees: confirmed, it calls splash_start_indefinite before fsck
[17:51] <kees> mdz: okay, cool.
[17:52] <IntuitiveNipple> mdz: In the bug you pointed to a patch at Novell, and I've taken that as a basis and added sys fs support on top of existing /proc/ and dev/ support. I just need some guidance on group ownership for the usb devices which are currently root:root since otherwise kvm/qemu will have to run as root. I looked at plugdev, but wondered about a new one for all VMs, maybe "vm" or "virtualmachines"
[17:52] <mdz> IntuitiveNipple: pitti is the person to talk to about that; it's recently changed quite a bit
[17:53] <IntuitiveNipple> mdz: Ok, thanks.
[17:53] <IntuitiveNipple> pitti: over to you when you're free :)
[17:53] <ogra> IntuitiveNipple, there is also a patch on bug 159189
[17:53] <ogra> that might give some hints
[17:57] <IntuitiveNipple> ogra: Can't see anything about permissions in there.
[17:57] <pitti> mdz, IntuitiveNipple: linux foundation conf call, can we talk later?
[17:58] <pitti> IntuitiveNipple: in short, /dev/kvm uses the 'kvm' group; we didn't change that, kvm isn't PolicyKitified ATM
[17:58] <ogra> IntuitiveNipple, no, but about switching from usbfs to sysfs
[17:58] <pitti> IntuitiveNipple: anyway, will read backlog later
[17:58] <IntuitiveNipple> pitti: thanks, yeah, shout me when you're free
[17:59] <IntuitiveNipple> ogra: The support for sys fs is done, its just a case of correct permissions to allow non-root access to the USB devices in /dev/bus/usb/*/*
[17:59] <ogra> ah, k
[18:00] <IntuitiveNipple> ogra: I was just thinking whilst I'm at it, adopt a generic group that can be used for all VMs such as kvm, qemu, vbox, etc/
[18:01]  * ogra doesnt ude vbox with usb support ... so i cant judge that ...
[18:01] <IntuitiveNipple> The biggest gripe currently is lack of decent USB support, and now it's coming through from upstream it would be good to support it as painlessly as possible
[18:02] <ogra> and i only use vbox usually, so i cant judge the others ... soren would be the right person for general virtualization discussions i think
[18:02] <IntuitiveNipple> yeah, good point. I'll email him
[18:11] <slangasek> mdz: 255008> yes, I see that Jan Rathmann has appeared now - good, he had linked this bug from his ISO testing but I couldn't find him
[18:11] <mdz> slangasek: my reproduction of it seems to have been bogus; it is actually the kvm/evdev issue I stumbled on
[18:11] <mdz> slangasek: it's working OK for me on real hardware atm
[18:14] <slangasek> iamfuzz: pong
[18:14] <iamfuzz> sladen, got cprov helping me, thx
[18:14] <slangasek> mdz: ok, thanks for the info
[18:23] <Cycom> are bugfixes still taking place for 8.04?
[18:24] <mdz> slangasek: I filed bug 264696 and bug 264767 as visual issues which should nonetheless be fixed before final
[18:25] <mdz> Cycom: yes, but selectively (only high-impact / low-risk backports)
[18:27] <Cycom> mdz: I ask because there is a bug, possibly in evdev, possibly in kernel, for 8.04  that was closed as 'fix released' because the bug doesn't appear in 8.10.
[18:28] <Cycom> Basically, when you click and hold your mouse, instead of a mousedown event, hold, mouseup, it sends a stream of mousedown events.  This prevents you from doing things like click and drag, etc. Is that high impact enough to reopen?
[18:29] <kees> dholbach: say, can you replace the universe-contributors icon with this one, which has transparency: http://outflux.net/wrench_emblem-trans.png
[18:29] <dholbach> kees: can you ask in #ubuntu-motu - in UDW session right now
[18:30] <tormod> where is udev maintained? the bzr branches on launchpad are all very old
[18:30] <kees> dholbach: ah, sure, thanks.
[18:31] <RainCT> mvo: ping
[18:33] <mpt> pitti, I've e-mailed you my sketches -- the bottom is what I think it probably should look like
[18:35] <mpt> pitti, let me know if that should be on the wiki anywhere
[18:42] <pitti> mpt: thanks
[18:43] <pitti> IntuitiveNipple: re
[18:43] <pitti> IntuitiveNipple: so, what's your Q?
[18:43] <IntuitiveNipple> pitti: emailed :)
[18:44] <pitti> IntuitiveNipple: I saw the response to bug 156085, if you mean that
[18:44] <slangasek> cody-somerville: looks like more coverage is still needed for xubuntu amd64?
[18:45] <IntuitiveNipple> pitti: I emailed you and Soren a few minutes ago
[18:45] <slangasek> _MMA_: ping, now that we have a kernel, is UbuntuStudio looking good for alpha-5?
[18:45] <IntuitiveNipple> pitti: your ubuntu.com address
[18:45] <slangasek> _MMA_: and if so, is someone working on ISO testing?
[18:46] <pitti> IntuitiveNipple: ok, will reply soon, thanks
[18:46] <mdz> Cycom: generally speaking, we make most bugfixes available through our new releases
[18:46] <_MMA_> slangasek: I am as much as I can atm. Im starting a new job today and am a bit busy with preppin' for that. Ill make sure someone is on it.
[18:46] <mdz> Cycom: we only backport bugfixes to an existing release in certain cases where it's justified
[18:47] <slangasek> _MMA_: ok - when you have someone on it, can you put them in touch with me, so I know where we are in the test cycle?
[18:47] <_MMA_> SUre.
[18:48] <unstable> Is there a dbus event for detecting whether or not a cable is plugged into my ubuntu machine?
[18:48] <unstable> I don't run gnome, I have some custom scripts that run, and I want to be alerted when a cable plugs into my ubuntu machine, anyone that can help/advise me on the best way to be alerted?
[18:48] <pitti> unstable: ITYM an ethernet cable? :-)
[18:49] <unstable> yea, ethernet cable
[18:49] <mdz> slangasek: I didn't reopen 255008 because I'm not sure what to do with it
[18:49] <mdz> slangasek: I think maybe my original impulse of directing him to his own bug and un-duping was perhaps the right course
[18:50] <pitti> unstable: network-manager reacts to this, I'm fairly sure it just listens to a hal event
[18:51] <pitti> unstable: I don't know it off the back of my hand, but try running "dbus-monitor --system" and plug in the cable, and see what happens
[18:55] <pitti> mpt: it looks nice and clean; the only thing I don't really like is putting the license and status into the bottom part of the text field, since it scrolls off
[18:55] <pitti> mpt: so you entirely want to get rid of the enabled/disabled colums in the tree view?
[18:55] <slangasek> mdz: right; I don't see any clearly better options
[18:56] <calc> slangasek: when will the archive be safe to upload again, any idea?
[18:56] <calc> i'm planning on doing an OOo upload right after the cds are done
[18:56] <pitti> mpt: s/license and status/license and support status/
[18:57] <slangasek> calc: we still have a number of outstanding tests, I think it would be best if you assumed "tomorrow"
[18:57] <pitti> mpt: also, I think it is at least currently not feasible to entirely merge enabling and "in use"
[18:58] <calc> slangasek: ok thats fine :
[18:58] <calc> :)
[18:58] <calc> slangasek: i assume its safe to do when the email announcement goes out as well?
[18:58] <slangasek> yes
[18:58] <calc> ok
[18:58] <calc> if i happen to see it before then i will upload at that time
[18:58] <mpt> pitti, I think it would be useful to have an icon-only in-use column, using (smaller versions of) the same icons as the explicit in-use-or-not text underneath
[18:59] <mpt> pitti, I'm sorry, I've forgotten what the difference is between "enabled" and "in use"
[19:00] <pitti> mpt: enabled -> install this driver and allow it to be used
[19:01] <pitti> 'in use' -> driver is used by some hardware right now
[19:01] <pitti> mpt: e. g. install the nvidia driver -> enabled, but not in use
[19:01] <mpt> ah
[19:01] <pitti> restart X -> enabled an in use
[19:01] <mpt> hm
[19:01] <pitti> have a broadcom wifi
[19:01] <mpt> pitti, do you always need to restart the computer for a driver to become in use?
[19:01] <mpt> or to become enabled?
[19:02] <pitti> mpt: no, most kernel modules "just work"
[19:02] <mpt> ok...
[19:02] <pitti> e. g. the b43 firmware, too
[19:02] <pitti> mpt: however, you always need a computer restart to disable a driver
[19:02] <knix> You need to start X for a new graphics driver
[19:02] <mpt> pitti, so whether a driver is in use is interesting information for deciding whether it should be enabled
[19:02] <pitti> e. g. uninstall nvidia -> disabled, but still in use
[19:02] <pitti> reboot -> disabled and not in use
[19:03] <mpt> oh, I see
[19:03] <mvo> RainCT: pong
[19:04] <mpt> hmmmmm
[19:05] <mpt> The problem is that whether something is "enabled" usually isn't something humans are interested in
[19:05] <pitti> mpt: I hate this very technical distinction as well, but we are kind oof stuck with it
[19:05] <mpt> Usually it can be reworded in a way that humans are interested in
[19:05] <mpt> But in this case, I'm not sure
[19:06] <mpt> What is the effect of a driver that is enabled but never used?
[19:06] <pitti> mpt: people might disable nonfree drivers because they don't like them, or so
[19:06] <pitti> mpt: it just won't work, and just sit there
[19:06] <mpt> Does it make the computer slower?
[19:06] <pitti> no, it won't,just takes disk space
[19:06] <pitti> and of course could create political issues
[19:07] <mpt> sure
[19:07] <pitti> having the nvidia proprietary driver isntalled and not in use is already bad in some cases
[19:07] <mpt> What effects does that have?
[19:07] <pitti> well, you get infested with non-free software :)
[19:07] <pitti> (which is why we don't install those by default)
[19:08] <mpt> but just to be clear here
[19:08] <mpt> This Hardware Drivers window doesn't actually install and uninstall drivers, does it?
[19:08] <pitti> it does
[19:08] <mpt> It does?
[19:08] <mpt> oh.
[19:09] <pitti> sure, it installs the packages, configures xorg.conf for nvidia, etc.
[19:09] <pitti> or, if you disable a driver, it uninstalls packages again
[19:09] <pitti> or, e. g. for the broadcom case, it instlals/removes the firmware
[19:09] <pitti> (the kernel module is shipped by default, nothing is installed there)
[19:10] <mpt> So a driver can be * not installed at all, * installed but blocked from ever being used, * installed but not used right at the moment, * installed and used right now.
[19:10] <mpt> Is that accurate?
[19:11] <mpt> Or is the second option impossible in the package management scheme?
[19:12] <tseliot1> mpt: if you blacklist a kernel module then yes
[19:12] <tseliot1> it is possible
[19:14] <mpt> ok
[19:15] <mpt> So, my design is mostly wrong
[19:17] <tseliot1> mpt: the "In use" label covered this case too
[19:18] <slangasek> it's possible that someone can blacklist a kernel module, but is that something that's meant to be handled through this interface?
[19:19] <emgent`nl> good evening
[19:20] <mpt> I guess the correct design will occasionally feature the sentence "This driver is turned on but not currently being used."
[19:20]  * mpt needs to think about this more :-)
[19:20] <tseliot1> slangasek: this is exactly what I was about to ask. AFAIK you can't do that in Jockey (yet) but I don't see why you couldn't. It wouldn't be difficult to implement.
[19:20] <LaserJock> ogra: hmm, it turns out my laptop also acts funny when the screensaver is activated
[19:20] <tseliot1> emgent`nl: good evening
[19:21] <slangasek> tseliot1: I'm not sure why it's desirable to implement; adding to the list of available states complicates the UI, if nothing else
[19:21] <emgent`nl> heya tseliot1 :)
[19:21] <LaserJock> so does suspend,hibernate, and the screensaver all get tied together somewhere? gnome-power-manager perhaps?
[19:21] <slangasek> LaserJock: yes, g-p-m touches all of the above
[19:21] <LaserJock> slangasek: ok, interesting
[19:21] <tseliot1> slangasek: I said that I didn't see the reason why you couldn't, not the reason why you shouldn't ;)
[19:22] <LaserJock> for a while g-p-m was crashing a lot
[19:22] <LaserJock> after updates it's not crashing, but I get a unusable computer ;-)
[19:27] <slangasek> tseliot1, superm1: do you think either of you could give me a release-noteable blurb about why DKMS is good for users?
[19:28] <superm1> slangasek, yeah i suppose i could.  how soon do you need it?
[19:29] <slangasek> superm1: if you have it for me today it goes in the alpha-5 technical overview, if you don't, it doesn't :)
[19:29] <superm1> slangasek, okay i'll try to write a short snippet this afternoon
[19:32] <ScottK> slangasek: Would you have a moment to accept the subversion backport in hardy-backports?  Due to archive incompatibilities I think it's important to get it out the door.  It's Bug #247514
[19:34] <pitti> mpt: re
[19:35] <pitti> mpt: right, 2 can happen as well; also, if you have a driver isntalled which does not match any installed hardware
[19:36] <slangasek> ScottK: done
[19:38] <ScottK> slangasek: Thanks.
[19:39] <superm1> slangasek, how's this: http://paste.ubuntu.com/43439/
[19:54] <tseliot1> +1 to superm1's description
[19:58] <jdstrand> pitti: hi! did you see my earlier queston re: dbgsym and dak?
[19:58] <pitti> hey jdstrand
[19:59] <pitti> yes, I thuoght I answered?
[19:59] <jdstrand> oh, I must have missed it :)
[19:59] <pitti> jdstrand: oh, about clamav and apparmor? sorry, I missed that
[20:00] <jdstrand> pitti: the apparmor/clamav was more of a commentary/plan
[20:00] <pitti> jdstrand: argh, completion error; [18:43]     pitti| jdong: known to me, and I mailed infinity about it the other day
[20:01] <pitti> sorry, jdong
[20:01] <jdong> no worries :)
[20:01] <jdstrand> pitti: ok cool. thanks!
[20:01] <jdstrand> asac: ^
[20:05] <balachmar> tkamppeter: So it is fine if I would use the patch to fix the bug 258421? Just wanted to make sure. (BTW I will read the logs to find out your answer :) ) Then I will make that my first attempt to fixing a bug.
[20:12] <pitti> mpt: hm, so shall I take your proposal with retaining the enabled/in use columns in the treeview for now?
[20:13] <mpt> pitti, I have the wording wrong and might be missing some elements
[20:13] <mpt> because I was confused about enabled vs. in use
[20:13] <mpt> pitti, do you want to get this finished quickly, or can it wait till tomorrow?
[20:13] <pitti> mpt: oh, it can definitively wait some days
[20:13] <pitti> mpt: I'm hacking in the code, and the thing I'm working on is not blocked on this
[20:14] <pitti> also, I'm about to go to bed soon anyway
[20:14] <mpt> ok
[20:14] <pitti> mpt: thanks a lot!
[20:16] <Cycom> mdz: I got home and saw your comments from earlier.  While I understand that the new releases are the primary vehicle for bugfixes, the new release isn't out yet, or even BETA yet.  To write off a bug as FIXED in an existing release, especially a LTS release, seems worriesome.
[20:27] <blisto1> hey, anyone know why the gnome file browser no longer gives an option for authentication info for samba shares?
[20:27] <blisto1> This is killing our 300 users.
[20:27] <blisto1> Worked up until a few weeks ago.
[20:27] <pitti> good night everyone
[20:29] <cody-somerville> slangasek, I have some folks who say they're working on it
[20:57] <slangasek> superm1: thanks, I think I'll try to find a way to say the same thing in fewer words, but that's a good starting point :)
[20:57] <superm1> slangasek, that was actually already a reduction from what i wrote :)
[20:57] <slangasek> :-)
[21:08] <sebner> seb128: ahoi! I was looking for you :D
[21:08] <seb128> hi sebner
[21:08] <sebner> seb128: I just saw your gdm update
[21:09] <seb128> which one?
[21:09] <seb128> the new version in intrepid?
[21:09] <sebner> seb128: yep
[21:09] <seb128> any issue there?
[21:10] <sebner> seb128: it's a stable new upstream. I thought gdm rewrite is finished with gnome 2.24 and I was wondering why you don't update to latest developement release 2.23.90 (too dangerous) ?
[21:11] <seb128> sebner: read the discussions on the upstream mailing list, I posted a summary of the issues the new version has in my opinion there some weeks ago, also note that GNOME didn't decide to use the new version either
[21:11] <seb128> sebner: one issue is that the new version has no graphical configuration tool, so either you use gconf to change option or you don't
[21:11] <sebner> seb128: so new target is 2.26?
[21:11] <seb128> it also has no xdmcp, no graphical themes, etc
[21:12] <seb128> sebner: GNOME is discussing it at the moment
[21:12] <seb128> read the upstream lists for details
[21:12] <sebner> seb128: so the rewrite seems not really finished =)
[21:12] <seb128> sebner: do you think we should update?
[21:12] <seb128> well, it's working, but it's less flexible than the previous version
[21:13] <seb128> since there is no strong advantage in the new code I don't see a reason to hurry in something which is less flexible and tested
[21:13] <sebner> seb128: well shouldn't a rewrite (started with 2.20 I think) be *better* than the old one? ^^
[21:13] <seb128> sebner: the code is better and it's getting there for sure, I just think it's not there yet
[21:14] <seb128> maybe next cycle
[21:14] <sebner> seb128: kk, just wanted to know that. thx for the infos :)
[21:14] <seb128> you're welcome
[21:27] <RainCT> it's a bit off-topic but, does someone know how I can align the text in a GtkLabel to the right?
[21:29] <IntuitiveNipple> RainCT: How about gtk_misc_set_alignment() ?
[21:31] <RainCT> IntuitiveNipple: that's it. Thanks!
[21:32] <IntuitiveNipple> cool
[21:51] <doko> ubuntu-archive: please could you reject libppl from the NEW queue? I'd like to reupload with the different debian .orig.tar.gz
[21:52] <slangasek> doko: done
[21:53] <seb128> slangasek: is main still supposed to be frozen?
[21:54] <slangasek> seb128: yes... :)
[21:54] <slangasek> seb128: the risk of us having to do a re-roll is low, but yes, we're still frozen
[21:55] <seb128> slangasek: alright, I've some slightly disruptive change I would like to upload tomorrow morning (lib soname change which some rdepends), maybe it'll be unfrozen by then though ;-)
[21:56] <seb128> there is a new GNOME again on monday coming, yeah for an another updates sprint ;-)
[21:56] <slangasek> yes, by tomorrow morning if it's not unfrozen, then I'm having a bad day
[21:58] <seb128> kees: are you around?
[21:58] <seb128> kees: is there any easy way to see if those warnings are a security issue or not?
[21:58] <stefanlsd_> seb128: I made the diff.gz for pidgin if you would like to take a look - https://bugs.launchpad.net/bugs/263612
[21:59] <seb128> stefanlsd_: intrepid is frozen and it's late so tomorrow
[21:59] <stefanlsd_> seb128: np
[22:00] <kees> seb128: basically, if the string being printed contains anything from outside the program.
[22:00] <kees> .
[22:00] <seb128> kees: or, so if you can pass random datas there
[22:00] <kees> seb128: most of the false alarms I've seen are printing out localized msgs
[22:00] <slangasek> _MMA_: heno reported a debootstrap failure with UbuntuStudio alpha5, bug #264804; is anyone else seeing this?
[22:00] <kees> seb128: right.
[22:00] <tkamppeter> hi balachmar
[22:01] <seb128> kees: thanks
[22:01] <kees> seb128: most of the time coders just forget to add the "%s" before what they're adding to a function that eventually uses sprintf.
[22:02] <kees> seb128: sure, let me know if you see any that are iffy or weird.
[22:02] <seb128> right, that's those I usually
[22:02] <seb128> kees: most of those are
[22:03] <seb128> gchat *text;
[22:03] <seb128> text = g_strdup("some text");
[22:03] <seb128> gtk_message_dialog (...., text)
[22:03] <seb128> where it should be ... "%s", text
[22:03] <tkamppeter> persia. seb128, can someone of you give me the e-mail address of balachmar? I need yo contact him, he visits the IRC only for some minutes when I am not here.
[22:03] <kees> yeah, or   if (something) { text = _("Some error"); } else { text = _("Another error"); }
[22:04] <kees> seb128: most of the "real" problems have been when e.g. a filename or URI is included in the message.
[22:04] <seb128> tkamppeter: I don't know his email
[22:05] <jdstrand> kees: how often have you seen these false positives?
[22:05] <seb128> kees: I see, thanks, I'll start patching those when I do updates
[22:05] <kees> seb128: great, thanks muchly.
[22:06] <seb128> jdstrand: as I was saying before, that's my build directory
[22:06] <seb128> $ find . -name *.build | xargs grep "warning: format not" | wc -l
[22:06] <seb128> 916
[22:06] <seb128> jdstrand: so there is lot of those in GNOME
[22:06] <jdstrand> seb128: right, I saw that-- I was just curious cause kees did an archive rebuild at one point
[22:06] <kees> jdstrand: I haven't done a huge analysis yet, but on a rough guess, I'd say about 1/5th of the packages that throw the error are vulnerable.
[22:06] <seb128> utch
[22:06] <kees> but that's just a wild guess
[22:06] <jdstrand> sure
[22:06] <seb128> good idea to clean those then ;-)
[22:07] <seb128> some have already annoyed me
[22:07] <jdstrand> but that is a high false positive rate, even if you are off by a bunch
[22:07] <seb128> GNOME tends to use -Werror in svn so builds break in intrepid
[22:07] <kees> and for a vulnerable one, there are 15 warnings and only 1 is an issue.
[22:07] <seb128> it seems those don't trigger warning on other distros though
[22:07] <seb128> so upstream didn't notice
[22:08] <kees> seb128: yeah, I knew these compiler defaults were going to cause a lot of pain (which is why I've been trying really hard to document them and fix ones I see)
[22:08] <kees> seb128: additionally, I didn't want to do build-bumps just to get things recompiled -- we've got enough pain.  :)
[22:08] <seb128> right
[22:08] <kees> my hope is to get the bulk of the archive rebuilt with hardening before the next LTS
[22:09] <jdstrand> I think that should be doable
[22:10] <NCommander> kees, well, I had a setback, but I'm on the right path now, I had to redo the Linux from Scratch chroot
[22:10] <kees> NCommander: heh, cool
[22:11] <kees> well, cool that you worked it out, not that you hit glitches.
[22:11] <NCommander> The big issue is that I screwed up the linker
[22:11] <kees> :)
[22:11] <NCommander> and I tried to use Ubuntu sources
[22:11] <NCommander> I'm going to work from baseline known to build sources, then rebuild larger with the Ubuntu source code
[22:11] <ScottK> NCommander: You're indi fix looks good.  I'm just waiting for slangasek to announce Main is open for business to upload it.
[22:11] <NCommander> \o/
[22:11]  * NCommander is a porter
[22:11] <NCommander> weee
[22:12] <NCommander> Kinda a weird concept on ubuntu since no one realizes our ports exist
[22:12] <slangasek> this is better than being a stout
[22:12] <seb128> kees: so for example gedit has:
[22:12] <seb128> 	message = g_strdup_printf (_("The file \"%s\" is read-only."),
[22:12] <seb128> 				   name_for_display);
[22:12] <NCommander> sladen, stout?
[22:12] <seb128> dialog = gtk_message_dialog_new (....message);
[22:12] <NCommander> er, slangasek ^
[22:12] <ScottK> NCommander: Beer reference.
[22:12] <seb128> kees: that could be leading to a crash or something
[22:12] <NCommander> ah, me and my lack of /dev/alchocalism strikes again
[22:13] <kees> seb128: correct.  that is potentially exploitable, but very hard to trigger.  ("user-assisted" as we call it.)
[22:13] <seb128> kees: alright, I'll not bother too much I think, just clean those on the way and send patches upstream
[22:14] <seb128> kees: I'm not sure what made the yelp one a security issue though
[22:14] <NCommander> ScottK, as an side, was I right about the kde4bindings issue w.r.t. to mono on lpia?
[22:14] <kees> seb128: it was that firefox uses yelp as a handler for man:// and info://, and doesn't show the URL when asking the user to open yelp
[22:14] <ScottK> NCommander: I haven't got to that one yet.  I checked indi first.
[22:15] <NCommander> Ah
[22:15] <kees> so, clicking a link on a page could lead to a format attack without much user interaction.  it was still considered "low" priority.
[22:15] <seb128> kees: still that should be nothing exploitable, yelp is a local application so that could only lead to crash it no?
[22:15] <Riddell> NCommander: did you manage to look at koffice?
[22:17] <NCommander> Riddell, I've built it, did some research, I can kick out a fix for it when main unfreezes
[22:17] <Riddell> great, thanks NCommander
[22:17] <seb128> NCommander: so you work on ubuntu, kubuntu and xubuntu now?
[22:17] <NCommander> Pretty much
[22:17] <NCommander> Give me time, I'll do work on Studio too
[22:17] <jdstrand> ScottK: what is the recommended way of integrating amavis-new with clamav in intrepid? (a wiki link or whatever is fine)
[22:18] <NCommander> And Mythbuntu getting installed on something when I find cheap hardware
[22:18] <seb128> NCommander: ;-)
[22:18] <seb128> NCommander: I've uploaded pangomm today btw, I'll get pitti to review it tomorrow
[22:18] <kees> seb128: it would be very hard to exploit, but it could still lead to arbitrary code execution.
[22:18] <seb128> kees: alright, I think that was enough question for today, thanks for reply to those!
[22:18] <kees> seb128: using %n and other carefully selected items, an attack can target specific areas of memory, and gain control of the execution flow.
[22:19] <kees> seb128: heh, no problem, I'm happy to answer them.
[22:20] <NCommander> seb128, I consider myself a jack of all trades. All derievates on all architectures I can access
[22:20] <NCommander> Or in other words, if its broke, I can fix it, or I know the guy who can fix it :-)
[22:21] <seb128> :-)
[22:21] <NCommander> (the sole exception ATM is gcl. I don't touch packages who's patch files are 5 times the size of the 15MB source package)
[22:21] <ScottK> jdstrand: I just looked and my notes are not at all where I thought they were.  So working from memory, you have to do some config file editing.   The most common one I see people use is http://www200.pair.com/mecham/spam/
[22:21] <seb128> NCommander: so you would touch openoffice? ;-)
[22:21] <NCommander> seb128, built it from source once or twice
[22:21] <slangasek> dear God, why
[22:21] <NCommander> slangasek, same reason I want Ubuntu on Alpha
[22:22] <jdstrand> ScottK: ok-- I was going to try it out to give it at least a shot at working out of the box :)
[22:22] <NCommander> I like pain, or a challenge
[22:22] <slangasek> you hate the planet?
[22:22] <slangasek> oh
[22:22] <ScottK> Great.
[22:22] <NCommander> That being said, I'm not going to be coding new features for it :-P
[22:22] <NCommander> But I'll fix build failures
[22:22] <NCommander> slangasek, no, just driving you insane with an alpha port ;-).
[22:23] <slangasek> no reason it would bother me
[22:23] <NCommander> argh
[22:23] <NCommander> bah, so much for driving people crazy
[22:26] <NCommander> seb128, given my recent work on bootstrapping and fixing nutty FTBFS, I'm keeping a blog about it
[22:26] <NCommander> seb128, you can watch my descent into true insanity in real time
[22:26] <slangasek> NCommander: I can think of more noble hobbies than trying to drive people crazy...
[22:26] <seb128> NCommander: you should become an ubuntu member and be on planet ubuntu ;-)
[22:26] <NCommander> seb128, I plan to apply after two months have passed
[22:27] <seb128> NCommander: btw pangomm will probably be accepted tomorrow, is gtkmm 2.13 ready? ;-)
[22:27] <NCommander> slangasek, I'm just multitasking. I drive myself crazy already, but I have enough free time to make someone else loose their mind too
[22:28] <NCommander> slangasek, ;-)
[22:28] <NCommander> BTW, there are people nuttier then I am
[22:28] <NCommander> Someone modified aptitude to solve suduko puzzles
[22:32] <jdstrand> ScottK: unless I am looking at the wrong thing, that page is a) from 2006 and b) completely ignores the Debian packaging
[22:32] <jdstrand> I seem to remember something in the wiki...
[22:32] <ScottK> May be.  As I said I can't find my notes.
[22:33] <ScottK> http://www200.pair.com/mecham/spam/clamav-amavisd-new.html is a little more specific.
[22:33] <ScottK> You may have to grep a bit for which config file stuff is in, but it should be generally accurate.
[22:33] <jdstrand> yeah, I was just looking at that...
[22:35] <jdstrand> ScottK: what about https://wiki.ubuntu.com/MOTU/Clamav/TestingProcedures ?
[22:36] <ScottK> I totally forgot about that.
[22:36] <ScottK> I think it misses the step where you activate clamav.
[22:37] <ScottK> Grep for clamav in the the conffile directory and you'll find that.
[22:37] <jdstrand> ok
[22:50] <slangasek> superm1|away: how does http://paste.ubuntu.com/43476/ look to you?
[22:52] <asac> ogra: mozilla bug 453704
[22:52] <asac> ogra: any hint? that user appears to have issues with ubuntu ltsp like above
[23:01] <calc> all java in main is supposed to be using default-jre right?
[23:01] <calc> or whatever it is called?
[23:01] <calc> doko: ?
[23:01]  * calc is going to convert over OOo 2.4.1 to using it if so
[23:05] <calc> ah i found the email
[23:06] <jdstrand> ScottK: amavis[16255]: (16255-01) Blocked INFECTED (Eicar-Test-Signature), LOCAL [<IP_ADDRESS>] [<IP_ADDRESS>] <jamie@localhost> -> ...
[23:07] <jdstrand> ScottK: so I updated the wiki page accordingly
[23:07] <jdstrand> ScottK: *and* the profile didn't block amavisd-new :)
[23:08] <ScottK> jdstrand: Great.
[23:08] <doko> calc: yes. are there any outstanding problems with this?
[23:09] <ScottK> jdstrand: I've got a variety of gui front ends on my laptop for testing.  I'll make sure those are OK too.
[23:09] <jdstrand> ScottK: excellent. I'll upload the debdiff today/tonight
[23:21] <cjwatson> Cycom: as far as bug statuses go, "fix released" is the correct state for the bug if it's fixed in intrepid, but you can use the "target to release" link to nominate the bug to be fixed in hardy as well; if that nomination's accepted by the release team, the bug then grows an extra independent state for hardy
[23:23] <Cycom> cjwatson: wouldn't it make more sense to have a seperate state for a bug that won't be fixed in a release?  It's confusing for people examining the bug who still have the bug in the current release.
[23:23] <Cycom> cjwatson: 'Well, clearly I need to file a new bugreport!' kind of thing.
[23:24] <Cycom> it would make more sense to have a 'fixed in new version'.  Also, Intrepid is still alpha.  It's not supposed to be used by general users yet.
[23:24] <cjwatson> no, because the default state for the vast majority of bugs is that they get fixed in the current development release and we move on. In terms of raw bug count, it's relatively rare for fixes to need to be backported to stable releases, and so it wouldn't make sense to optimise for that.
[23:24] <Cycom> cjwatson: how bout just marking it 'won't fix' then?
[23:25] <cjwatson> no. the state of the bug is fix-released. when intrepid is released ordinary users will be able to get hold of that fix. From your description, it might well make sense to nominate it for hardy too
[23:25] <cjwatson> We're not going to reoptimise bug workflow for the uncommon case, but we do have ways to handle it which I've described to you
[23:26] <Cycom> if the fix isn't available, then it's not released...
[23:26] <cjwatson> this is how we use the bug states. please respect that
[23:26] <ScottK> Cycom: You aren't the first to suggest this approach and it really has been considered.
[23:27] <Cycom> is there a page to explain this to users?
[23:27] <Cycom> if so, I have no gripe.
[23:27] <Cycom> if not, it should be made.
[23:29]  * calc thinks he redid the java bits in 2.4.1 properly to build both with openjdk and gcj
[23:29] <calc> doko: i think it should be fine now that i have the patch to workaround the rhino issue
[23:29] <doko> ok
[23:29] <calc> doko: before it was failing due to the bug wrt rhino, there is already a bug filed in launchpad about it as you are probably aware :)
[23:29] <cjwatson> Cycom: I agree that something should be written and put somewhere prominent. At the moment I can't find such a page
[23:30] <cjwatson> (which is not necessarily to say it doesn't exist, I'm not a docteam kind of guy ...)
[23:31] <cjwatson> https://wiki.ubuntu.com/Bugs/Status defines our use of Fix Released
[23:32] <cjwatson> although it's aimed more at bug triagers than bug reporters
[23:33] <Cycom> cjwatson: Won't Fix: It is most often used for bugs with a release target that will not be fixed in that particular release but may be fixed later.
[23:33] <Cycom> vs. Fix Released: a release tarball was announced and is publicly available, or a fix was uploaded to an official Ubuntu repo.
[23:33] <cjwatson> yes, that's *if* somebody nominates a bug for a release and then it's later decided to be inappropriate for that release
[23:33] <cjwatson> that hasn't happened here
[23:34] <cjwatson> I've added a line to the description of Fix Released to describe the case at hand
[23:34] <Cycom> cjwatson: I was just about to suggest that :)
[23:35] <cjwatson> Won't Fix is only right if you think it *shouldn't* be fixed in hardy; which seems unlikely given your general manner :)
[23:35] <Cycom> cjwatson: so that now begs the question, where IS the target to release link?
[23:35] <cjwatson> right now, the state is that no decision has been taken regarding that bug and hardy
[23:35] <cjwatson> Cycom: should be just below the "Affects" box, but it may be that you only see it if you have permission to use it
[23:36] <Cycom> 'Nominate for release'?
[23:36] <cjwatson> oh, it's called "Target to release" on edge.launchpad.net. Sure, that sounds right
[23:36] <Cycom> cjwatson: broken link :/
[23:36] <cjwatson> (that's the beta testing site)
[23:36] <cjwatson> get somebody in #ubuntu-bugs to do it for you
[23:37] <Cycom> cjwatson: great! thanks.
[23:37] <cjwatson> I could do it myself, but I'd rather not since I'm in the release team and if I do it it'll automatically accept the nomination
[23:37] <Cycom> cjwatson: yeah, I understand :)
[23:37] <cjwatson> which is a bit more than I'd prefer at 11:30 at night
[23:38]  * cjwatson -> bed
[23:39] <Cycom> later dude. thanks again.
[23:39]  * calc bbl
[23:41] <cjwatson> oh, another way to look at the whole thing (might as well mention it since I thought about it) is that ultimately users benefit if we can make developers' processes for bug handling as efficient as possible. Developers are more efficient if they don't have to keep on looking at the bugs they've already fixed; therefore it makes sense to mark them fixed in the default view once the development release is fixed, and only ...
[23:41] <cjwatson> ... have developers have to look at them if they're using a non-default view (like launchpad.net/ubuntu/hardy/+bugs)
[23:42] <lifeless> yah
[23:42] <lifeless> this is why bzr marks bugs as fix released when they hit mainline
[23:42] <cjwatson> there are definitely smarter ways to do it (theoretically speaking) but this is what we have for now)
[23:48] <jdstrand> ScottK: uploaded debdiff for bug #264817
[23:49] <jdstrand> ScottK: keep in mind that it will be in complain mode on certain upgrades (see ApparmorProfileMigration), but new installs will be enforcing
[23:50] <jdstrand> ScottK: ping me when satisfied, and I'll apply for FFe
[23:52] <leszek> where can I find or change the translated menu in the isolinux bootloader from the livecd ? the *.tr file seems not to be the place