[12:02] <Keybuk> I've always wondered why monitors aren't square
[12:02] <Keybuk> I suspect it originally had something to do with difficulty of electron tubes or something
[12:02] <HrdwrBoB> peoples vision isn't square
[12:03] <HrdwrBoB> you have more vision sideways
[12:03] <Keybuk> hmm, true
[12:03] <HrdwrBoB> hence widescreen
[12:03] <Keybuk> that's the theoretical justification for widescreen, isn't it?
[12:03] <HrdwrBoB> the eye is a terribly ineffecient thing, we have a tiny tiny focus point
[12:03] <xhaker> HrdwrBoB: i don't think they did it 4:3 first because of that
[12:03] <LaserJock> hmm, but I like more vertical space so I don't have to scroll as much. I must be brainwashed
[12:03] <HrdwrBoB> xhaker: no, probably not, it would just have been the easiest way to do it
[12:04] <HrdwrBoB> LaserJock: yes but you have to focus down the page
[12:04] <xhaker> LaserJock: do you read much?
[12:04] <HrdwrBoB> that's a convenience issue, you can't see the whole thing at once
[12:04] <sladen> Keybuk: principly to do with humans living in the horizontal plane (eg. we don't fly and we don't swim---so food and predators are on the same level)
[12:05] <Keybuk> don't swim ... clearly you haven't read "The Aquatic Ape" :)
[12:06] <LaserJock> I recently got a 17" widescreen and I'm having a hard time adjusting to the width. I think I liked the ratio of a CRT better.
[12:06] <HrdwrBoB> Pixel Pitch 
[12:06] <HrdwrBoB> 0.264 mm  on my 17" LCD
[12:08] <Keybuk> LaserJock: see, that's just tempting a reply along the lines of "width is harder to become accustomed to than length ... or so I'm told" :)
[12:09] <Keybuk> oh, wait, I was looking at Network Manager ... back into the gutter with me!
[12:09] <LaserJock> yikes
[12:10] <Keybuk> damn
[12:11] <Keybuk> I can't screenshot the logout dialog
[12:11] <LaserJock> is it bigger than a screen now ;-)
[12:11] <Keybuk> no, it's missing all of its icons
[12:11] <Keybuk> which actually looks a vast improvement, tbh
[12:11] <Tm_T> hmm, what's the purpose of that BT tracker in dapper?
[12:12] <seb128> Keybuk: did you restart the session since you upgraded?
[12:12] <seb128> Keybuk: the icons moved to an another place, so code still running doesn't find them ...
[12:12] <seb128> Keybuk: that's just a dapper to dapper upgrade issue, I'm not sure I want to spend efforts on workarounding it :p
[12:13] <Keybuk> seb128: I was logging out to restart the session after an upgrade :)
[12:13] <Keybuk> seb128: btw, GNOME still steadfastly refuses to logout on both my machines
[12:13] <Keybuk> it eventually gets the idea after sitting there for about a minute
[12:15] <seb128> Keybuk: usually that's either a bugged app doing session registration wrongly
[12:15] <Keybuk> seb128: I'm not running anything strange that I'm aware of
[12:15] <seb128> or lo beeing misconfigured
[12:15] <Keybuk> tomboy is about the only "alien" thing in my session
[12:15] <seb128> I've the issue quite often too atm
[12:16] <seb128> I'll have a look when everything else is settled a bit
[12:16] <Keybuk> we have time now :)
[12:16] <seb128> did the decision to shift dapper has been taken?
[12:16] <Keybuk> yes
[12:16] <seb128> ah, cool
[12:17] <seb128> desktop bugs backlog is not nice atm
[12:17] <Keybuk> https://wiki.ubuntu.com/DapperReleaseSchedule/Slewed
[12:17] <seb128> I've around 400 mails in my box and I keep usually 1 mail by bug 
[12:17] <seb128> and I was at ~ 10 mails before going to UI sprint
[12:18] <LaserJock> Keybuk: when was the decision made?
[12:18] <seb128> that mean we got new bugs or comments for around  300 or 400 bugs in 10 days
[12:18] <seb128> which is ... utch
[12:18] <xhaker> LaserJock: today @ maybe 19:00 UTC
[12:19] <xhaker> now i get the impression it was earlier
[12:19] <LaserJock> xhaker: thanks
[12:19] <Keybuk> LaserJock: earlier at a special meeting of the TB+CC
[12:21] <LaserJock> Keybuk: hmmm, I think the doc team wanted to make an adjustment to the Slewed schedule. Should they talk to the TB ASAP?
[12:21] <jdub> seb128: utch is good!
[12:21] <Keybuk> what was the adjustment you wanted?
[12:21] <seb128> jdub: urg so
[12:21] <LaserJock> Keybuk: well, I don't know if it was perfectly decided, but we didn't think the DocStringFreeze should be pushed so much
[12:22] <seb128> jdub: :)
[12:22] <Keybuk> LaserJock: it isn't pushed?  there's an extra week between that freeze and the final release compared to the original schedule
[12:22] <Keybuk> the confusion there is probably that there's more time between Beta and Final on the new schedule than the old
[12:23] <LaserJock> Keybuk: we were discussing having the DocStringFreeze on April 6th
[12:23] <Keybuk> LaserJock: that'd put the doc freeze before the UI and Strings were frozen though
[12:24] <Keybuk> which seems silly
[12:24] <LaserJock> Keybuk: yeah, I'm noticing that :(
[12:24] <Keybuk> why such a long freeze?
[12:24] <Keybuk> it seems odd to freeze dapper's docs two months before it's released
[12:24] <LaserJock> Keybuk: to allow time for translation
[12:25] <Keybuk> why would dapper's docs take longer to translate than breezy's?
[12:25] <LaserJock> Keybuk: I'm not sure but I would guess because there are more docs and perhaps more translations? I'm really not sure
[12:25] <LaserJock> Keybuk: mdke is the one to talk to but we have been discussing it on ubuntu-doc
[12:25] <Keybuk> that doesn't seem likely to me
[12:26] <Keybuk> we certainly haven't given you less time than you had
[12:26] <Keybuk> and freezing docs before the underlying system is frozen just seems wrong
[12:26] <Keybuk> you may end up documenting things that change
[12:26] <LaserJock> Keybuk: sure, but I think we where under the impression that the UI freeze would not be pushed
[12:26] <Keybuk> UI freeze has been thawed
[12:27] <Keybuk> because of the Localisation effort
[12:27] <Keybuk> with the emphasis on other languages being added to dapper, it may be necessary for UI elements to change
[12:28] <LaserJock> Keybuk: ok, well I'll email the doc team list and we can discuss it some more. We planned on sending an email to the TB once we figured out home much time we needed, etc.
[12:28] <Keybuk> right
[12:28] <Keybuk> it does seem odd that you'd need longer to me
[12:28] <Keybuk> as that wouldn't explain why you wouldn't also need longer for dapper+1
[12:29] <Keybuk> if you had a two month doc freeze, you'd have to freeze dapper+1's docs at only 4 weeks *into* the release
[12:29] <LaserJock> Keybuk: I think it might have been more like "we can pretty much be done with the docs by the present Freeze so why not give more time to translations"
[12:29] <Keybuk> also the later freeze doesn't actually stop you as a team freezing documents and preparing them for translation ahead of the freeze
[12:29] <Keybuk> though it does mean you'd have to play catch up with the UI
[12:30] <Keybuk> LaserJock: that was Corey's argument at the meeting
[12:30] <Keybuk> which doesn't play well with "but what if what you've documented changed" ?
[12:30] <LaserJock> exactly
[12:30] <Keybuk> and as I said, if a doc is finished, it can be translated in advance of the freeze
[12:30] <LaserJock> yeah, for sure
[12:31] <Keybuk> I'm ambivolent on the issue; the UI and String freezes were given extra time due to the localisation work ... so there could still be a balance there to be struck
[12:32] <LaserJock> I see what you're saying. I think we just thought the UI Freeze wasn't going to be moved.
[12:32] <LaserJock> so we just need to take that into account
[01:08] <Keybuk> the Orange finally proves that dapper is a Duck, I guess
[01:09] <Keybuk> you don't get Dragon a l'Orange, after all
[01:10] <LaserJock> lol
[01:15] <Seveas> Keybuk, the orange represents the dragon's flame
[01:16] <Keybuk> http://www.carpages.co.uk/ford/ford-focus-st-15-02-05.asp
[01:16] <Keybuk> it reminds me a lot of that
[01:16] <Seveas> lol
[01:16] <Keybuk> all bling, and aimed straight at the chav/ricer market :p
[01:17] <Keybuk> we should have a Burberry Metacity theme to go with it
[01:17] <Keybuk> as you can guess, I am not a fan of new Human
[01:17] <Seveas> Keybuk, http://files.datawire.nl/uploads/o8901cyyFFFsz0gM9JcMRQ/5hOQkl6N7fsuzf1c9-GQdA/727-Oranje_supporters_klaar_voor_Duitsland.jpg
[01:18] <jdub> Keybuk: 'Numan'
[01:18] <Keybuk> the only human it reminds me of are those who smother themselves in Fake Tan
[01:19] <jdub> Keybuk: the good thing about 'Numan' is that every time you see someone running it, you can say it the same way Seinfeld does whenever Numan shows up.
[01:19] <Keybuk> what's that?
[01:19] <jdub> i'm sure there are samples on the interweb
[01:20] <Keybuk> plus I hate the new icons
[01:20] <LaserJock> jdub: lol, that's good
[01:27] <Keybuk> Holy Segfaulting X-Chat!
[01:27] <Keybuk> jdub: why do the Evolution header list column titles suck in Human?
[01:27] <Keybuk> sorry, Numan
[01:28] <sladen> Keybuk: the intensity?
[01:29] <jdub> Keybuk: dunno.
[01:29] <Seveas> sladen, the insanity ;)
[01:29] <jdub> (i actually haven't run evo with it)
[01:33] <Keybuk> sladen: they look like a row of buttons, instead of a column title
[01:33] <Keybuk> ie. rounded corners and gradients
[01:34] <Keybuk> not to mention borders, instead of inter-column space
[01:34] <sladen> Keybuk: and the text jumps around in such a cool way
[01:34] <sladen> Keybuk: it's almost as though it were intentional :)
[01:35] <Keybuk> the scrollbar edges are *damned* confusing
[01:35] <Keybuk> it makes it look like there's a little bit of movement available
[01:35] <Keybuk> (when you're viewing 100% of the whole document)
[01:37] <sladen> there's a lack of constract betwen what's clickable and what's not.  and the ends should be same colour as the middle section, rather than the outer section
[01:40] <sladen> an improvement might be to have the whole 'bar' section highlight orange on hover and remove the 5px high end pieces
[01:43] <infinity> sladen: Did you take an executive decision on the reverse-video slash-down thing?
[01:44] <infinity> sladen: (FWIW, I still think it's both ugly and unintuitive, but whatever)
[01:46] <Burgwork> I don't think we need a progress bar or need to show what is happening, but that is just me
[01:47] <infinity> Burgwork: Well, in an ideal world, shutdown would take no more than a couple of seconds (a goal for dapper+1, to be sure), then I'd agree, progress is pointless.
[01:48] <infinity> Burgwork: When shutdown can take 30-60 seconds on some machines right now, though, we need to at least give a hint of activity.
[01:48] <infinity> (There's no reason why a desktop machine shouldn't be able to go from logout to off in 2 or 3 seconds, however.  After the sessions is saved, nothing else should care about state on a desktop box..)
[01:49] <Amaranth> on my mini shutdown is faster than OS X :)
[01:51] <infinity> Does OSX suffer from the same traditionally anal UNIX view that "if you started it, you must stop it gracefully before we can proceed with a halt"?
[01:51] <Amaranth> i guess
[01:52] <infinity> Cause, while that's pretty true of certain daemons that will muck up log files if they're violently killed, 99% of what the average desktop machine has running should be able to get the plug pulled.
[01:52] <Amaranth> sometimes it powers off in 10 seconds, sometimes it takes 30
[01:52] <infinity> Which will be a goal for dapper+1 (which also means the removal of splash-down again, so it was just a temportary hack for one release)
[01:53] <infinity> temporary, too.
[01:53] <jdub> infinity: i hope we can remove the log lines from usplash in dapper+1 :-)
[01:54] <mjg59> Hmm
[01:54] <mjg59> Implementing a UGA framebuffer looks like it might actually be quite easy
[01:54] <mjg59> EFI seems to magically have C calling convention
[01:54] <Amaranth> jdub: get rid of the progress bar too :)
[01:55] <mjg59> You just end up with a bunch of function pointers into firmware
[01:55] <mjg59> Which is kind of magic
[01:55] <Amaranth> neat
[01:55] <infinity> Amaranth: The progress bar can't go away until the boot time is REALLY, REALLY short, IMO.
[01:55] <mjg59> And the most basic support is just "Blit this block of memory onto the screen"
[01:56] <jdub> some status is warranted
[01:56] <infinity> jdub: I'm all for a default "non-verbose" mode (with an option for verbosity for people who like it)
[01:56] <Amaranth> infinity: but the progress bar kind of..jumps
[01:56] <KaiL> anybody in here, who understandy enough about cpufreq, to explain, why it worked in breezy, but doesn't any more in dapper (kernel related problem)?
[01:56] <infinity> jdub: It's not exactly rocket science for us to do that right now.
[01:56] <jdub> but if the status could be displayed by a colour-changing spinner or something, that'd be fine
[01:56] <Amaranth> infinity: something like a throbber would be more appropriate, i think
[01:56] <jdub> infinity: yes, that's what i've been pushing for since we did usplash
[01:56] <Amaranth> spinner, there you go
[01:57] <infinity> I don't see how a spinner/throbber is much improvement over a progress bar that's not quite perfect.
[01:57] <infinity> At least the progress bar give you SOME indication of how long you have to wait.
[01:57] <jdub> osx has a spinner, winxp has a non-progress progress bar, but we can actually display real progress, so doing so would be useful
[01:57] <sladen> infinity: no, _the executive_, made an executive request
[01:57] <infinity> A throbber just says "I'm doing stuff, you may have enough time to go get coffee, I may be done in 5 seconds, you may have time for a nap, NOBODY KNOWS"
[01:58] <Amaranth> but some things take 10 seconds, some take 1
[01:58] <Amaranth> and you don't really know if it froze or not
[01:58] <infinity> It's an approximation of progress.
[01:58] <mjg59> jdub: Mm? osx has a spinner and a progress bar
[01:58] <mjg59> The progress bar appears once the graphics driver is up
[01:58] <infinity> And, unless your system is completely hardlocked, there's a fair chance that even on a "freeze", your spinner/throbber would keep spinning/throbbing, so that's no help.
[01:58] <jdub> mjg59: yeah
[01:58] <Amaranth> last time i paid attention the bar only moves once something finishes
[01:59] <infinity> (I have a Windows installation that just blindly keeps "progressing" forever, but never actually boots.
[01:59] <mjg59> Having both seems mad
[01:59] <mjg59> Having actually used osx now, I'm not terribly keen on it
[01:59] <mjg59> It's shiny, but I've made it fall over several times
[02:00] <Amaranth> mjg59: the finder is a wreck
[02:00] <mjg59> I guess it's the case that people subconsciously realise that certain things will explode and avoid doing them, and then claim that other OSs (where they don't have that) are worse
[02:00] <infinity> sladen: Fair enough.  Last I heard from him, we were still debating it a bit.  Then you sent me patches with no context (which I was going to follow up on later), but whatever. :)
[02:00] <Amaranth> mjg59: and the dock is worthless
[02:00] <Amaranth> mjg59: apple-tab and quicksilver make it usable
[02:00] <infinity> sladen: When it hits the archive, I'll let the comunity argue about it.  I don't actually care that deeply.
[02:00] <Amaranth> mjg59: but i've never had OS X kernel panic or anything, except when i ran the ext2fsx driver on tiger
[02:01] <infinity> I don't panic on Dapper either.
[02:01] <sladen> infinity: I agree thoughly, my take was that it didn't actually look any worse, so... :)
[02:01] <infinity> But I do suffer occasional video lockups.  Our video situation is pretty sad.
[02:01] <Amaranth> i did once, when i tried running with the bcm43xx driver from svn
[02:03] <infinity> If only we shipped video from exactly two vendors, who were both friendly with us, and employed a mess of hackers to make those two vendors' cards work flawlessly.  Hrm.
[02:04] <Lathiat> hehe
[02:04] <infinity> I'm starting to sense that the solution to any of our stability problems is to sell an "Ubuntu Computer", and tell people that you CAN run Ubuntu on other machines, but we won't support it.
[02:05] <infinity> Oh, and we should charge twice as much for that "Ubuntu Computer" as you'd pay for putting together similar parts yourself.
[02:05] <bddebian> infinity: I think my initramfs might be jacked, do you want a copy?
[02:06] <infinity> bddebian: Only if it's not jacked due to -ENOSPACE on /tmp or /boot (in which case, the bug is filed in triplicate, and I need to fix it)
[02:06] <infinity> bddebian: Anything else, and yeah, I'd love a copy.
[02:06] <bddebian> infinity: No, it's missing cpqarray
[02:07] <infinity> bddebian: And a description of the jackitude.
[02:07] <bddebian> OK, I'll snag a copy when I get back to work tomorrow
[02:07] <infinity> Erm, how are you adding cpqarray?
[02:07] <bddebian> How am I "adding" it?
[02:07] <infinity> (It's not in the default list right now)
[02:08] <bddebian> Oh, then maybe it isn't broken?
[02:08] <infinity> Right, if you're not adding it, and I'm not adding it either, we know the breakage.  I don't need a copy. :)
[02:08] <infinity> I'll add it to the default list.
[02:08] <bddebian> Install picked it up
[02:09] <infinity> If you want to stick it in the "scsi" section in /usr/share/initramfs-tools/hook-functions and re-gen your initrd... Tell me if that unjacks it. :)
[02:09] <infinity> Installer and initramfs do things in entirely different ways.
[02:10] <bddebian> infinity: Well I was going to stick in in /etc/mkinitramfs/modules and update-initramfs -u   Is that not correct?
[02:12] <infinity> That would do fine for a test, yes.
[02:12] <infinity> It'll end up in the other file if your test is successful, though (in my next upload)
[02:12] <bddebian> OK, thx
[02:20] <Burgwork> has it become 6-06 or is it 6.06?
[02:22] <infinity> I'm hoping for 6.06, since 6-06 makes it more difficult to represent in debian package versions in a policy-compliant way. :)
[02:23] <Keybuk> when have we ever put it in package versions?
[02:23] <infinity> We've done it in security a few times. :)
[02:24] <infinity> And ubuntu-docs appears to use a version that relates to the release version.
[02:24] <LaserJock> umm, this is sort of a stupid question. Is there an easy way to tell the difference between Flight 4 & 5 livecd's?
[02:25] <Keybuk> LaserJock: what kind of difference do you mean?
[02:25] <LaserJock> Keybuk: I download a livecd but I can't remember if it was Flight 4 or 5 :(
[02:25] <infinity> LaserJock: md5sum.
[02:26] <LaserJock> mjg59: intel?
[02:26] <mjg59> LaserJock: Yeah
[02:26] <LaserJock> infinity: ah, yes. should have thought of that
[02:26] <LaserJock> mjg59: great!
[02:30] <sladen> mjg59: have you got a macmini and macbookpro yet?
[02:30] <sladen> mjg59: you seem like you're about ready to progress to the next level
[02:30] <mjg59> sladen: I'e got a mini
[02:30] <mjg59> No macbook
[02:31] <LaserJock> hmm, I suppose it doesn't bode well if the md5sum doesn't match either Flight4 or Flight5
[02:31] <mjg59> I'm just working on making the framebuffer sane, so we can avoid this passing of kernel arguments pain
[02:31] <infinity> LaserJock: rsync it to flight5, then...
[02:33] <LaserJock> infinity: you can rsync the iso's?
[02:33] <infinity> Of course.
[02:34] <LaserJock> mjg59: if you get to the point where  you need an iMac tester, I'm available ;-)
[02:34] <mjg59> LaserJock: Not quite - I've found the binutils issue that stops us building a bootloader, but once that's fixed we should have test images
[02:35] <infinity> LaserJock: rsync -v --progress --partial rsync://cdimage.ubuntu.com/cdimage/releases/dapper/flight-5/dapper-live-i386.iso ./my-old-iso.iso
[02:36] <infinity> LaserJock: Or some approximation thereof.
[02:37] <LaserJock> infinity: cool, thanks
[02:42] <sladen> mjg59: out of interest, what was it?  GCC4ism?
[02:43] <mjg59> sladen: No, scary stuff I don't understand at all
[02:43] <mjg59> It's fine with gcc 4
[02:44] <jdub> Kamion: unlikely ping
[02:58] <Keybuk> where's sladen when you need him?
[03:05] <mjg59> Eh? This machine appears to have no UGA table
[03:05] <Lathiat> UGA?
[03:05] <mjg59> EFI's graphics architecture
[03:05] <Lathiat> ah
[03:06] <jdub> Lathiat: it's short for AWWWWUGA! (as in the submarine alarm sound)
[03:06] <jdub> AWWWWUGA! AWWWWUGA! DIVE! DIVE!
[03:06] <bddebian> hahaha
[03:09] <mjg59> Uhm.
[03:09] <mjg59> Can we re-do the UI for the SCIM config applet?
[03:10] <jdub> haha
[03:10] <jdub> too late! critical feature!
[03:12] <mjg59> No, seriously
[03:12] <mjg59> Why does it not know what my keyboard layout is?
[03:12] <mjg59> Why does it have three tree heads that are entirely pointless?
[03:12] <mjg59> Did /anyone/ do UI review on it?
[03:13] <mjg59> "Embed Preedit String into client window"?
[03:13] <mjg59> That has so many things wrong with it I'm not sure where to start
[03:13] <jdub> mjg59: really, this is something that we should integrate / do properly upstream
[03:13] <Keybuk> jdub: hmm?  UI Freeze is weeks away :)
[03:13] <Keybuk> plenty of time to fix it
[03:14] <jdub> where "fix" will involve quite a bit of "rewrite" work
[03:14] <mjg59> jdub: It's worse than the old Xscreensaver one
[03:14] <jdub> yeah
[03:14] <mjg59> It's like those preferences apps that you get with laptops that have plainly been written by some technical guy who didn't run away fast enough
[03:14] <mjg59> And has a default MFC icon
[03:15] <jdub> heh
[03:15] <mjg59> Looking at it, it looks almost as if it autogenerates chunks of the UI (since there are several plugins)
[03:30] <minghua> mjg59: the but about scim's UI is bug #3635
[03:30] <Ubugtu> malone bug 3635 in scim "scim-setup isn't HIG compliant" [Minor,Confirmed]  http://launchpad.net/bugs/3635
[03:30] <minghua> mjg59: I am sure upstream would love a patch/rewrite ;-)
[03:30] <mjg59> Ha
[03:30] <mjg59> Yes
[03:31] <minghua> it has always been like this, it is just much more exposed to public scrutiny recently due to inclusion by ubuntu-desktop
[03:41] <infinity> minghua: Do you know anything about scim-chewing?
[03:41] <infinity> minghua: The build (sometimes) gets in an infinitely loop, and it sure would be nice to fix that. :)
[03:41] <infinity> minghua: http://librarian.launchpad.net/1744038/buildlog_ubuntu-dapper-hppa.scim-chewing_0.2.1-2ubuntu2_FAILEDTOBUILD.txt.gz
[03:41] <minghua> infinity: yes, a bit
[03:41] <minghua> oh not again :-(
[03:41] <infinity> s/infinitely/infinite/
[03:41] <minghua> infinity: I'll look at it when I gets home (in an hour)
[03:42] <_ion> My attempt at making a NetworkManager 0.6 package for Dapper: http://johan.kiviniemi.name/ubuntu/
[03:42] <minghua> infinity: fortunately I know the debian maintainer and upstream author well :-)
[03:42] <infinity> minghua: You rock.  If you don't have rights to upload it (do you?) feel free to pass patchs through me, and I'll get them in ASAP to make my poor buildds happy.
[03:43] <minghua> infinity: I have universe upload right.  but let's see how long it takes to figure out the problem first :-)
[03:44] <infinity> minghua: I'm sure it's not terribly tough to sort out, I'm just running flat-out over here trying to (re)bootstrap hppa, and juggle a bunch of other stuff.
[03:45] <bddebian> Excuses, excuses :-)
[03:48] <minghua> infinity: I'll try :-)
[04:04] <Kyral> lol @ Jeff's blog post
[04:12] <minghua> infinity: there is a ubuntu patch for scim-chewing that I don't understand, it adds:
[04:12] <minghua> AC_SUBST(LIBTOOL_EXPORT_OPTIONS)
[04:12] <minghua> to configure.ac
[04:12] <infinity> I am not an autoconf/libtool guru by any stretch, so don't ask me. :)
[04:12] <minghua> the relevant changelog is "* Add patch for correct the configure.ac for LIBTOOL _EXPORT_OPTIONS"
[04:12] <minghua> infinity: okay
[04:13] <minghua> anyone autotools/libtool guru around?  what is this LIBTOOL_EXPORT_OPTIONS used for?
[04:13] <infinity> Anyhow, I doubt (though can't really prove) that that's what's causing the infinite loop, since the loop seems more touchy than that.
[04:13] <minghua> freeflying?  (since this is your patch)
[04:14] <infinity> (Note that it built find on some buildds, and looped on others..)
[04:14] <infinity> s/find/fine/
[04:14] <minghua> infinity: yeah, I am just looking at the ubuntu patchs first
[04:37] <natroll> i see devel people
[04:38] <mjg59> Hm. Right. So the Mac wakes up happily through the assembly section. Now I just need to check where it's falling over in the kernel, then.
[04:39] <bddebian> natroll: :)
[04:41] <minghua> infinity: I think I have an idea now
[04:41] <minghua> infinity: can you modify the file po/Makefile.in.in, after line 259 (in the Makefile target), add
[04:42] <minghua> infinity: add "touch POTFILES && touch Makefile", and try again?
[04:42] <minghua> infinity: I can't upload to main so I need you to upload anyway, and I think the patch is trival
[04:43] <infinity> minghua: I can't try again on that buildd in any meaningful way right now, but I can try in a little while.
[04:44] <minghua> infinity: do you want me to file an bug?
[04:44] <infinity> minghua: No, I can use backscroll. :)
[04:45] <minghua> good, so consider scim-chewing back in infinity's hands now :-)
[04:46] <minghua> and scim-m17n "not usabel at all" bug :-(
[05:27] <infinity> Gah.
[05:27] <infinity> minghua: Will the madness never stop?  I think po/Makefile.in.in is autogenerated during build... From what, I have no idea. :)
[05:27] <minghua> infinity: no, po/Makefile.in.in is in source
[05:28] <minghua> infinity: but the debian/rules clean is apparently broken, so always checkout new source
[05:29] <minghua> infinity: it seems to me that the problem is po/POTFILES and po/Makefile is generated by the same command (cd .. && ./config.status)
[05:29] <minghua> infinity: but po/Makefile target depends on po/POTFILE, therefore the timestamp skew
[05:29] <infinity> minghua: Erm, I was using fresh source.  The Makefile.in.in I have halfway through a build is different from the one in the source package.
[05:30] <minghua> ouch
[05:31] <minghua> infinity: ah yes, the debian/rules run bootstrap, so Makefile.in.in may well be changed...
[05:31] <minghua> but I don't think it will be regenerated over and over (but then again, I can reproduce the build failure)
[05:32] <minghua> infinity: no, in my build the po/Makefile.in.in isn't touched at all
[05:33] <infinity> I swear I'm not making this up. :)
[05:36] <minghua> infinity: there is no mentioning of po/Makefile.in.in in the failed build log either...
[05:36] <infinity> No, there isn't in my log either.
[05:36] <minghua> infinity: are you sure you are looking at po/Makefile.in.in instead of po/Makefile.in?
[05:36] <infinity> It doesn't claim to be regerating it, but it's definitely different than the one I have in the source package on unpack.
[05:40] <infinity> Oh, feh.
[05:40] <infinity> dpkg-source: warning: ignoring deletion of file po/Makefile.in.in
[05:40] <infinity> The clean target removes it.  That's hilarious.
[05:40] <infinity> So much for quick hack testing.
[05:41] <minghua> infinity: told you that debian/rules clean is broken...
[05:41] <infinity> Right, so, back to the original question.  Where is Makefile.in.in coming from? :)
[05:42] <infinity> If clean removes it (and clea is run at the beginning of every build), it's coming from somewhere else. :)
[05:42] <minghua> good point
[05:43] <infinity> Perhaps it's an automake template of some sort, and doesn't "come from" the source package at all.
[05:44] <infinity> Yup, that seems to be the case.
[05:44] <minghua> infinity: it comes from the configure
[05:44] <infinity> That'll make it a bit hard to patch. :)
[05:45] <minghua> it bootstraps (./autogen.sh)
[05:45] <infinity> Yeah, it comes direct from intltoolize, I guess.
[05:46] <minghua> infinity: what about hacking scripts/remove-autotool.sh so that it doesn't remove po/Makefile.in.in? ;-)
[05:47] <infinity> Yeah, that might be the "best" solution.
[05:49] <minghua> does "pbuilder build" runs debian/rules clean before building as well?
[05:49] <infinity> I have no idea.  dpkg-buildpackage does.  Does pbuilder use dpkg-buildpackage?
[05:49] <minghua> yes, but seems it uses dpkg-buildpackage -b, which IIRC doesn't run clean
[05:50] <infinity> Yes, it does.
[05:50] <infinity> Only dpkg-buildpackage -nc doesn't.
[05:50] <infinity> (-nc == no clean)
[05:50] <minghua> infinity: yeah, you are right, saw clean in my pbuilder log
[05:56] <infinity> Oh, hrm.  I can't even use dpatch for that, since the clean will whack the file before dpatch gets to run. :)
[05:57] <minghua> hehe
[05:57] <infinity> I feel so dirty.
[06:02] <minghua> scim-chewing apparently went through buildds of all debian archs fine
[06:02] <infinity> That may be a red herring.  It may just be happening universally with a new intltool, but hppa was behind, so built with a different version.
[06:02] <infinity> Or something.
[06:02] <infinity> I dunno.
[06:02] <infinity> I'd just rather not have it happen at all. :)
[06:02] <minghua> new intltool... that makes sense
[06:03] <infinity> (And the fix probably belongs in intltool, really, if it's a breakage in a generic template...
[06:04] <minghua> infinity: yeah, the new generated po/Makefile.in.in is indeed different on the parts related to po/Makefile and po/POTFILES
[06:05] <minghua> stamp-it: Makefile.in.in ../config.status POTFILES.in
[06:05] <minghua>         cd .. \
[06:05] <minghua>           && CONFIG_FILES=$(subdir)/Makefile.in CONFIG_HEADERS= CONFIG_LINKS= \
[06:05] <minghua>                $(SHELL) ./config.status
[06:06] <minghua> Oops...  where is the "touch stamp-it"?
[06:06] <minghua> infinity: could that be the problem?
[06:06] <infinity> That does seem likely.
[06:06] <infinity> You may want to file a bug on intltool and see if anyone has a clue how those rules are supposed to work . :)
[06:06] <infinity> I'm just going to upload this dirty hack for now.
[06:07] <minghua> infinity: okay, I'll file the intltool bug
[06:13] <minghua> wonderful.  now I can reproduce this infinite loop if I run clean before build
[06:16] <infinity> Excellent.
[06:28] <minghua> infinity: that would be bug #35161 if you are interested 
[06:29] <minghua> ah, our dear bug bot has left
[06:36] <jdub> infinity: thanks for uploading scim-schawing
[06:45] <hendry> where are the collection of Ubuntu diffs on debian
[06:46] <Burgundavia> http://people.ubuntu.com/~scott/patches/
[06:48] <hendry> Burgundavia: cheers
[06:48] <Burgundavia> hendry: np
[06:49] <Burgundavia> hendry: beware, I understand some of the diffs there are a little wierd
[06:51] <hendry> yes. very big
[06:52] <hendry> it would be nicer to have some interface
[06:52] <hendry> it's unreadable to me
[06:52] <jdub> hi kai
[06:54] <fabbione> morning
[07:08] <hendry> jdub: hello
[07:12] <hendry> what are these Italian Ubuntu deriv's called?
[07:14] <Burgundavia> Uffico Zero
[07:18] <hendry> Burgundavia: cheers
[07:21] <hendry> are Debian maintainers considered Ubuntu maintainers?
[07:22] <minghua> hendry: I think no.  and strictly speaking ubuntu doesn't have "maintainers", only "developers"
[07:22] <minghua> hendry: it seems being a DD makes it much more easier to apply for an ubuntu developer though
[07:22] <hendry> http://www.ubuntu.com/partners/become refers to "maintainers"
[07:23] <minghua> oh okay, then I don't know
[07:24] <minghua> there must be people who know better than I :-)
[07:37] <hendry> is there any kind of ubuntu and debian bts syncing?
[07:39] <Treenaks> Launchpad follows Debian bugs if you tell it to
[07:39] <Treenaks> it won't post there thoguh
[07:39] <Treenaks> afaik
[07:41] <hendry> i hear a lot about the ubuntu desktop
[07:42] <hendry> is there any marketing for the "server"?
[07:42] <Burgundavia> not currently
[07:43] <hendry> what's the deal with bugzilla? https://bugzilla.ubuntu.com/show_bug.cgi?id=28846
[07:43] <natroll> hendry, file a bug on bugzilla
[07:43] <Burgundavia> bugzilla has been replaced
[07:44] <hendry> natroll: about?
[07:44] <natroll> hendry, i was kidding
[07:44] <hendry> Burgundavia: so it should be taken down at some point?
[07:44] <Burgundavia> hendry: no, the bugzilla is locked and all the open bugs imported into Malone
[07:45] <hendry> Burgundavia: ok
[07:50] <jdub> boh. you may not have got my full answer.
[07:50] <jdub> :0
[07:50] <jdub> :)
[07:52] <jdub> my isp is filled with awesome
[07:52] <jdub> as is irssi
[07:56] <hendry> are the ubuntu guys going to Debconf6?
[07:57] <jdub> some might be - kinda badly timed, given schedule previous and current
[07:58] <netstar> Why was metacity built without compositor?
[08:00] <jdub> netstar: because it's not ready for inclusion yet by default - search for spifficity
[08:00] <Mithrandir> jdub: he might have more luck if he looks for spiftacity.
[08:01] <netstar> ty
[08:01] <jdub> Mithrandir: you should tell him, lest he miss it
[08:03] <doko> amazing ... the sparc buildd did finish openoffice.org before the i386 buildd
[08:03] <doko> fabbione: ^^^
[08:03] <fabbione> doko: i know
[08:03] <fabbione> sparcbuildd > *
[08:04] <hendry> on the wiki my name is Hendry2. how the hell? who is the other hendry? :)
[08:04] <fabbione> doko: oosmoketest = good :)
[08:04] <fabbione> doko: just wait that James will reboot in the new kernel..
[08:04] <fabbione> doko: that will speed up a bit more too.. readding 512MB of ram to the buildds..
[08:04] <doko> cool, we need to make that run on another display than X:0 as well
[08:05] <doko> s/make/make sure/
[08:05] <fabbione> doko: i only have VNC here for testing..
[08:05] <fabbione> doko: the new iron should arrive either this week or the next
[08:06] <fabbione> that includes a real desktop
[08:06] <fabbione> and a real server...
[08:08] <minghua> hendry: also you? :-  https://wiki.ubuntu.com/hendry
[08:14] <dAndy> who owns autofs in ubuntu, and can they take a look at: 31071 ? Thanks
[08:14] <hendry> minghua: i just made that. Notice the last edited name
[08:14] <hendry> minghua: "scim"?
[08:15] <minghua> hendry: oh I see.  I didn't look at the date of the wiki page.
[08:16] <minghua> hendry: the reason you have hendry2 on wiki is probably due to "hendry" is someone else on launchpad then
[08:16] <minghua> hendry: apt-cache show scim
[08:16] <fabbione> dAndy: i have been assigned autofs bugs, it's in the list with the others..
[08:17] <dAndy> fabbione: ok cool, I added a possible patch to the comments, but then again, I dont know why it was changed between breezy and dapper
[08:18] <fabbione> dAndy: i have no clue of anything.. i only got the autofs bug assinged to me.. i don't even use it
[08:19] <dAndy> fabbione: heh ok, well it is a trivial change, and it is only reverting back to how it was in breezy
[08:21] <fabbione> dAndy: ok thanks for the info
[08:28] <pitti> Good morning
[08:34] <dholbach> good morning
[08:36] <Mithrandir> dholbach: you will soon have a patch for the clock applet to spawn evo on the right day incoming
[08:38] <dholbach> Mithrandir: oh wow
[08:39] <Mithrandir> dholbach: it wants the evo patch I put in last night too to avoid spawning two windows, but it's quite trivial
[08:39] <Mithrandir> dholbach: do you have a bug number for that or should I just file a new one?
[08:39] <dholbach> i'll take a look at it
[08:43] <Mithrandir> https://launchpad.net/distros/ubuntu/+source/gnome-applets/+bug/35167 ; enjoy
[08:44] <dholbach> Mithrandir: merci beaucoup
[08:44] <Mithrandir> dholbach: it doesn't do the right thing when double-clicking appointments yet, but that should be easy enough to add.
[08:44] <Mithrandir> (I'd assume)
[08:44] <Mithrandir> I'm off for a bit, ttyl
[08:45] <dholbach> see you
[08:45] <dholbach> and thanks for the patch
[08:46] <minghua> hello, I need a core-developer to review and upload the patch in bug #35163
[08:47] <minghua> it's for SCIM's autostart feature
[08:47] <minghua> I need this to be uploaded first to work on other scim packages
[08:47] <minghua> and #ubuntu-l10n doen't seem to be very active (asked half an hour ago)
[08:47] <minghua> anyone?  thanks
[08:48] <minghua> https://launchpad.net/distros/ubuntu/+source/scim/+bug/35163
[08:48] <minghua> as our bug bot is gone...
[08:48] <dholbach> minghua: i'll do that
[08:52] <dholbach> minghua: done
[08:52] <minghua> dholbach: thanks, you rock
[08:52] <dholbach> thanks :)
[08:52] <_ion> Anybody willing to try my NetworkManager 0.6.1 packages?
[08:53] <pitti> _ion: we have 0.5.1
[08:53] <_ion> pitti: Yes, that's pretty much the reason why i packaged 0.6.1. :-)
[08:53] <pitti> _ion: Scott explained at length on ubuntu-devel why we can't upgrade
[08:53] <pitti> patches have to be done against 0.5.1 for dapper
[08:54] <pitti> _ion: unless you did all of the steps he mentioned there?
[08:54] <pitti> _ion: i. e. did you port the ubuntu changes, like ifupdown compatibility, removal of name server dependency, etc.?
[08:55] <pitti> (if so, *that* would indeed rock :) )
[08:55] <_ion> My package should be compatible with ifupdown and have no name server dependency.
[08:55] <_ion> I mean no local name server dependency.
[08:55] <infinity> So, you ported all of Scott's patches, then?
[08:55] <pitti> so you could port all the current ubuntu patches to your package?
[08:56] <_ion> Not all of them, but i hope someone could help me in that task. http://johan.kiviniemi.name/ubuntu/
[08:56] <pitti> which ones are still left?
[08:56] <pitti> if the job is 90% done, then this would indeed be worth a try (IMHO)
[08:56] <_ion> Let me see...
[08:58] <siretart> _ion: does your 0.6.1  support wpa? which version of wpasupplicant do you require?
[09:01] <siretart> _ion: I'm asking because I'm just preparing an upload of wpasupplicant to debian which has an patch from the 0.5 branch included, which seems to be needed for nm-0.6.1
[09:01] <mdke> does the TB have an email address?
[09:01] <jdub> technical-board@lists.ubuntu.com
[09:01] <Pygi> mdke: they have mailing list if I am not mistaken
[09:02] <mdke> thanks
[09:03] <_ion> 10-dbus-api-fix.patch is already in upstream. 20-linux-wlan-ng.patch was not ported (src/NetworkManagerDevice.c doesn't exist anymore in 0.6.1). Ditto for 30-blacklist-devices.patch 50-disable-named-and-vpn-managers.patch 60-dispatch-more-events.patch. 40-ubuntu-backend.patch isn't ported (is it still needed?). 65-dispatcher-script-dir.patch and 70-dont-deactivate-new-devices.patch are ported.
[09:03] <_ion> Unfortunately i don't have a WLAN card, i hope someone could help me by testing the package in a WPA network.
[09:04] <pitti> _ion: 40-ubuntu-backend.patch is the central patch that has to be ported
[09:04] <_ion> At the moment the dependency for wpasupplicant isn't versioned.
[09:04] <pitti> _ion: 20-linux-wlan-ng.patch is my hack, if the others are cleared with Keybuk, then I will port that one
[09:05] <pitti> _ion: but I'm afraid 50-disable-named-and-vpn-managers.patch and 40-ubuntu-backend.patch are so central for our needs that they need to be ported to 0.6.1 in a seamless way
[09:06] <pitti> _ion: please don't feel discouraged by that, to the contrary, your efforts are highly appreciated; we just need to discuss how to get it right :)
[09:07] <pitti> Riddell: ok, so I hacked langpack-o-matic to import packages like gwenview now; so unless you found any other important missing bits, I'm going to rebuild the packs now
[09:08] <Mithrandir> _ion: ajmitch has a WPA setup at home, iirc.
[09:09] <_ion> I'll look at porting NetworkManagerUbuntu.c (from 40-ubuntu-backend.patch) to 0.6.1
[09:10] <pitti> _ion: cool :)
[09:11] <mdke> hey jdub, while you're here. start.ubuntu.com?
[09:11] <Pygi> _ion; I can help if somethin' i sneeded?
[09:11] <Pygi> needed*
[09:13] <minghua> pitti: a question about lang-pack -- should all .po files of main packages be stripped and put into lang-pack?
[09:14] <pitti> _ion, Pygi: I can assure you, if you manage to get that done for Dapper, you'll have to fight groupies with a stick^W^W^W^W^W^W^Wthe appreciation of the Ubuntu community will be your's :)
[09:14] <pitti> minghua: ideally yes
[09:14] <Pygi> pitti: hehe ;)
[09:15] <_ion> :-)
[09:15] <pitti> minghua: there are some redundancies for packages which were recently promoted without being rebuilt and such
[09:15] <minghua> pitti: I was just thinking of the scim-* packages that recently entered main.  Almost all of them have .po files
[09:15] <pitti> minghua: yes, they need a rebuild to get stripped (universe packages aren't)
[09:15] <pitti> hi smurf 
[09:17] <minghua> pitti: but things like "* debian/rules: Add gettext domain to .server and .desktop files to get language pack support for them. (Similarly to cdbs' gnome.mk)" only apply to .desktop files, not .po files, right?
[09:17] <minghua> pitti: (that was from your change to scim)
[09:17] <pitti> minghua: right
[09:18] <minghua> pitti: good to know.  thanks for explaining
[09:19] <Pygi> pitti: when does it have to be done, so it would have a chance of being included? ;)
[09:20] <pitti> Pygi: *actually* about four weeks ago, for upstream version freeze
[09:20] <Pygi> pitti: o joy 
[09:20] <pitti> Pygi: so it'll need a serious amount of begging, testing, and review to get it approved now
[09:21] <Pygi> pitti: we'll have masses who will test once they hear package is here ^^
[09:22] <pitti> Pygi: I'm sure that a lot of folks are happy to test it on u-devel
[09:35] <tepsipakki> Hi! As dapper is now getting six week more testing and localisation time, is it possible to add openoffice.org-soikko (+libsoikko) which is a hyphenation addon for OO.o. The problem with libsoikko is that it isn't open source, but freely distributable, so they'd go to multiverse
[09:36] <tepsipakki> it has been packaged for debian and ubuntu for a long time already, and the hyphenation quality is excellent
[09:36] <tepsipakki> ..but I know that freeze is long gone now
[09:36] <Tm_T> tepsipakki: oh yes, soikko coulbe useful
[09:36] <Tm_T> tepsipakki: universe? ;)
[09:37] <tepsipakki> multiverse
[09:37] <tepsipakki> because of libsoikko
[09:37] <tepsipakki> http://users.tkk.fi/~pry/soikko/license.txt
[09:37] <Tm_T> aah
[09:37] <Tm_T> tepsipakki: #ubuntu-motu I think
[09:37] <tepsipakki> i guess.. I'm not sure
[09:39] <tepsipakki> I know the answer from there ;)
[09:39] <Tm_T> and that is?
[09:39] <tepsipakki> "no" :)
[09:39] <Tm_T> don't be so sure
[09:39] <tepsipakki> that's what I'd expect at least :)
[09:39] <tepsipakki> but ok
[10:15] <_ion> NetworkManagerUbuntu.c from 40-ubuntu-backend.patch is pretty much ported. Next i'll have to modify the autotools stuff in order to compile it and see if it works. :-)
[10:16] <pitti> _ion: btw, feel free to throw out the autotools changes from that patch and regenerate it as a separate patch (or just inline)
[10:17] <sivang> morning all
[10:18] <pitti> hi sivang 
[10:21] <_ion> pitti: Hm. Would it be evil to make the patch just replace NetworkManagerDebian.c with the Ubuntu-specific stuff instead of adding a whole new NetworkManagerUbuntu.c? That way there would be no need to fiddle with configure*, Makefile* etc.
[10:23] <pitti> _ion: hmm, it would work for me, but please rather ask Keybuk about it; it's his baby
[10:23] <pitti> _ion: but for the purpose of initial packaging, that's certainly fine
[10:23] <pitti> _ion: we can always restructure it afterwards if the actual thing works and is accepted
[10:23] <_ion> Ok.
[10:26] <jdub> anyone tried today's dapper install cd (not live)?
[10:26] <Mithrandir> jdub: I tried yesterday's; why?
[10:26] <jdub> Mithrandir: works ok?
[10:26] <Mithrandir> jdub: yes, worked fine for me.
[10:28] <jdub> thanks
[10:28] <siretart> _ion: for wpa, you will most probably need this package of wpa: http://siretart.tauware.de/wpasupplicant/, version 0.4.8-1
[10:30] <mroth> ok, maybe its because its 1:30am, but where on earth is the "attach file" function in launchpad?  I'm too used to bugzilla
[10:31] <mroth> er, nevermind, i knew as soon as I hit "enter" i would find it
[10:31] <_ion> siretart: Ok, thanks. I don't have a WLAN with WPA, but Pygi does and he said he'd help with the package. I'll mention about that to him.
[10:32] <siretart> _ion: the network-manager maintainer in debian told me that he needs the ap-scan command in wpa_cli for nm to work with wpa. this command is only in the 0.5 branch available, but the 0.4.8 package I pointed you to has this command backported
[10:33] <_ion> siretart: Ok, nice.
[10:33] <siretart> _ion: so both packages should work, but only the 0.4.8 package is a candidate for dapper at all (and even thats undecided)
[10:39] <Pygi> siretart: no way to get 0.5 branch in?
[10:42] <kagou> hi
[10:56] <mpt> Goooooooooooooooooooood morning Londonpadders!
[10:57] <Tm_T> stop that siren!
[11:03] <doko> dholbach: examplecontent ping
[11:03] <dholbach> doko: i'm on the phone
[11:04] <dholbach> doko: ttyl
[11:05] <siretart> Pygi: the 0.5 branch is considered as the experimental development branch by upstream. it works for me, but I wouldn't recommend to support that branch for years
[11:05] <Pygi> siretart: agreed
[11:05] <siretart> Pygi: the 0.4.8 branch on the other hand was broadly tested and is in maintenance mode. only small and careful updates, perfect for longterm support
[11:06] <ajmitch> morning siretart 
[11:06] <siretart> hi ajmitch 
[11:07] <jordi> jdub: re LAMP, I guess you did see my reference to that after FOSDEM :)
[11:14] <sivang> mpt: this is not #launchpad ? :)
[11:16] <_ion> Btw., in the network-manager-0.6.1 package i put the nm-vpn-properties binary into the nm-applet package. Should it be split to its own package?
[11:20] <Seveas> you should not include vpn
[11:20] <Treenaks> Seveas: vpns rock!
[11:20] <Seveas> currently Ubuntu does not include the VPN stuff for a good reason 
[11:20] <Seveas> Treenaks, nm-vpn not - it's quite flaky
[11:20] <Treenaks> Seveas: ok.. so it needs bugfixing ;)
[11:21] <siretart> Treenaks: it needs a complete development cycle for exhaustive testing. dapper will be supported 3 years on the desktop
[11:21] <neuralis> seveas: i didn't look, what kind of vpns does nm support?
[11:21] <siretart> Treenaks: lets better provide add on packages for dapper, and integrate them into edgy
[11:21] <mpt> sivang, I didn't mention Launchpad :-P
[11:22] <Treenaks> siretart: oh sure
[11:22] <Seveas> _ion, please make sure your package has about the same functionaluty as the current Ubuntu package (ie no bind needed, no vpns etc) but does support wpa
[11:22] <sivang> mpt: you said, launchpadders , but indeed, I guess we're now all lunchpadders as we're using it :)
[11:22] <_ion> seveas: Ok, will do.
[11:22] <Seveas> That's the best way of getting it accepted
[11:22] <mpt> sivang, no I didn't
[11:22] <sivang> err
[11:22] <mpt> :-P
[11:23] <sivang> londonpadders
[11:23] <sivang> mpt: you're also in London now?
[11:23] <Seveas> sivang, you will be pleased to know that Ubugtus webcal plugin is now fully functional, including your request. 
[11:23] <mpt> sivang, temporarily
[11:23] <sivang> Seveas: yay! /me does a happy dance
[11:23] <sivang> mpt: launchpad sprint ?
[11:24] <sivang> Seveas: so how can I ask it for the current ongoing meeting?
[11:24] <mpt> yes
[11:24] <Seveas> not - it's in the topic from 10 minutes before to 30 minutes after the meeting
[11:26] <sivang> very good. thank you!
[11:40] <infinity> dholbach: BTW, goffice is FTBFS.
[11:40] <infinity> dholbach: All arches.
[11:41] <mvo> infinity: any news about the auto-dist-upgrade test setup :) ?
[11:43] <dholbach> infinity: thanks, i'll have a look at it later
[11:43] <infinity> mvo: Stalled for a bit, we need to discuss it with elmo, who just about choked when I mentioned it to him. :/
[11:46] <mvo> infinity: hm, can't we get a (cheap) decicated machine then? I mean, if it's too risky to put it on a machine with other tasks? or I can go and put it on one of my own machines early next week (when I'm back from sprinting)
[11:47] <infinity> mvo: Yeah, we could get one dedicated machine, though we ideally want one per arch.
[11:48] <seb128> infinity: do you have an idea if other GNOME packages are FTBFSing? Launchpad doesn't make easy to look on daily failures, etc
[11:49] <mvo> infinity: right. sometimes the problems are arch-specific unfortunately (ia32-libs exploeded yesterday on amd64)
[11:49] <infinity> seb128: You're right, it doesn't make it easy...
[11:50] <infinity> seb128: https://launchpad.net/distros/ubuntu/+builds?build_state=failed <-- that may help a bit, though.
[11:50] <doko> jordi, seb128: btw, see gnome report #334738, gedit examples ...
[11:50] <doko> mvo: no change in ia32-libs yesterday
[11:50] <infinity> seb128: Be careful of version numbers, since LP still has a bug where it will happily retry obsolete sources..
[11:51] <mvo> doko: I didn't explain myself clearly, it was discovered yesterday by a user, but it may well be a problem for some time
[11:51] <jordi> doko: wrong bug number?
[11:52] <seb128> infinity: is there a way to filter by arch?
[11:52] <infinity> seb128: Not yet, no. :/
[11:52] <doko> jordi: no, "wrong characters in print preview/file"
[11:52] <doko> opened for gnome-print
[11:53] <jordi> doko: doh, I was looking at the bts ;)
[11:53] <seb128> doko: bugzilla.gnome bug
[11:54] <doko> seb128: yes
[12:00] <doko> Kamion: please process OOo-l10n binaries in NEW, and promote them to main
[12:01] <jordi> doko: hmm. Horrible.
[12:01] <jordi> If what appears i nthe preview is what actually appears in the paper, I see what you're saying now :)
[12:01] <pitti> seb128, Riddell: new langpacks on http://people.ubuntu.com/~pitti/langpacks/, this time evenn with amarok and gwenview :)
[12:02] <Kamion> doko: I already did
[12:02] <Kamion> doko|impatient again ;-)
[12:02] <doko> jordi: yes, you actually have to check a printout; best thing, if you do that on a postscript printer.
[12:03] <doko> Kamion: heh, looks like you have an interest in smaller packages ;-)
[12:04] <Kamion> more an interest in the output of queue not overflowing my screen too badly ... one line per binary package
[12:05] <jordi> doko: we have no printer here :/
[12:05] <doko> jordi: not my problem ;-P
[12:06] <jordi> hehe
[12:06] <seb128> pitti: is there any need to try new gnomeish package? :)
[12:06] <seb128> pitti: ie: any change since yesterday?
[12:06] <pitti> just some updates
[12:06] <pitti> might have more translations now
[12:07] <pitti> but I think if I test them, that's good neough
[12:07] <seb128> lemme try
[12:08] <doko> seb128: your gtk changelog: "patch for ia32-libs package" should be a32-libs-gtk package, but that's not in Debian
[12:09] <seb128> doko: I know, that's listed as one of the sync changes, ie: an Ubuntu specific patch
[12:09] <seb128> doko: noted for the package name :)
[12:10] <seb128> pitti: /usr/share/locale-langpack/fr/LC_MESSAGES/test.mo ... is that a package? :)
[12:11] <pitti> hmm, what's in it?
[12:11] <pitti> nm, I have it here
[12:12] <pitti> it must come from a package, yes, I didn't add anythign manually
[12:12] <seb128> k
[12:12] <pitti> [12:12] <pitti> wftl: nevow_0.4.1-1.1ubuntu1: 0 domains, but 1 pot files
[12:12] <pitti> wftl: nevow_0.4.1-1.1ubuntu1: guessing domain from single POT file: test
[12:12] <pitti> bah
[12:13] <pitti> hm, that can't be it
[12:13] <pitti> seb128: I'll refine dload-strippedtarto show the domains it imports
[12:13] <pitti> seb128: but for now it doesn't really hurt, I think
[12:15] <seb128> yeah, just noticed it and was wondering if that's a debug stuff you let :)
[12:15] <seb128> since that's a new .mo
[12:16] <ploum> doko: ping ?
[12:16] <doko> ploum: just ask
[12:17] <ploum> doko: I upgraded OOo today and it re-created the file  opens___.ttf
[12:17] <ploum> so OOo interface is completely broken
[12:18] <ploum> (I know I just can remove the file but I  wanted to told you)
[12:18] <StevenK> Ran 200 tests in 9.233s
[12:18] <StevenK> OK
[12:18] <doko> ploum: no, the file is not there
[12:18] <StevenK> WHEEEEE!
[12:19] <ploum> doko: weird...  I removed the file yesterday. Today I just dist-upgraded and the file is here again
[12:20] <doko> ploum: which version?
[12:20] <ploum> 2.0.2-1ubuntu3
[12:21] <ploum> the opens___.tf is marked as modified today at 7:03AM
[12:22] <ploum> (my computer was off, so I suppose this is the build time of the package or something like that)
[12:24] <ploum> Well, I remove it and I will tell you if something happens again
[12:25] <jordi> mvo, daf and I just decided to start an "autoubuntu" derivative
[12:25] <jordi> with all the autopackage goodness you can get
[12:25] <ploum> (anyway, thanks for the Print-patch drop. Brochure mode is now working again and I'm happy :-) )
[12:25] <seb128> jordi: please go troll somewhere else :p
[12:26] <jordi> seb128: sure, sure. You keep doing those old .deb things.
[12:26] <ploum> jordi: I'm thinking about launching a messedbuntu distro. Using only RPMs
[12:26] <doko> pitti: five new OOo help packages ...
[12:26] <jordi> ploum: we will beat your mess. Our technology is up to it. :)
[12:27] <Seveas> ploum, jordi: I seriously don't know who of you to lart first...
[12:27] <Seveas> you should use klik everywhere!!!112!!!one
[12:27] <pitti> doko: adding them
[12:28] <pitti> doko: hm, I can't see any new ones? did they just came out of NEW?
[12:29] <pitti> doko: nevermind, got them
[12:29] <doko> pitti: yes
[12:29] <doko> ploum: you are right, missed the removal of that file
[12:31] <doko> ploum: you are right, missed the removal of that file
[12:32] <ploum> doko: ok. Thanks for looking :-)
[12:34] <pitti> doko: uploaded
[12:36] <mvo> pitti: we discussed the font perferences stuff again here and the current prefered solution is to make language selector set the fontconfig stuff
[12:36] <pitti> mvo: hm, that's not really a solution, it's a nasty hack that won't solve the actual problem :/
[12:37] <pitti> mvo: but oh well, if nothing else is possible ...
[12:37] <seb128> mvo: do most of people actually use the language selector?
[12:40] <mvo> well, the solution to have special fontconfiles depending on the language is a bad hack already
[12:40] <mvo> and worse, the different chinese variants use different settings apparently
[12:41] <mvo> so zh_TW and zh_CN have different perferences apparently
[12:41] <mvo> the alternative would be to ship the file in seperate package (with a single file) or as part of language-{pack,support}
[12:42] <mvo> it's all pretty bad
[12:42] <mvo> and the zh_TW and zh_CN problems seems to be "delicate"
[12:43] <pitti> heh ;)
[12:43] <fabbione> mdz: do you think it would be possible to have an UVF exception for missingh (universe)? the changes are minor bug fixes, including fix of FTBFS on sparc, that will unleash another big set of pkgs to be built on sparc.
[12:43] <pitti> mvo: can you please explain to me again why removing latin glyphs from the CJK fonts would be bad? (just trying to understand the reason)
[12:44] <mvo> pitti: japanese and chinese have overlapping glyths (the same glyth appera in both languages)
[12:44] <infinity> mdz: missingh is at the base of a twisted maze of haskell build-deps, and the upstream changes look tiny and harmless.
[12:44] <pitti> mvo: so?
[12:44] <infinity> mdz: (TBH, I would have just uploaded and asked forgiveness, rather than permission, but given how strict we've been this release, I didn't want to piss anyone off) :)
[12:44] <pitti> mvo: I didn't intend to split the CJK fonts :)
[12:45] <highvoltage> weird
[12:45] <mvo> pitti: well, there are various problems, one is that on a stock install you can have japanese glyths in a otherwise chinese text
[12:45] <mdz> fabbione,infinity: I have no objection; UVF exception management for universe has been delegated to motu-uvf
[12:45] <pitti> mvo: how woudl removing latin glyphs from the CJK fonts change that?
[12:45] <pitti> mvo: s/change/break/
[12:46] <infinity> mdz: Ahh.  Cool.  Perhaps I should join that group. :)
[12:46] <mvo> pitti: it wouldn't change that at all, but it wouldn't solve this problem either
[12:46] <pitti> mvo: why not?
[12:47] <pitti> mvo: I thought the main itch was that latin looks bad under CJK, and CJK looks bad under latin?
[12:47] <mvo> pitti: that is true but unfortunately only one of the problems, the other one is that chinese and japanese glyths are mixed 
[12:47] <fabbione> mdz: danke
[12:47] <pitti> mvo: I don't think that we can solve *this* problem at all
[12:48] <infinity> fabbione: Shall I do the fake sync?
[12:48] <pitti> mvo: not even with the hack you proposed (or can we?)
[12:50] <fabbione> infinity: go ahead
[12:50] <infinity> Kay, doing.
[12:50] <mvo> pitti: the solution to have different perferences based on the language (THE HACK) will solve it because it moves chinese fonts to the top for chinese and japanese fonts for the japanese users
[12:50] <mvo> pitti: currently it's either japanese fonts have preference or chinese ones. that means one group of to manually fix there setup
[12:50] <pitti> EPARSE
[12:52] <mvo> pitti: sorry, network problems
[12:52] <mvo> pitti: what was the last bit you said/got from me?
 pitti: currently it's either japanese fonts have preference or chinese ones. that means one group of to manually fix there setup
 EPARSE
[12:54] <Lathiat> you forgot your -
[12:54] <mvo> pitti: let me try again. there are certain glyths that are in both chinese and japanese fonts (because both languages have the glyth). when the application asks for that glyth fontconfig will pick a font for it. it will use (among other stuff) the order in which the fonts are listed in the fonts.conf file. if a japanese font is before a chinese one fontconfig seems to pick that
[12:55] <infinity> Lathiat: pitti is unsigned.
[12:55] <daf> hi pitti 
[12:55] <pitti> hey daf
[12:55] <Lathiat> pitti: im sorry
[12:55] <Lathiat> it must be a boring, but simple life
[12:55] <daf> stripping latin glyphs would be hacky but possible
[12:55] <mvo> pitti: that means that you end up with a mostely chinese text with some japanese glyths
[12:55] <daf> I'm not sure what adverse effects it would have
[12:55] <pitti> mvo: right, I agree that using the locale hack is acceptable for that overlap
[12:56] <mvo> ok
[12:56] <pitti> but not for the CJK <-> Latin conflict
[12:56] <pitti> there must be a better solution
[12:56] <pitti> I want to read Chinese spam, and Chinese/Japanese people want to read English
[12:56] <pitti> or write
[12:56] <pitti> Firefox/Console/etc.
[12:56] <mvo> agreed
[12:56] <daf> Abel is going to join us
[12:57] <abelcheung> yes, I'm here
[12:57] <daf> ah, hi Abel
[12:57] <pitti> hi abelcheung 
[12:57] <pitti> abelcheung: ok, so we identified two different problems
[12:57] <mvo> abelcheung is our expert for those matters :)
[12:57] <pitti> abelcheung: did you see the scrollback here?
[12:57] <mvo> pitti: freefont has a script btw to strip out glyphs 
[12:58] <pitti> abelcheung: what would you think about a locale hack to sort out the Chinese/Japanese conflict type, and removig the Latin glyphs from CJK fonts to solve the Latin/CJK conflict?
[12:58] <abelcheung> about stripping latin chars from CJK fonts... (well I didn't think I'm expect in this area)
[12:58] <pitti> mvo: fontconfig with LC_ALL=C works fine, btw :)
[12:59] <pitti> solution 6 :)
[12:59] <_ion>  network-manager (0.6.1-5) dapper; urgency=low
[12:59] <_ion> * Removed named/VPN stuff in order to have about the same functionality as the 0.5.1 package.
[12:59] <abelcheung> yes, there is some benefit; one of the Korean font already did that, it's "EunGuseul Mono"
[12:59] <abelcheung> but....
[12:59] <jordi> abelcheung: well, it's one of the problems zh users have, clearly
[12:59] <pitti> _ion: oh, I don't actually think it's necessary to remove features, just the current backend must continue to work as it does now :)
[01:00] <abelcheung> an uproar might be coming if we really do this
[01:00] <pitti> abelcheung: 'this' -> remove glyphs?
[01:00] <abelcheung> pitti: exactly
[01:00] <pitti> abelcheung: what would you propose instead?
[01:01] <daf> sounds risky
[01:01] <_ion> pitti: Well, that's what 50-disable-named-and-vpn-managers.patch does in 0.5.1.
[01:01] <pitti> I'm aware that this isn't very clean, but I fail to see another solution
[01:01] <pitti> _ion: alright :)
[01:01] <jordi> abelcheung: why would that happen?
[01:01] <daf> what happens if fontconfig specifies latin-only fonts before CJK fonts?
[01:02] <pitti> AFAICS, if the CJK glyphs look crappy in vera, and Latin looks crappy in CJK fonts, then it's sorta obvious to pick the best of each
[01:02] <daf> wouldn't it use latin from the latin fonts and CJK glyphs from the CJK fonts?
[01:02] <daf> Vera has no CJK glyphs
[01:02] <jordi> daf: afaiui, should work?
[01:02] <pitti> daf: right, we could also do it this way aroud
[01:02] <pitti> around, even
[01:02] <_ion> So, now 40-ubuntu-backend.patch and 50-disable-named-and-vpn-managers.patch _should_ be ported/recreated from 0.5.1.
[01:02] <pitti> _ion: rock :)
[01:02] <daf> I don't think DejaVu has any either
[01:02] <abelcheung> daf: right now latin-only fonts are already located before CJK fonts, but somehow when latin glyphs and non-glyphs touch together, the effect is undeterministic
[01:02] <daf> ah
[01:02] <daf> that sounds very much like a bug
[01:03] <abelcheung> non-latin glyphs
[01:03] <abelcheung> daf: yes
[01:03] <jordi> abelcheung: fontconfig bugs?
[01:03] <pitti> rather gtk ones, I assume ?
[01:03] <daf> hmm, could be a pango issue
[01:03] <jordi> pitti: I think this is a joint seb128/keithp sabotage operation
[01:03] <pitti> jordi++
[01:03] <daf> it's difficult to know
[01:04] <pitti> jordi: I tell you, seb128 didn't ever give up solution 6
[01:04] <seb128> solution 6 is the way to go
[01:04] <daf> I thought seb likes solution 7
[01:04] <daf> "make everyone speak French"
[01:04] <pitti> seb128: only with slightly altered parameters :)
[01:04] <Robot101> iz gtk boog
[01:04] <abelcheung> I'd rather use suicide as 6th solution
[01:05] <jordi> where's seb? He should have started kicking people already
[01:05] <pitti> abelcheung: seriously again, if we removed ugly CJK glyphs from fonts which have a higher prio than good CJK fonts, that would have the same effect, wouldn't it?
[01:05] <jordi> oh. he just defended #6.
[01:05] <jordi> hi seb :)
[01:05] <pitti> abelcheung: (if removing latin from CJK would be considered impolite/whatever)
[01:06] <seb128> hey jordi ;)
[01:06] <daf> would stripping CJK from freefont (e.g.) help?
[01:06] <ajmitch> jordi: harassing poor seb again?
[01:06] <abelcheung> pitti: it's mostly publicity effect that makes the stripping action bad.
[01:06] <seb128> don't worry for me :)
[01:06] <abelcheung> pitti: not technically bad
[01:06] <pitti> abelcheung: I don't see how?
[01:06] <pitti> abelcheung: I mean, we don't strip CJK glyphs altogether, we just select the best ones?
[01:07] <daf> ajmitch: don't fall for that "poor gnome maintainer" spiel
[01:07] <abelcheung> say when greek or russian characters were stripped from some fonts, those people will be angry as well
[01:07] <jordi> ajmitch: it's better over planet, as he never replies
[01:07] <pitti> daf: interesting to see that 'spiel' is an accepted English word :)
[01:07] <daf> indeed!
[01:08] <pitti> abelcheung: hm, I'm really no expert in the PR effect of modifying fonts :)
[01:08] <pitti> but ugly glyphs on the desktop should have a worse PR effect than what's behind the scenes, or not?
[01:08] <abelcheung> pitti: latin fonts are already placed beyond non-latin ones, just that they sometimes don't work (worse part is, not always won't work, just sometimes)
[01:08] <jordi> I really don't understand the "bad press" effect either, but I guess we need to trust abel on that :)
[01:08] <seb128> "View your computer storage" -> "View your files and disk space"
[01:08] <jordi> I mean, the change would be for good of zh users
[01:08] <seb128> for computer tooltip
[01:08] <tepsipakki> bah, gnome-screensaver doesn
[01:09] <tepsipakki> 't use pam_sm_setcred()
[01:09] <seb128> what people think about ""Browse all computer files" or ""Browse your computer drives"?
[01:09] <pitti> also, having specialized fonts helps to remove redundancy and makes them smaller; modularity rulez :)
[01:09] <jordi> abelcheung: I appoint you to fix fontconfig, that solves the problem. :)
[01:09] <mvo> I think it's a solution we should try (removing the glyph) if we get feedback from the font-mainters first (and if they don't oppose it)
[01:09] <daf> seb128: B
[01:09] <mvo> if only fontconfig would support the exclusion of certain unicode ranges for fonts ...
[01:10] <pitti> seb128: where is that string?
[01:10] <seb128> daf: thank you :) any better suggestion maybe?
[01:10] <_ion> C) "Format C:"
[01:10] <seb128> pitti: tooltip of "Computer" to Places panel menu
[01:10] <pitti> mvo: which would have the same effect without the benefit of saving disk space...
[01:10] <daf> seb128: I guess "drives" rather than "mounts" is standard
[01:10] <abelcheung> jordi: me? .......... I can try my best, though there might be some bug down from gtk to fontconfig layer that needs attention from corresponding maintainer
[01:10] <daf> seb128: maybe "locations" :/
[01:10] <pitti> seb128: heh, right, the current German translatino for this one is horrible
[01:10] <seb128> "View your computer storage" is current english
[01:10] <daf> hmm
[01:10] <mvo> pitti: yes and it would be a configuration issues, people could revert it (not that easy when they are actually removed)
[01:10] <seb128> silbs suggested "View your files and disk space" but is not sure about it
[01:10] <daf> doesn't it also include network mounts?
[01:10] <seb128> mdz suggested "Browse all computer files"
[01:11] <seb128> daf: no
[01:11] <daf> ok
[01:11] <pitti> mvo: but I guess it is (a) harder to implement and (b) would have an incredible runtime penalty
[01:11] <pitti> mvo: since then the font selection needs to happen for each glyph, doesn't it?
[01:11] <pitti> or does that already happen?
[01:11] <daf> I think it happens for chunks of text
[01:11] <abelcheung> pitti: besides, does fontconfig scan all fonts to pick the most preferred ones for all glyphs?
[01:12] <mvo> (a) <- yes (b) I'm not sure, there is a cache for this
[01:12] <pitti> abelcheung: currently fontconfig only selects per-family, not per unicode block
[01:12] <daf> I'm not sure, for example, whether Firefox passed the language of each paragraph to fontconfig when selecting fonts
[01:12] <pitti> abelcheung: so it's not 'all' glyphs
[01:12] <abelcheung> pitti: I see
[01:12] <daf> or if it just specifies one language for each page
[01:13] <pitti> but I don't really know about fontconfig details
[01:13] <pitti> daf: I hope not :)
[01:13] <daf> you can do <p xml:lang="zh">...</p>, but I don't know if this has any effect on font selection
[01:13] <jordi> abelcheung: was kidding, sorry :)
[01:15] <mvo> pitti: we will try the "remove glyphs" approach here locally after lunch to see what it looks like
[01:16] <pitti> mvo: yes, that would be nice :)
[01:16] <mvo> :)
[01:16] <pitti> good_press('works for everyone' good font config by default) - bad_press('messing up fonts') >> 0 hopefully :)
[01:17] <daf> :)
[01:17] <pitti> as for the C/J conflict, the only real solution would be that both C and J glyphs would look equally well in all fonts that provide both, right?
[01:18] <pitti> s/both/either/
[01:20] <daf> I'm not sure it's possible to have one font that will please both Chinese and Japanese users
[01:20] <daf> they prefer different styles
[01:20] <daf> abelcheung: is that correct?
[01:21] <pitti> we need one for every family, right?
[01:21] <pitti> they probably don't have serifes, but certainly a different set of families
[01:21] <daf> right
[01:21] <mjr> yes, there are differences in recommended renderings in Chinese and Japanese
[01:21] <daf> e.g. Japanese has "kochi", "mincho" and "marumoji" families
[01:22] <daf> sorry, s/kochi/gothic/
[01:32] <ogra> seb128, redhat has a preferences-merged/ dir in gnome-menus, do we have a equivalent to add <Include>/<Exclude> statements ? 
[01:39] <abelcheung> daf: yes, that's correct, they prefer different styles
[01:44] <sladen> killall -9 gnome-screensaver && echo DIE HARDER
[01:47] <ogra> sladen, good idea :/
[01:47] <Riddell> pitti: lang packs are good for me
[01:47] <pitti> Riddell: thanks
[01:48] <seb128> ogra: what do you mean?
[01:48] <seb128> ogra: what are you trying to do?
[01:49] <ogra> seb128, adding a file to g-s-s that hides the xscreensaver entry from the menu
[01:49] <ogra> i see that redhat just drops a file with an exclude statement into /etc/xdg/menus/preferences-merged
[01:50] <seb128> ogra: put NotShowIn=GNOME for xscreensaver and you are done
[01:50] <ogra> heh
[01:50] <ogra> ok, we're easier ::)
[01:50] <ogra> seb128, thanks :)
[01:50] <seb128> np
[01:53] <ogra> err
[01:53] <ogra> seb128, that will hide it forever ...
[01:53] <ogra> i want it shown if g-s-s is not installed
[01:53] <seb128> from GNOME yeah
[01:53] <seb128> ah
[01:53] <BenC> Wow, OOo, gcc, gnome and some xorg all in one night...wish I had uploaded the next kernel to really make it a nice update :)
[01:53] <seb128> suck to be you
[01:53] <ogra> :P
[01:53] <KaiL> hmm, beagle wants those "extendes attributes", out kernel has them - so, why aren't they enabled in /etc/fstab?
[01:54] <seb128> KaiL: because we don't ship beagle by default?
[01:54] <KaiL> oops ;)
[01:58] <pitti> seb128: hm, beagle-dev is still in universe
[01:58] <pitti> seb128: (for the nautilus issue)
[01:59] <pitti> seb128: and beagle is not yet approved for main
[01:59] <dholbach> doko: pong
[01:59] <seb128> pitti: I though you approved it for main
[01:59] <pitti> no, reviewed it
[01:59] <pitti> the bugs are simple enough to fix, I guess
[01:59] <pitti> but noone did it so far
[02:00] <pitti> I'd be fine with depending on beagle-dev now if anyone fixes beagle
[02:00] <seb128> I didn't take your comment as a "must be fixed before promotion"
[02:00] <seb128> tseng: ping? :)
[02:00] <pitti> just to avoid promoting, and then forgetting about it
[02:01] <pitti> mvo: enjoy!
[02:01] <pitti> mmm, lunch, will do the same
[02:07] <zul> heylo
[02:08] <Kamion> Kinnison: gparted seems to be hanging on apply here - all I told it to do was create two partitions
[02:08] <Kamion> absolutely bugger-all happening in strace
[02:09] <natroll> doesn't sound very nice
[02:14] <tseng> seb128: yo
[02:14] <seb128> tseng: hi
[02:14] <seb128> tseng: did you have a chance to look on beagle bugs pitti pointed for promotion?
[02:14] <sivang> tseng: hey
[02:15] <Kamion> Kinnison: BTW, your emacs appears to be enthusiastically converting tabs to spaces in some of the installer-mode patch, which makes it a bit hard to read in places
[02:15] <infinity> mdz: Okay to sync db4.2 (no more diff, yay!), db4.3 (manpages added), and db4.4 (manpages, and a hang in libdb4.4 fixed)?
[02:15] <Kamion> particularly when looking at the ubuntu2 -> ubuntu3 diff
[02:16] <infinity> mdz: I just merged all the Ubuntu changes into the Debian packages, so it'd be nice to go the other way and have them in sync finally. :)
[02:19] <Keybuk> heh, under an hour to spare!
[02:20] <_ion> keybuk: Hi
[02:21] <Keybuk> hey
[02:21] <_ion> keybuk: Could you please inspect 40-ubuntu-backend.patch in http://johan.kiviniemi.name/ubuntu/ ?
[02:21] <Keybuk> what does it change?
[02:21] <infinity> mdz: And I have no idea why I just asked that, since it's neither an upstream version bump of a feature change, just bugfixes.
[02:22] <infinity> s/of/or/
[02:23] <_ion> keybuk: Well, i ported the patch to network-manager 0.6.1 (hopefully correctly :-) ). Also: < _ion> pitti: Hm. Would it be evil to make the patch just replace NetworkManagerDebian.c with the Ubuntu-specific stuff instead of adding a whole new NetworkManagerUbuntu.c? That way there would be no need to fiddle with configure*, Makefile* etc. < pitti> _ion: hmm, it would work for me, but please rather ask Keybuk about it; it's his baby < pitti> _ion: ...
[02:23] <_ion> ... but for the purpose of initial packaging, that's certainly fine < pitti> _ion: we can always restructure it afterwards if the actual thing works and is accepted
[02:24] <Keybuk> ok, I'll have a look at it
[02:24] <Keybuk> see how different it is to my own effort here
[02:24] <_ion> Thanks.
[02:24] <Keybuk> no, thank you :)
[02:28] <tseng> seb128: yes, we have been working alot more on evolution-sharp bug
[02:28] <tseng> seb128: it looks like slomo fixed it, but i didnt get to check yet.. it was a real showstopper
[02:29] <seb128> tseng: ah, nice
[02:29] <seb128> slomo_: ping?
[02:29] <tseng> seb128: do you still want to promote it?
[02:29] <seb128> tseng: why not?
[02:29] <slomo_> seb128, tseng: beagle/evo-sharp seems to work fine for me now... no crashes, no memory filling :)
[02:29] <tseng> because its late, and its dapper
 I'd be fine with depending on beagle-dev now if anyone fixes beagle
[02:29] <tseng> ok.
[02:30] <seb128> tseng: it should have 0 impact on the desktop if beagle is not installed
[02:30] <tseng> let me look at that autostart
[02:30] <Kamion> fabbione: I still need the disk selector in partman-auto. How's that going?
[02:30] <seb128> the fallback is a few lines of code
[02:32] <tseng> seb128: it looks like novell has their whole desktop relying on it now
[02:32] <seb128> yeah
[02:33] <seb128> they have GTK filechooser, yelp, deskbar, nautilus using it
[02:33] <tseng> they have gtk 2.10?
[02:33] <seb128> dunno, I've not figured when yo find srpms for suse
[02:33] <tseng> they are really hard to find for nld
[02:33] <seb128> but that's possible they have 2.8 with the beagle patch
[02:33] <tseng> they are in novell forge
[02:34] <tseng> Keybuk: it has some semi-intelligent throttling
[02:34] <seb128> I don't know, I just supposed since federico blogged about it
[02:34] <seb128> tseng: do you have an URL for that? :)
[02:34] <tseng> Keybuk: the scheduler slows down on battery power, speeds up when a screensaver is active
[02:34] <tseng> Keybuk: 0 throttling with EXERCISE_THE_DOG=1
[02:35] <Keybuk> right
[02:35] <Keybuk> it still has to "find" on whatever it wants to watch though
[02:35] <Keybuk> inotify is teh suck
[02:36] <tseng> better than no inotify
[02:36] <slomo_> seb128: would you want gsf support in beagle? it's not yet enabled because our gsf-sharp is too old... but seems like something useful to me
[02:36] <Keybuk> I still want *something* to notify userspace of mounts and unmounts
[02:36] <seb128> slomo_: what is gsf?
[02:37] <Keybuk> seb128: I have a HAL/GnomeVFS bug for you ... I have a floppy icon
[02:37] <seb128> Keybuk: do you have a /etc/fstab floppy entry?
[02:37] <Keybuk> seb128: yes
[02:38] <seb128> so you get an icon ...
[02:38] <Keybuk> I have a floppy drive too
[02:38] <Keybuk> right, that's not the whole bug yet
[02:38] <Keybuk> due to the PNP bug, I don't have "floppy" loaded
[02:38] <Keybuk> if I modprobe floppy; I get /dev/fd0
[02:38] <Keybuk> and *another* floppy icon
[02:38] <Keybuk> so HAL/GnomeVFS things I have two floppy drives
[02:38] <slomo_> seb128: your country... starts with g ;) libgsf is for reading all kind of document formats afaik
[02:38] <seb128> slomo_: hehe
[02:39] <seb128> Keybuk: I would be tempted to say that we should not put an fstab entry for it :)
[02:39] <Keybuk> seb128: some people still like to mount and unmount their floppy the old fashioned way
[02:40] <Keybuk> HAL/GnomeVFS should be intelligent enough to see the "newly added" floppy drive has the same DEVNAME as the one in /etc/fstab
[02:40] <Keybuk> (modprobe floppy results in /dev/fd0 ... which is what the entry in fstab has)
[02:40] <seb128> yeah
[02:40] <Keybuk> where should I file the bug?
[02:40] <seb128> gnome-vfs probably
[02:41] <slomo_> seb128: well, i'll test it here now... and tseng will file a UVF exception for beagle to get us the newest bugfix release
[02:42] <seb128> thank you
[02:42] <Keybuk> seb128: either that, or HAL/GnomeVFS should ignore fstab entries for which the device doesn't exist :p
[02:43] <seb128> that case should be fixed yeah
[02:43] <seb128> the "look for duplicate" is a bonus then :)
[02:44] <Keybuk> no, it's safe against that at least
[02:45] <Keybuk> bug 35191 anyway
[02:45] <Ubugtu> malone bug 35191 in gnome-vfs "Duplicate floppy icons" [Normal,Unconfirmed]  http://launchpad.net/bugs/35191
[02:45] <seb128> thank you
[03:00] <seb128> what would people use instead of "Log out <username>..." for the menu item name?
[03:00] <seb128> Mark suggested "Quit", what do you think about it?
[03:01] <_ion> IMO "Log out foo" is very good, "Quit" would be more confusing.
[03:01] <daf> what's hte problem with "Log out..."?
[03:01] <Amaranth> i like "Log out <username>..."
[03:02] <dholbach> because you not just log out there, you can lock your screen as well, switch user, ...
[03:02] <janimo> "Finish"
[03:02] <seb128> daf: Mark doesn't like it 
[03:02] <seb128> and right
[03:02] <daf> won't changing this string affect l10n coverage?
[03:02] <_ion> "Kill self"
[03:02] <seb128> there is the fact the Ubuntu session dialog allow to does stuff like locking screen
[03:03] <dholbach> "Leave session"
[03:03] <pitti> seb128: the only thing that embraces all 7 options is 'Fiddle with my session...' :/
[03:03] <seb128> dholbach: locking is not leaving it :)
[03:03] <daf> pitti++
[03:03] <dholbach> but session was deemed too technical
[03:03] <dholbach> seb128: you leave it alone for some time :)
[03:03] <seb128> daf: we have rosetta .... 
[03:03] <pitti> dholbach: 'log out' is heavily technical, too
[03:04] <jdub> seb128: "kthxbye"
[03:04] <seb128> jdub: :)
[03:04] <dholbach> i like leave session with a funky icon, it should be ok
[03:04] <pitti> "Don't wanna play any more"
[03:04] <_ion> jdub: :-D
[03:04] <seb128> "Are you sure you want to do that"
[03:04] <_ion> "I'm afraid i can't let you do that, <user>"
[03:05] <dholbach> "take my ball and play elsewhere"
[03:05] <jdub> seb128: "Install unpatched gnome-panel..."
[03:06] <pitti> we really can't split 'End session...' and 'Pause session...'?
[03:06] <pitti> and we have to accomodate 'switch user', too
[03:06] <jdub> pitti: upstream does this quite nicely...
[03:07] <jdub> (using a similar approach to windows xp and mac os x, splitting these two sets of functions)
[03:07] <seb128> upstream is not the discussion
[03:07] <jdub> :-)
[03:07] <seb128> we have to stick with what we have
[03:07] <seb128> and I would like a panel item title...
[03:07] <jdub> was getting to explain to pitti that we are specifically not doing it that way
[03:08] <pitti> jdub: but there is a feature missing: 'Open email client' (8th button)
[03:08] <jdub> pitti: dapper+1 :-)
[03:08] <tseng> pitti: :D
[03:08] <pitti> seriously, the current thing is pretty confusing
[03:09] <_ion> pitti: In addition, i think the dialog should have a "run interactive ruby in shell" button as well.
[03:09] <jdub> seb128: i think log off ends up being the best compromise for that entry
[03:10] <jdub> seb128: what's the tooltip for the top right button?
[03:10] <seb128> "Log out of this session to log in as a different user" beeing changed now by "Leave this session" 
[03:10] <pitti> jdub: 'log off' says nothing to normal users, or does it have a common non-geek meaning in English?
[03:10] <seb128> change from silbs mail
[03:11] <jdub> pitti: it's very widely accepted jargon
[03:11] <pitti> jdub: does it convey the fact that 4 of the 7 options don't log you out?
[03:12] <jdub> pitti: no, but it's the most reasonable compromise, considering that's what we have to deal with
[03:13] <pitti> jdub: what about 'End/pause session'?
[03:13] <janimo> How about "Back to real life"
[03:13] <jdub> pitti: session means even less, and end/pause are extremely uncommon in this context
[03:14] <jdub> windows has 'switch user' behind its 'log off' set of choices too
[03:14] <pitti> also suspend and hibernate?
[03:14] <jdub> no
[03:14] <jdub> as said above, windows xp and mac os x both have the same strategy as upstream
[03:15] <pitti> 'Go away from the computer'
[03:15] <pitti> :)
[03:16] <jdub> (osx splits them by listing sleep/restart/shutdown and "log out <user>..." as separate menu entries
[03:17] <jdub> sorry: sleep, restart..., shut down... and log out <user>...
[03:17] <pitti> seb128: hm, so shall I upload the current nautilus, or wait for sb to fix beagle?
[03:18] <seb128> pitti: go for it
[03:18] <pitti> yes, give the buildds something to grind :)
[03:23] <Mithrandir> seb128: xkeyboard-config 0.8 is a tad icky wrt merging, but I think it's doable.
[03:24] <KaiL> how to raise a bugs importance? Having no X after installing is imho rather critical... https://launchpad.net/distros/ubuntu/+source/xserver-xorg-driver-ati/+bug/35194
[03:24] <Ubugtu> malone bug 35194 in xserver-xorg-driver-ati "activated but not usable on X1xxx" [Normal,Unconfirmed]  
[03:24] <seb128> Mithrandir: do you need merging? I just updated current package to 0.8 which works fine
[03:24] <seb128> Mithrandir: Debian moves stuff too /usr/share, we don't need that for that cycle
[03:24] <Mithrandir> seb128: you did? Have you uploaded it already or just waiting so far?
[03:25] <seb128> Mithrandir: no, I've just tested on my box
[03:25] <seb128> Mithrandir: but didn't merge anything, just apt-get source xkeyboard-config, copied debian dir to new source and debuild dpkg-i
[03:25] <Mithrandir> seb128: 'k, if you'd like to drop the packages somewhere I can get at them, I'd appreciate.
[03:25] <Mithrandir> hmm, ok.  There's a bunch in the .diff.gz, unsure how much we need, though
[03:26] <seb128> daniels said that's mainly 0.7 stuff he backported I think
[03:26] <seb128> before 5.10
[03:26] <seb128> I can ping him about it if you want
[03:27] <seb128> diff seems quite short
[03:28] <Mithrandir> I'll ping him and see if there's anything we should be careful about.
[03:28] <Mithrandir> it seems to include an awful lot of generated files in the source
[03:28] <Keybuk> Mithrandir: basically I've had three or four reports that a LiveCD has wireless-* options in /etc/network/interfaces
[03:29] <Keybuk> (which prevents n-m from workign)
[03:29] <seb128> Mithrandir: 
[03:29] <seb128> mar 15 23:18:24 <seb128>        do you know if that's a risky update?
[03:29] <seb128> mar 15 23:18:38 <seb128>        or if 0.8 should be as good or better than 0.6?
[03:29] <seb128> mar 15 23:19:34 <daniels>       0.8 should be fine, the last really intrusive thing they did was all the fixes that went into 0.7 that I pulled back into 0.6
[03:29] <seb128> Mithrandir: that's from yesterday
[03:29] <Mithrandir> seb128: ok, so we're really at 0.7, not 0.6.
[03:30] <Mithrandir> Keybuk: given that what casper does is:
[03:30] <Mithrandir> for interface in /sys/class/net/eth* /sys/class/net/ath*; do [ -e $interface ]  || continue i="$(basename $interface)" cat >> "$IFFILE" <<EOF
[03:30] <Mithrandir> auto $i
[03:30] <Mithrandir> iface $i inet dhcp
[03:30] <Mithrandir> that's quite impressive.
[03:30] <Mithrandir> EOF
[03:30] <Mithrandir> done
[03:31] <Keybuk> ok...
[03:31] <Keybuk> so casper doesn't run anything that does wifi network detection?
[03:31] <Keybuk> that was basically my question -- I know the installer *does*
[03:31] <Mithrandir> no, it doesn't.
[03:31] <seb128> Keybuk: maybe people use the network-admin tool
[03:31] <Mithrandir> I suspect those people have used a tool themselves or are reports from breezy.
[03:31] <Keybuk> definitely Flight 5
[03:32] <bddebian> Heya
[03:32] <Kyral> hey bddebian
[03:32] <Mithrandir> Keybuk: very weird.
[03:32] <bddebian> Hi Kyral
[03:33] <jdub> Keybuk: do we need to put in a setting in network-admin for autoconfigure?
[03:33] <jdub> ie. bugger off all settings?
[03:33] <seb128> jdub: network-manager you mean?
[03:33] <jdub> doesn't make sense in the case where they're not using n-m though :(
[03:33] <bddebian> infinity: Adding cpqarray to /etc/mkinitramfs/modules and doing update-initramfs -u worked.
[03:34] <Keybuk> jdub: "enabled and dhcp" is sufficient for auto
[03:34] <jdub> seb128: no, n-a, so /e/n/i settings can be removed
[03:34] <bddebian> Thanks again ogra and Keybuk
[03:34] <jdub> Keybuk: ah, ok
[03:34] <Keybuk> it's when they add other settings like "use only this essid" that n-m buggers off
[03:34] <jdub> right
[03:34] <jdub> so, perhaps that would work then
[03:34] <jdub> on the device page, put autoconfigure
[03:34] <infinity> bddebian: Great, can you formally file a bug so I don't forget?  (It's 1:30am here)
[03:34] <bddebian> Ouch
[03:34] <jdub> (which would just autoconfigure really dumbly without n-m)
[03:35] <bddebian> infinity: I'd be happy to but what is the "bug"?  Just adding cpqarray to initramfs?
[03:35] <Kamion> Keybuk: how hard would it be to grow an option in nm-applet to let you say "no, really, manage this interface already"
[03:35] <Keybuk> jdub: "Enable this connection", "Configuration: DHCP"
[03:35] <Kamion> ?
[03:35] <Keybuk> Kamion: VERY.  With extra figlet.
[03:35] <Keybuk> nm-applet communicates to NetworkManager via dbus
[03:35] <Kamion> yum
[03:35] <Keybuk> it would involve a huge amount of pain
[03:35] <infinity> bddebian: Yeah, "my hardware need cpqarray to boot, and you don't include it, you big jerk"
[03:35] <bddebian> Hehe, OK
[03:35] <Keybuk> and stuff *way* outside of my knowledge sphere atm
[03:36] <jdub> Kamion: see, i'm basically asking the same question, but the other way around :)
[03:36] <Kamion> but dbus is such a good idea and should be used for absolutely everything :P
[03:36] <Keybuk> dbus, like the rest of the GNOME and fd.o stuff is *so* well documented
[03:36] <Keybuk> OH YES
[03:36] <bddebian> infinity: Are main bugs in LaunchPad now?
[03:36] <Keybuk> one day I'm going to get a very large hammer and explain to everyone that a file collating the comments above functions is *not* documentation
[03:36] <dholbach> bddebian: yes
[03:36] <bddebian> Heya Daniel
[03:37] <infinity> bddebian: Have been for ages now.
[03:37] <Kamion> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-January/000054.html
[03:37] <bddebian> Well I have been out of the loop for several months :(
[03:38] <Keybuk> all I've found for dbus so far is a twisty maze of API documentation, with no hints about where to start, or even what the general purpose of any given set of functions is for
[03:38] <Keybuk> and a tutorial/primer that's so out of date, *none* of the functions mentioned exist in the API anymore
[03:38] <jdub> Keybuk: talk to Robot101 - i think he had some better stuff
[03:40] <bddebian> infinity: Sorry, one last stupid question.  File it against initramfs?
[03:41] <infinity> bddebian: initramfs-tools
[03:41] <bddebian> OK, thx
[03:42] <seb128> Mithrandir: what did you hack on for gdm?
[03:42] <Mithrandir> seb128: the "focus the right window when starting up" bug I told you about.
[03:43] <Mithrandir> seb128: only affects xinerama setups.
[03:43] <seb128> right, I remember this one, you got a patch?
[03:43] <Mithrandir> https://launchpad.net/distros/ubuntu/+source/gdm/+bug/28712
[03:43] <Ubugtu> malone bug 28712 in gdm "gdm loses focus when mouse pointer is outside window (when initially started)" [Normal,Unconfirmed]  
[03:43] <Mithrandir> yeah, there's a patch inline
[03:43] <seb128> ah, nice
[03:43] <seb128> I'm lagging behind on bugs mails atm
[03:45] <Mithrandir> I also hacked a bit on libpam-tmpdir/gdm interaction since gdm installs a SIGCHLD handler which, well, is unfortunate when you run stuff and want to catch the exit status.
[03:50] <tseng> pitti: i just made a patch for your beagle uri bug
[03:50] <pitti> tseng: cool
[03:50] <pitti> tseng: adding an autostart .desktop is certainly trivial as well?
[03:50] <tseng> pitti: yep
[03:51] <xhaker> Keybuk: do you happen to know if n-m allows one to specify the key index of WEP ?
[03:51] <Keybuk> I would expect so
[03:51] <Keybuk> I know about -> <- this much about WEP
[03:52] <Keybuk> which is slightly more than I know about WPA :p
[03:52] <Treenaks> WEP has 4 key 'slots'. n-m doesn't allow you to specify any key but the primary one.
[03:52] <Treenaks> afaik
[03:53] <xhaker> Treenaks: my point :S
[03:53] <Treenaks> xhaker: But those other keys aren't necessary in 99% of cases
[03:53] <Treenaks> xhaker: ime
[03:53] <xhaker> i don't think they did that in the GNOME spirit, they're on crack
[03:53] <Treenaks> (because you can just choose one of the 4 keys set in the AP to communicate with it)
[03:54] <Treenaks> xhaker: no, it's just because not many people use it -- so it isn't high-priority for them to add it... I gues they'll gladly accept a patch.
[03:54] <Treenaks> (probably)
[03:54] <xhaker> you setup in the AP what key is used to associate with it.. if it's the second you have to specify the  second key an te index 2
[03:55] <xhaker> in the app of course
[03:56] <Treenaks> xhaker: you do? I could always select any of the 4 keys in the primary slot and it'd just work
[03:56] <Treenaks> (and yes, all slots had a different key)
[03:56] <xhaker> i'm having trouble implementing this feature on gtkwifi, UI wise.. asking for the key index in a dialog is wierd
[03:56] <Treenaks> xhaker: So I think the original meaning of those key slots has been lost in the void
[03:56] <Treenaks> xhaker: dropdown
[03:57] <xhaker> in front of the key text entry ?
[03:57] <Treenaks> xhaker: no, separate line, with a label 'Primary key
[03:57] <Treenaks> '
[03:57] <xhaker> i was thinking hiding it below with a ">"
[03:58] <Treenaks> could do that too
[03:58] <Treenaks> together with the _other_ 3 key entries
[03:59] <xhaker> ohh.. you gave me an idea
[03:59] <xhaker> have 4 key entry slots and 3 of the hidden
[04:00] <xhaker> i just don't now what users would prefer
[04:01] <Treenaks> xhaker: 1 key entry slot, 3 hidden
[04:02] <xhaker> Treenaks: i have to code a mechanism that disables all entry slots when one has a key written
[04:02] <Treenaks> why?
[04:02] <xhaker> so i can send to the ap the right key index
[04:03] <Treenaks> uhr...
[04:03] <Treenaks> I still can't figure out what key index is for
[04:03] <Treenaks> +the
[04:03] <xhaker> Treenaks: i don't also really, it's like a second secret besides the key! :S
[04:04] <Treenaks> xhaker: You can also enter 4 keys... that makes it even weirder
[04:04] <xhaker> to associate you have to send the pair.. key-index & actual-key
[04:05] <Treenaks> xhaker: I'd ask the network-manager mailing list about this if I were you
[04:05] <Treenaks> xhaker: they must have some wifi gurus hanging around there too :)
[04:05] <bddebian> infinity: Bug submitted, thx
[04:07] <jdub> pitti: which files are the separated .desktop translations in?
[04:07] <pitti> jdub: the normal application .mo files
[04:07] <jdub> ahr
[04:08] <pitti> jdub: that's where the .desktop translations come from in the first place
[04:08] <pitti> jdub: (source package build calls intltool-merge for 'untranslated .desktop + .po -> translated .desktop'
[04:10] <jdub> pitti: so loading the menus means opening every application .mo file?
[04:10] <pitti> jdub: right, that's what we were concerned about when specing this
[04:11] <pitti> jdub: but when I did the benchmarks with our implementation, it was negigible
[04:11] <jdub> cool
[04:11] <jdub> pitti: have you hit xdg with this idea?
[04:11] <pitti> jdub: https://wiki.ubuntu.com/LangpacksDesktopfiles has the benchmark
[04:11] <pitti> jdub: they know the idea, but I didn't show them our benchmark and implementation yet; I planned to, but I can do that closer to the release
[04:12] <jdub> pitti: ok
[04:12] <jdub> pitti: great
[04:12] <pitti> when I have more time for discussion and less opportunities to fix bugs :)
[04:12] <jdub> pitti: i'm just showing it to some gnome folks now
[04:15] <janimo> Lathiat: ping
[04:16] <Keybuk> pitti: is there any reason that dhclient would decide not to deal with an interface?
[04:16] <Keybuk> does it do anything like check for link?
[04:16] <pitti> Keybuk: I can't say off-hand, but I doubt it
[04:17] <pitti> Keybuk: you allude to the bug that n-m sometimes doesn't get an IP with DHCP and uses a zeroconf one instead?
[04:17] <Keybuk> no
[04:17] <pitti> Keybuk: if I have my card in /e/n/interfaces, I never have problems with dhcp, just with n-m
[04:18] <Keybuk> the fact that "ifup -a" on boot runs dhclient on the wifi card, when there's no associated AP
[04:18] <Keybuk> instead of the one in the background running
[04:18] <pitti> hm, no idea
[04:18] <Keybuk> no, me neither
[04:19] <pitti> but it should pick up an already running dhclient for an interface
[04:19] <Keybuk> it's annoyingly hard to debug
[04:19] <pitti> if not, that's a bug
[04:19] <Keybuk> the problem is that there's no dhclient running for that interface
[04:19] <Keybuk> it exits, rather than persisting
[04:20] <Keybuk> and because if exists, ifup registers the interface as "down"
[04:20] <Keybuk> s/if exists/it exits/  (damn, can't type)
[04:21] <Keybuk> and because the interface is down, "ifup -a" tries to bring it up again, in the foreground
[04:21] <xhaker> Treenaks: http://forums.macosxhints.com/archive/index.php/t-15556
[04:23] <xhaker> Treenaks: i guess apple and gnome are trying to make people forget the other 3 keys
[04:23] <seb128> ogra: what do you call "make preferences .desktop file an alternative" ?
[04:23] <seb128> ogra: as in "update-alternative"?
[04:23] <Treenaks> xhaker: because nobody uses them
[04:23] <Treenaks> xhaker: (almost)
[04:23] <xhaker> it's part of the standard though :/
[04:23] <ogra> seb128, yep
[04:23] <seb128> ogra: arg, DON'T
[04:23] <ogra> seb128, why ? 
[04:23] <seb128> back this off
[04:24] <ogra> its the only possibility
[04:24] <seb128> because that's abusing of alternatives
[04:24] <ogra> thats the reason for alternatives 
[04:24] <seb128> (and I hate alternatives, that's bug prone)
[04:25] <seb128> ogra: no, that's not, the reason of alternatives is to make a default program on a generic name
[04:25] <seb128> not to mask a menu item from GNOME menu
[04:25] <seb128> that's so ugly and not needed
[04:25] <ogra> seb128, then implement the masking upstream and others define, i'd happily use .merge files if we'd support them
[04:25] <seb128> if you don't revert it I'll
[04:26] <jdub> seb128: ogra is using alternatives for everything now :-)
[04:26] <ogra> jdub, where its necessary, yes
[04:26] <seb128> it's so not necessary here
[04:26] <jdub> nor for distributor-logo ;-)
[04:26] <seb128> we don't use one for distributor-logo, do we?
[04:26] <ogra> seb128, so tell me whats the solution please
[04:26] <ogra> seb128, nope
[04:26] <jdub> seb128: no, but ogra wanted to ;-)
[04:27] <seb128> ogra: I gave you one this morning which is good enough imho
[04:27] <ogra> seb128, no, it isnt
[04:27] <seb128> if people want xscreensaver under GNOME they can use the menu editor
[04:27] <seb128> ogra: I've firefox and epiphany to my menu, should I make those an alternative?
[04:27] <ogra> seb128, completely disabling xscreensaver doesnt make sense if i can solve it 
[04:27] <seb128> alternatives for every .desktop party
[04:28] <ogra> seb128, if they would produce 100% identical menu entries, i'd opt for an alternative for ff and ephi, yes
[04:28] <seb128> change the icon for one of those then
[04:28] <ogra> so the installed and preferred one is in the menu
[04:28] <seb128> if that's your only issue
[04:28] <ogra> nomeata, it isnt
[04:29] <ogra> grr
[04:29] <jdub> nice problem
[04:29] <ogra> nomeata, it isnt
[04:29] <ogra> ARGH !!!
[04:29] <xhaker> seb128: i do think the browser should not be made an alternative.. but the first panel button should point to the default gnome browser set in preferences
[04:29] <jdub> hrm, can't use TryExec testing
[04:29] <seb128> xhaker: already discussed
[04:29] <xhaker> seb128: it was?
[04:29] <xhaker> seb128: any logs?
[04:29] <jdub> ogra: i like this problem
[04:29] <seb128> xhaker: yep, ubuntu-desktop list
[04:29] <ogra> jdub, i can exec both if both is installed, i doubt that would solve it
[04:30] <seb128> mask xscreensaver by default
[04:30] <jdub> ogra: no, that's why i said "can't use TryExec testing" :)
[04:30] <ogra> jdub, there is a solution in xdg we dont have impelmented
[04:30] <seb128> and let people unmask it :)
[04:30] <jdub> seb128: you are a fascist!
[04:30] <xhaker> haha
[04:30] <seb128> jdub: and you like that :p
[04:30] <seb128> no? :)
[04:30] <jdub> seb128: hater of cute things and freedom!
[04:30] <sladen> seb128: even better, you could mask *both* of them.  Then the user wouldn't get confused at all...
[04:31] <xhaker> especially cute things
[04:31] <jdub> seb128: lover of fish smelling things!
[04:31] <ogra> jdub, xdg apparently can use .merge files it merges in the directory files dynamically, there you can include <Include>/<Exclude> directives for entries, redhat uses that for xscreensaver
[04:31] <seb128> sladen: go troll somewhere else
[04:32] <seb128> jdub: hum
[04:33] <jdub> ogra: and, interestingly enough, one user on the system might use xscreensaver, another might use gnome-screensaver
[04:33] <ogra> sladen, right, since you cant configure the hacks anyway, we could hide the whole configuration ;)
[04:34] <ogra> jdub, hmm, right ... thats where the alternative fails ...
[04:34] <ogra> i'm pretty sure the xdg variant would at least work with the menu editor ...
[04:34] <jdub> ogra: .desktop attribute for "is blah running?" ;-) ;-)
[04:34] <seb128> having an alternatives for that is not a good idea anyway
[04:34] <ogra> globally it is ...
[04:35] <ogra> but jdub is right, individually it breaks
[04:35] <jdub> ogra: it really isn't what alternatives are meant to be used for though
[04:35] <ogra> alternatives are used if i have the same file in two packages and want one to be the default, no ?
[04:36] <ogra> (and want to avoid conflicts)
[04:36] <Treenaks> ogra: diversions too
[04:36] <janimo> ogra, why is x-s-s a problem for gnome, is it part of ubuntu-desktop?
[04:37] <Treenaks> janimo: you don't want both g-s-s and x-s-s running
[04:37] <xhaker> jdub: you're worse than ogra https://lists.ubuntu.com/archives/ubuntu-desktop/2005-December/000031.html
[04:38] <janimo> Treenaks: I know but since it's not in the default install why care?
[04:38] <janimo> or why is k-s-s not in the mix as well?
[04:38] <janimo> assuming kde has it's own ss
[04:39] <ogra> because users want to be able to switch back easily to xscreensaver ...
[04:39] <ogra> k-s-s isnt involved here
[04:39] <janimo> ogra, so g-s-s is not ready?
[04:39] <Treenaks> because KDE doesn't like freedesktop standards?
[04:39] <ogra> janimo, huh ? 
[04:39] <dholbach> janimo: "linux isn't ready"
[04:40] <janimo> ogra: why would people consider switching back to x-s-s?
[04:40] <ogra> janimo, because some want 1000% configurability of everything 
[04:40] <ogra> g-s-s doesnt (and brobably will never) offer this
[04:41] <janimo> those are l33t users they will know hwo to figure ot that g-s-s and x-s- do not mix well
[04:41] <ogra> janimo, they arent
[04:41] <Treenaks> janimo: it should Just Work
[04:41] <pitti> well, the most important config options would be enough already...
[04:41] <janimo> if they arent why do they want ocnfigurabilty 
[04:41] <janimo> beyind normal
[04:41] <ogra> l33t users edit /usr/share/gnome-screensaver/themes/*.desktop
[04:41] <sladen> ogra: could you use the same detection code as for the 'xscreensaver-command' wrapper and use that load the appropriate configuration dialogue.  (eg. Hide both of xscreensaver and gnome-screensaver and then have a pain  Configure Screensaver  wrapper)
[04:41] <jdub> ogra: (i think g-s-s may do per-hack config at some stage)
[04:42] <janimo> can't both be patched to watch for some lock in var/lock and do not start if others running or similar?
[04:42] <ogra> sladen, one is a menu entry and should be properly handled by gnome-menu or xdg, the other is a binary wrapper ...
[04:42] <xhaker> janimo: they might be running side y side
[04:42] <ogra> janimo, you dont understand the prob
[04:42] <janimo> ogra: apparenly not :)
[04:43] <ogra> its only about .desktop entries
[04:43] <janimo> aha
[04:43] <janimo> got it
[04:43] <ogra> has nothing to do with what starts or not
[04:44] <ogra> sladen, i'd prefer an alternative to a wrapper in your example ...
[04:45] <ogra> jdub, not before dapper+1 ... and i'm not allowed to add the preview button patch util upstream adds it as well ...
[04:45] <ogra> so these features will be missing for dapper
[04:47] <jdub> ogra: no, i mean, i think upstream will end up doing g-s-s per-hack config
[04:47] <ogra> jdub, they dont seem fond of it yet ...
[04:47] <jdub> no, but they will :)
[04:48] <ogra> (and its *very* tricky if you work across xscreensaver/gnome-screensaver, i have half a patch ready here)
[04:49] <seb128> jdub: you will use your clue bat for that? :)
[04:49] <ogra> seb128, so will you fix xdg or can i keep my alternative ? 
[04:49] <ogra> :)
[04:50] <seb128> ogra: you will get your alternative out
[04:50] <jdub> ha ha
[04:50] <ogra> seb128, and proper xdg handling in ? 
[04:50] <seb128> ogra: what do you call proper xdg handling?
[04:50] <seb128> we have proper xdg handling
[04:50] <CarlFK> I am trying to compose a bug report and stuck on a silly word problem: what do you call the text "About" in regards to an apps Help About menu choice?
[04:50] <seb128> and I've just checked, FC5 has no gnome-menus patch
[04:50] <ogra> seb128, being able to use the defined features from the xdg spec
[04:51] <CarlFK> Label, prompt, menu text...?
[04:51] <seb128> CarlFK: what is the bug about? seems duplicatish
[04:51] <jdub> CarlFK: string
[04:52] <CarlFK> seb128: "there should be consistancy between menu string and dialog titles."
[04:52] <CarlFK> don't like string...
[04:52] <seb128> CarlFK: for what app?
[04:52] <CarlFK> synaptic
[04:52] <ogra> seb128, from redhats gnome-screensaver.spec: install -D -m644 %{SOURCE1} $RPM_BUILD_ROOT%{_sysconfdir}/xdg/menus/preferences-post-merged/gnome-screensaver-hide-xscreensaver.menu
[04:52] <CarlFK> https://launchpad.net/malone/bugs/34361
[04:52] <Ubugtu> malone bug 34361 in synaptic "repo win titled "software preferences"" [Normal,Unconfirmed]  
[04:53] <ogra> seb128, and gnome-screensaver-hide-xscreensaver.menu contains the proper  <Exclude> directive
[04:54] <seb128> ogra: that doesn't seems a change for "proper xdg handling"
[04:54] <seb128> where is the patch or feature they have and we don't have?
[04:55] <ogra>  /etc/xdg/menus/preferences-merged/ is defined for us, but ignored if i put a .menu file into it
[04:57] <desrt> typo on the ubuntu website: http://www.ubuntu.com/community/participate/ "...you should contribute to the Art team who on icons, themes."
[05:00] <ogra> seb128, for our preferences.menu file:   <!-- Read in overrides and child menus from preferences-merged/ -->
[05:00] <ogra>   <DefaultMergeDirs/>
[05:00] <ogra> preferences-merged is ignored
[05:01] <Riddell> Treenaks: that's nonsense and quite insulting
[05:02] <Treenaks> Riddell: That's what I understood from reading comments on freedesktop.org mailing lists, sorry.
[05:02] <Treenaks> Riddell: so 'This is my opinion'
[05:02] <ogra> Treenaks, wrt screensavers, there is simply no f.d.o standard yet that rules screensaver handling, configuring etc ...
[05:03] <Treenaks> ogra: I thought this was re: autostart
[05:03] <ogra> so you could say gnome doesnt respect f.d.o as well ... if it come to screensavers
[05:03] <ogra> its only about the menu entries
[05:07] <Riddell> Treenaks: you are talking rubbish, kde had autostart long before gnome, we created the spec (not a standard), but have not implemented the final spec since we have not had a release 
[05:11] <seb128> ogra: seems that moving the  <DefaultMergeDirs/> just before the "  <!-- Menu items to exclude from the toplevel -->
[05:11] <seb128>   <Exclude>
[05:11] <seb128>     <Filename>gnomecc.desktop</Filename>"
[05:11] <seb128> ogra: does the job
[05:12] <seb128> ogra: from /etc/xdg/menus/preferences.menu
[05:15] <ogra> seb128, ah, cool, will test that ...#
[05:15] <ogra> :)
[05:25] <sivang> sladen: http://muse.19inch.net/~sivan/upbackup/
[05:26] <sivang> sladen: let me know if this is okay, you can also fetch it from your account I suppose :)
[05:29] <mdz> seb128: do you know what is causing that problem where logging out stalls?
[05:29] <seb128> mdz: no, but I had it 2 times yesterday, it's on my list to stuff to investigate ...
[05:30] <mdz> seb128: I've seen it on my laptop as well; seemed to happen after an upgrade and then not the next time
[05:30] <seb128> I'm inclined to blame gnome-panel or libbonobo
[05:33] <mdz> seb128: I saw it on Jane's machine yesterday as well
[05:33] <mdz> seb128: and then just now a different weird problem
[05:33] <mdz> she logged out, logged back in, and got the "panel already running" dialog, then no panel
[05:33] <seb128> mdz: "weird", beeing "panel already running" we discuss on the other chan?
[05:33] <mdz> seb128: yes
[05:34] <mdz> which channel?
[05:34] <seb128> #canonical
[05:34] <seb128> oh, you are not here
[05:34] <mdz> right, my xchat doesn't autojoin me
 jbailey: sometime gnome-panel doesn't exit with the session
 so when you log again you get 2 of those
 and they are not friends
[05:35] <mdz> right, exactly
[05:35] <mdz> her old gnome-panel process (and a bunch of other stuff, bonobo, esd, etc.) was still running from the previous login
[05:36] <seb128> I had a quick discussion with vuntz about it yesterday
[05:37] <seb128> I'll probably work on it tomorrow or monday
[05:39] <Keybuk> Dear X-Chat.  Please stop SEGVing.  kthxbye
[05:39] <bddebian> heh
[05:40] <sivang> hehe
[05:41] <mdz> seb128: thanks
[05:41] <seb128> np
[05:43] <mkde> dapper is to be referred to as 6.06 right?
[05:43] <ogra> 6-06
[05:43] <mkde> oh?
[05:43] <mkde> that's a change from previous conventions, isn't it?
[05:43] <ogra> yep
[05:44] <mkde> right, thanks
[05:44] <ogra> dont ask me, i didnt make the change :)
[05:44] <ogra> but Keybuk has arguments for it iirc :)
[05:44] <jdub> ew
[05:44] <mkde> np, I'll tell the documentation team
[05:44] <ogra> and sabdfl wanted it as well ...
[05:45] <mkde> is it decided?
[05:46] <ogra> Keybuk, ?? ^^ was there consensus abou tthe new versioning scheme 
[05:46] <Keybuk> we haven't discussed that
[05:46] <Keybuk> ask mdz or sabdfl :)
[05:47] <ogra> it was mentioned several times during all three meetings iirc
[05:47] <mkde> how about you guys decide, and let the docteam know?
[05:47] <sladen> Keybuk: I thought the most famous program you're known for writing is an IRC boucer---can't you stick that between XChat the teh intraweb?
[05:47] <ogra> mdke, pfft that would be to easy :P
[05:47] <mkde> is the naming convention to be changed on the website restrospectively? like 5-04, 5-10?
[05:48] <Keybuk> sladen: I wouldn't say it's the most famous
[05:49] <sladen> Keybuk: most-widely-installed-by-script-kiddies
[05:51] <Keybuk> I don't like IRC bouncers though <g>
[05:52] <natroll-> what's IRC bouncer?
[05:52] <seb128> mdz: seems that your ogg stations don't work
[05:52] <kagou> hi
[05:52] <seb128> mdz: http://ubuntu.hbr1.com:19800/house.ogg by example
[05:52] <natroll-> i assume something nasty
[05:54] <mdz> seb128: was working for me when I sent it; I tested first
[05:54] <Kamion> mkde: I doubt that
[05:54] <seb128> mdz: it stopped working so :)
[05:54] <seb128> mdz: http://radio.hbr1.com:19800/house.ogg works fine, http://ubuntu.hbr1.com:19800/house.ogg doesn't
[05:54] <mdz> seb128: I will mail them
[05:55] <seb128> mdz: ok, should I use radio.hbr1.com for now?
[05:55] <seb128> or delay that change time they fix it?
[05:55] <seb128> or push it now assuming they will fix it quickly? :)
[05:55] <Kamion> doko: why the extra grub upload? I had already demoted ia32-libs-dev to an alternative build-dep that wouldn't be used
[05:57] <doko> Kamion: looking ...
[05:59] <doko> hmm, you are right, not necessary
[05:59] <mdz> seb128: whatever is easiest for you
[05:59] <mdz> seb128: just don't forget to change it before release if you use radio ;-)
[05:59] <seb128> mdz: I've already done the patch, so I'll list them, if they don't fix them I'll drop before dapper
[06:00] <seb128> s/drop/drop it
[06:01] <mdz> seb128: the URLs they gave me were .m3u and .pls
[06:01] <mdz> seb128: but we need the actual stream URLs, right?
[06:02] <seb128> correct
[06:02] <seb128> http://ubuntu.hbr1.com/
[06:02] <seb128> those .mm3u have radio.hbr1.com
[06:02] <seb128> .m3u
[06:05] <mdz> seb128: right
[06:05] <mdz> I've just mailed them
[06:05] <seb128> k
[06:08] <fabbione> Kamion: ping?
[06:09] <mdz> fabbione: there is a strange comment at the top of /etc/init.d/rc.local
[06:09] <fabbione> mdz: uh such as?
[06:09] <Kamion> fabbione: hi
[06:10] <fabbione> mdz: i did copy it almost pristine from another script
[06:10] <fabbione> Kamion: i was just reading the -meeting report.. i am sorry we misunderstood eachother.. 
[06:10] <fabbione> Kamion: should we look at it again?
[06:10] <Kamion> fabbione: no worries - to clarify, you expect me to upload that, right?
[06:10] <Kamion> which is fine by me
[06:10] <fabbione> Kamion: my understanding was that i did give you the core functionality and it is working
[06:11] <fabbione> Kamion: and that you were going to cleanup the strings before upload
[06:11] <Kamion> http://people.ubuntu.com/~fabbione/pa.diff is the current diff, right?
[06:11] <fabbione> Kamion: there is only line from that patch you need to change
[06:11] <fabbione> Kamion: yes
[06:11] <Kamion> what do I need to change? just the changelog?
[06:11] <fabbione> Kamion: the changelog and one debugging line
[06:12] <fabbione> just one sec.. i am searching the line
[06:13] <Kamion> I had a look, couldn't see it
[06:13] <fabbione> it's the one that forces to show always the disk selector
[06:13] <fabbione> we want to see the disk selector only if there is more than a disk
[06:15] <mdz> fabbione: yes, but the information in the comment doesn't apply to the script
[06:15] <fabbione> mdz: ok, that's easy to remove
[06:15] <fabbione> Kamion: gimme 2 minutes and i will fix it for you. i can't find it either.. i might have lost it somewhere by mistake
[06:16] <Kamion> +# if preseeded we don't ask_for_disk.
[06:16] <Kamion> +if [ -z "$dev" ] ; then
[06:16] <Kamion> +    STATE=1
[06:16] <Kamion> +else
[06:16] <Kamion> +    STATE=2
[06:16] <Kamion> +fi
[06:16] <Kamion> that logic seems the wrong way round, so maybe if I change that -z to -n then it'll be fine?
[06:21] <fabbione> Kamion: no the logic is fine...
[06:21] <fabbione> new patch is up
[06:22] <fabbione> you set the STATE=1 if device is empty and so you ask for it
[06:22] <fabbione> the new patch will ask for the device only if there is more than one
[06:22] <Kamion> oh, yeah, misread
[06:22] <fabbione> but..
[06:22] <fabbione> hold on.. i am tired..
[06:22] <fabbione> sorry
[06:23] <Pygi> _ion: ping
[06:27] <fabbione> Kamion: ok.. this patch should be good
[06:27] <fabbione> +# if there is only one device and we are not preseeded
[06:27] <fabbione> +# we autoselect the device, skip the question
[06:27] <fabbione> +# and jump to the next.
[06:27] <fabbione> +if [ $count -le 1 ]  && [ -z "$dev" ] ; then
[06:27] <fabbione> +  STATE=2
[06:27] <fabbione> +  dev="$devs"
[06:27] <fabbione> +fi
[06:27] <fabbione> that's the diff basically from the one you had
[06:29] <Kamion> looks reasonable
[06:29] <Kamion> I'm finishing up for the night soon, but I'll look at it tomorrow morning
[06:29] <Kamion> thanks again
[06:29] <fabbione> Kamion: sorry again for the misunderstanding..
[06:29] <fabbione> i didn't mean to block you at all :/
[06:30] <fabbione> mdz: i am fixing the comment in a few minutes.. i need to rsync the local mirror first
[06:35] <Kyral> Is there a meeting going on?
[06:35] <xhaker> Kyral: no?
[06:35] <Kyral> hmm
[06:49] <ogra> seb128, right, that fixes it, do you want to add the dir and change of preferences.menu to gnome-menus or are you ok with me doing it (i'd like to get rid of the bug)
[06:53] <seb128> ogra: I would like to understand why we need to do that and not fedora
[06:54] <ogra> hmm
 hmm
 ogra: I would like to not change the conffile if not required too
[06:57] <seb128_> --- Disconnected ().
[06:58] <ogra> was below the hmm :)
[07:00] <ogra> fedora has no direct call of an Exclude directive in the preferences.menu file itself ...
[07:00] <ogra> we supress gnomecc in there ...
[07:09] <seb128_> ogra: should not make a difference
[07:09] <ogra> it doesnt, just tested
[07:10] <seb128_> and the gnome-cc is upstream stuff
[07:10] <seb128_> no distro patch
[07:11] <ogra> the only distro patch touching the file is 01_preferences-legacydir.diff
[07:13] <ogra> removing that makes no difference either ...
[07:17] <joelbryan> the irony of today's gnome image viewers... in gthumb's about dialog says "An image viewer and browser for GNOME.", but has cataloging capabilities, in eog's about dialog says "The GNOME image viewing and cataloguing program.", but can't do any cataloging stuff. sometimes I think eog should be removed..
[07:23] <joelbryan> what's the big difference between eog and gthumb?
[07:24] <joelbryan> gthumb can do what eog does
[07:25] <Burgwork> eog is a basic viewer, nothing more
[07:25] <Burgwork> and removing it would be bad, trust me
[07:26] <joelbryan> ok
[07:27] <Burgwork> my FC4 box at work doesn't have eog and it sucks
[07:28] <joelbryan> speed is a plus factor for eog.
[07:28] <joelbryan> and the next and back button, before I hate eog, but with the new button, I'm kinda liking it.
[07:30] <joelbryan> gthumb is comparible to microsoft office picture viewer, while eog is like windows picture viewer for fax and image
[07:32] <kent> Finns det ngon skiva med fri programvara fr windows? 
[07:32] <kent> helst p svenska..
[07:32] <joelbryan> i'm just posting my past thoughts.. :-) it's what I posted before in fedora mailing lists. just think the irony of their about descriptions.
[07:32] <Treenaks> kent: Please use 
[07:33] <Treenaks> kent: English
[07:33] <kent> sorry, wrong channel. :(
[07:35] <joelbryan> I'm made a simple interface handling irc:// links for gaim, do you think it'll get approved, it's very simple app, just dialog with text inputs and a button, and currently I'm trying to put a checkbox for the app not to run gaim automatically.
[07:36] <Treenaks> no, we're past feature freeze
[07:36] <joelbryan> someone just told me that gaim doesn't handle irc:// links, so I made this app.
[07:37] <Pygi> joel: perhaps for dapper+1 ;)
[07:37] <joelbryan> cool!
[07:37] <joelbryan> I'm trying to help rhythmbox to write to ipod.
[07:38] <Pygi> joel: xchat-gnome handles irc...isn't that enought, at least for now? ^^
[07:38] <Burgwork> Pygi, not part of the default desktop anymore
[07:39] <Pygi> Burgwork: o, really? since when? :-/
[07:39] <cassidy> and it's a shame ! :p
[07:39] <Pygi> cassidy: agreed
[07:39] <joelbryan> Pygi: isn't it xchat-gnome will not be included in dapper, oh well, just wishful.
[07:40] <Pygi> and what is gonna replace xchat-gnome? don't tell me Gaim IRC capabilities ???
[07:40] <joelbryan> dapper rocks!, it's now my no.1 favorite opensource software, no.2 is drupal.
[07:40] <joelbryan> drupal 4.7 also rocks!
[07:40] <cassidy> Pygi: it seems. It sucks, i know :\
[07:41] <Pygi> cassidy: O joy, whatever :-/
[07:41] <Pygi> cassidy: with what update does it come? so I don't do the upgrade ^^
[07:41] <cassidy> Pygi: if you have x-g installed, it will not be removed
[07:42] <cassidy> ubuntu-desktop just doesn't depend on it anymore
[07:42] <cassidy> so it's not installed by default
[07:42] <Pygi> cassidy: joy ... :-/
[07:44] <joelbryan> when I first tried gaim's irc for the first time, I liked it alot than xchat-gnome, that's why I think xchat-gnome is a duplicate.
[07:46] <Burgwork> gaim doing irc has nothing to do with removing x-g from the desktop
[07:46] <joelbryan> is a "Show All" button in logout dialog a feature? coz I also made some modifications with the logout dialog to display less icons.
[07:47] <joelbryan> then why not install epiphany since it also handles http://
[07:48] <Burgwork> umm, it is duplicative of firefox?
[07:48] <joelbryan> yeah, same with x-c and gaim
[07:50] <Pygi> joelbryan: for that cause, why not Flock ? ^^
[07:51] <joelbryan> what's flock?
[07:51] <joelbryan> me too
[07:51] <Pygi> joelbryan: google ;)
[07:51] <joelbryan> sorry.
[07:51] <joelbryan> anyone using meld, it's awesome.
[07:53] <joelbryan> awesome, does flock uses gtkhtml extensively instead of mozengine?
[07:54] <Burgwork> joelbryan, Pygi this is wandering into offtopic, please keep it focused here
[07:54] <Pygi> Burgwork: yup, sorry
[07:55] <joelbryan> me too, sorry
[07:55] <LaserJock> Seveas: ping?
[08:00] <mdz> seb128: already a 2.14.1 of gedit?
[08:07] <dholbach> mdz: we had some other "quick fixes" already :)
[08:07] <dholbach> mdz: for the rough edges :)
[08:07] <joelbryan> I tried editing metacity schema using gedit and my pc just hangs, should there be a way for the desktop to be honest, they are running out of memory?
[08:10] <joelbryan> I think there should be a way to say "honestly I would like to tell you that you are running out of memory and I won't continue loading this application, so I'll just save the changes you have made.and exit the program", this somehow fixes alot of things. (e.g. inkscape memory hog)
[08:10] <joelbryan> _somehow_
[08:18] <mario_> _ion: ping
[08:18] <Lutany> pong
[08:19] <Pygi> Lutany: ?
[08:21] <Lutany> :-)
[08:25] <sharms> shouldn't deskbar automatically install beagle (without it it seems rather useless?)
[08:27] <Burgwork> sharms, far from it
[08:27] <sharms> on default dapper install deskbar is available, but does nothing in default installed condition
[08:28] <sharms> it will, despite it telling you it does, not index your home directory etc
[08:28] <sharms> that seems like a bug to me
[08:28] <Pygi> sharms: mono is NOT YET in main
[08:29] <Pygi> and beagle is not stable enough
[08:29] <Burgwork> Pygi, umm, yes it is
[08:29] <sharms> so maybe deskbar shouldn't be in the default install until it is primetime?
[08:29] <Pygi> Burgwork: buh, I am lost lately :-/ too much "not sleeping"
[08:29] <sharms> because if the dapper pause is 6 weeks to polish, this is definately a polish issue
[08:29] <sharms> a component not working and doing what it says it does is a polish issue
[08:29] <Pygi> sharms: well, at least, beagle is not stable and tested enough
[08:30] <Burgwork> sharms, there are two issues here
[08:30] <sharms> so maybe deskbar should not be included with dapper
[08:30] <Burgwork> one: everything is turned off by default in dapper
[08:30] <Burgwork> two: beagle not installed by default
[08:30] <Burgwork> the first can be fixed without the second
[08:30] <Burgwork> please file a bug on the first
[08:30] <sharms> thats what I was going to do
[08:30] <sharms> I just figured I would run it by you guys
[08:30] <sharms> and making sure I am not blind
[08:30] <MrFaber> Anyone experiences problems with cpu scaling in dapper?
[09:15] <sladen> MrFaber: if _you_ have problems with power-scaling, could you file a bug please :)
[09:24] <Seveas> LaserJock, ?
[09:25] <LaserJock> Seveas: do happen to know anything about the @ubuntu.com email addresses?
[09:25] <jpatrick> you missed a word there
[09:25] <Seveas> LaserJock, if you're a member you get one that forwards to your prefered address in LP
[09:26] <LaserJock> Seveas: I changed my preffered email address but it still is forwarding to the other address
[09:26] <LaserJock> Seveas: I even took the old address off LP and it is still forwarding
[09:27] <Seveas> for that to change you may need to poke $someone
[09:28] <LaserJock> Seveas: and do you know who $someone might be? :-)
[09:28] <Seveas> iirc elmo
[09:28] <LaserJock> hmmmm
[09:30] <Pygi> _ion: are you alive actually? ;)
[09:31] <trappist> where should I complain about mailman, or something else on lists.ubuntu.com, breaking gpg signatures on some emails?
[09:38] <bddebian> Is there a wiki on creating a mirror?
[09:58] <Burgwork> jdub, why has there been no official statement about the dapper delay yet?
[09:59] <Seveas> Burgwork, both CC and TB have to approve all official statements
[09:59] <Seveas> (about this)
[09:59] <Burgwork> Seveas, the decision has been made though, no?
[10:00] <Seveas> if so, it will be announced
[10:00] <bddebian> Should debmirror work for us?
[10:02] <HiddenPuppy> Seveas: Burgwork, there is a draft delay announcement on the wiki
[10:02] <HiddenPuppy> by sabdfl
[10:02] <mdke> it's running late, Burgwork is right
[10:06] <Fujitsu> Well, it's been decided...
[10:21] <kalphegor> how can i help ubuntu with a wallpaper? maybe default wallpaper for Dapper :) is there any visual/art team?
[10:21] <Burgwork> kalphegor, #ubuntu-art I believe (it might be -artwork)
[10:21] <TMM> hi all!
[10:21] <kalphegor> thanks
[10:22] <tseng> hi Burgwork 
[10:22] <minghua> Burgwork, kalphegor: it seems to be -artwork
[10:22] <Burgwork> salut tseng 
[10:22] <TMM> can someone help me out with cdbs and simple-patchsys? I am trying to apply a patch, that just works cleanly when I operate the normal 'patch' command, and, I have looked at  simple-patchsys.mk and I have extracted the line that does the actual patching, and THAT works as well, but it fails from 'fakeroot dpkg-buildpackage'
[10:22] <TMM> any ideas? :)
[10:23] <Treenaks> TMM: use cdbs-edit-patch :)
[10:23] <tseng> you'll have to be more specific about how it fails
[10:23] <tseng> Treenaks: thats not useful, a plain diff -ruN would be fine if he started at the top of the souce tree
[10:25] <TMM> tseng: it fails at all patchlevels with the oh so common 'can't find file to patch at input line 6' which would only make sense either the  $(DEB_SRC) was wrong
[10:25] <tseng> TMM: yeah
[10:25] <tseng> did you diff from the top level
[10:25] <tseng> or did something weird
[10:25] <TMM> tseng: they are suse patches, from a source-rpm
[10:25] <tseng> diff -ruN fooapp-0.2.old fooapp-0.2.new
[10:26] <TMM> tseng: that's apparently what they did, because the diff header looks like they did :)
[10:26] <TMM> tseng: wait, they should be done with the -R flag?
[10:26] <TMM> --- linux-iscsi-4.0.1.orig/Makefile     2004-02-09 11:42:27.000000000 +0100
[10:26] <TMM> +++ linux-iscsi-4.0.1/Makefile  2004-05-25 10:45:26.000000000 +0200
[10:26] <TMM> that's what the header looks like.... probably not -R then
[10:27] <tseng> if i eat my words you could do cdbs-edit-patch 01_patchname.diff
[10:27] <tseng> which gives you a fake shell
[10:27] <tseng> apply the patch with 'patch'
[10:27] <tseng> and exit the shell
[10:28] <TMM> owww... do I have to? there are 15 of 'em :)
[10:28] <tseng> i see.
[10:28] <TMM> what if I just run a script of the patches to change all the +'s to -'s and vice-verse? :)
[10:28] <TMM> wait... that's not going to work
[10:28] <tseng> linux-iscsi-4.0.1
[10:29] <tseng> this is the name of your folder?
[10:29] <TMM> yes
[10:29] <TMM> but, that should work fine with -p1 right?
[10:29] <Burgwork> Kamion, do we need a sign "No feeding the fish?" :)
[10:32] <_ion> pygi: Pong.
[10:32] <_ion> Just woke up. :-)
[10:32] <Pygi> _ion: K, will talk later then?
[10:32] <TMM> what would me the chances of getting iscsi support into the -server kernel before dapper releases? slim? extremely small? near-zero? :) it pretty much doesn't touch any files, it just adds a couple
[10:32] <Pygi> TMM: #ubuntu-server
[10:32] <Pygi> and I would guess "zero" :)
[10:33] <_ion> pygi: Now's okay.
[10:33] <TMM> Pygi: you are probably right, I only just noticed today it isn't in there, and, I feel it is a pretty darn nasty omission :)
[10:34] <Pygi> _ion: we should patch drivers as well, you know that?
[10:34] <_ion> pygi: For WPA support?
[10:34] <Pygi> _ion: yup, and 802.1x 
[10:34] <Fujitsu> 802.1x will be supported?
[10:35] <_ion> pygi: Oh.
[10:35] <Pygi> Fujitsu: nothing will be or was ever supported ;)
[10:35] <Fujitsu> Why not?
[10:35] <Pygi> Fujitsu: 'Cause if I tell you anything now, I would have to shoot you ;)
[10:35] <Fujitsu> Is it in the works?
[10:36] <Pygi> _ion: and kernel freeze is in a week (I guess so), so we should do that ASAP
[10:36] <Kamion> Burgwork: we're discussing the announcement now, shouldn't take too long
[10:36] <Pygi> if we want it done
[10:36] <Pygi> Fujitsu: read up :)
[10:37] <TMM> tseng: do you have any ideas?
[10:37] <TMM> tseng: or is re-applying all the patches manually the only way (r)?
[10:37] <tseng> none that i havent thrown out there
[10:37] <_ion> pygi: Anyway, (this isn't confirmed yet!) the essential patches from the 0.5.1 package should be ported to 0.6.1 now.
[10:37] <mdke> Kamion, is the timetable fixed?
[10:37] <Burgwork> _ion, you are a god
[10:37] <_ion> pygi: I take it someone has already made the patches for the drivers?
[10:37] <Kamion> mdke: yes
[10:37] <Fujitsu> That's a yes, I take it... I really need EAP-TLS for NetworkManager to be useful :(
[10:38] <Pygi> _ion: yes, we should just apply it.... they are on n-m list...
[10:38] <Kamion> see DapperReleaseSchedule
[10:38] <_ion> pygi: Ok.
[10:38] <mdke> Kamion, i'm not very happy with the doc freeze, any scope for negotiation?
[10:38] <Fujitsu> UserInterfaceFreeze is ages away, I notice, which is good.
[10:38] <Pygi> _ion: so that should be our priority for now...what do you say
[10:38] <Kamion> mdke: talk to the TB about that sooner rather than later
[10:38] <Pygi> ?
[10:38] <mdke> Kamion, I sent a mail early this morning
[10:38] <Kamion> mdke: don't need to wait for a meeting, just grab them
[10:39] <_ion> pygi: Yep, i agree.
[10:39] <Kamion> I imagine that there is some scope there
[10:39] <mdke> Kamion, have you got any to hand?
[10:39] <mdke> mjg59, ?
[10:39] <Kamion> mdke: no, sorry
[10:39] <mdke> Kamion, :)
[10:39] <Pygi> _ion: we should check when exactly kernel freeze is...
[10:39] <Kamion> in fact I'm about to go for the evening
[10:39] <Pygi> Kamion: perhaps you know when is dapper kernel freeze?
[10:39] <Kamion> Pygi: DapperReleaseSchedule, I mentioned it just a few lines up
[10:39] <Fujitsu> May 18.
[10:39] <Pygi> Kamion: ah, thx
[10:40] <mdke> Kamion, have a nice evening, what is left of it :)
[10:41] <Kamion> my wife likes to see me occasionally
[10:41] <mdke> be off with you
[10:41] <Pygi> _ion: please take a look at https://wiki.ubuntu.com/DapperReleaseSchedule, I am unable to find kernel freeze ??
[10:42] <Kamion> Pygi: try the "find" function in your browser
[10:42] <_ion> pygi: As fujitsu said, May 18th.
[10:42] <Pygi> Kamion: heh
[10:42] <Pygi> _ion: huh, kk
[10:44] <Pygi> _ion: so, are we going to apply patches against all drivers that can be found on n-m list?
[10:44] <Pygi> _ion: and it would be really great, if we could pull of the 802.1x as well
[10:46] <_ion> I'd like to see how big/complex those patches are. I tried to search for "patch" in http://mail.gnome.org/archives/networkmanager-list/ but didn't get any results. Do you have an URL?
[10:46] <_ion> Yeah, it'd be great.
[10:46] <Pygi> Fujitsu: hehe ;)
[10:47] <TMM> tseng: reapplying it is then...
[10:47] <_ion> Seems like the search function is b0rken at that page.
[10:48] <Fujitsu> b0rked?
[10:48] <Pygi> _ion: heh :-/
[10:49] <_ion> http://mail.gnome.org/archives/networkmanager-list/2006-March/msg00134.html "madwifi-ng driver fix"
[10:49] <_ion> A quite simple patch.
[10:49] <Fujitsu> How is ipw2200?
[10:49] <Fujitsu> That's outrageously short!
[10:51] <Pygi> _ion: yup, I know...but there are more patche
[10:51] <Pygi> patches* that we need to apply
[10:53] <Pygi> _ion: from Seveas: you need the patch from Robert Love (various collected workaround) and a patch from dan williams to make madwifi-ng report wpa capabilitues
[10:53] <Seveas> (and you need to convince a lot of people that Ubuntu should switch to madwifi-ng)
[10:53] <Seveas> (or port the latter patch to madwifi-old)
[10:54] <Seveas> the madwifi patch: madwifi.org/ticket/444
[10:54] <Seveas> the other was sent to the list on march 3rd 15:35 UTC
[10:55] <Seveas> (not to discourage you, but I am following that list quite closely and would be surprised if you can get it to work reasonably well)
[10:59] <Pygi> _ion: found second patch perhaps?
[11:00] <Pygi> _ion: or is it the one we found earlier on the list?
[11:03] <Lathiat> JanC: ping
[11:03] <Lathiat> janc: unping
[11:03] <Kyral> lol
[11:03] <JanC> 
[11:03] <Lathiat> (meant to type janimo, offline so tab complete failed me :)
[11:09] <_ion> pygi: Hm, there's some patch in here. http://madwifi.org/attachment/ticket/275/active-scan.patch
[11:10] <_ion> Linked from http://mail.gnome.org/archives/networkmanager-list/2006-February/msg00112.html
[11:10] <Pygi> _ion: that should probably be applied as well to enable 802.1x support
[11:10] <_ion> Here's the patch from Robert Love. http://mail.gnome.org/archives/networkmanager-list/2006-February/msg00081.html
[11:12] <Pygi> _ion: most patches seem rather simple, so it shouldn't be a problem
[11:12] <_ion> Yep.
[11:12] <Pygi> disable-named-and-vpn-managers should be ported rather soon
[11:13] <_ion> Oh, i ported it.
[11:13] <_ion> I sent an email.
[11:14] <doko> mjg59: elilo ping
[11:14] <Pygi> _ion: o joy, you took my job :-P
[11:14] <_ion> :-)
[11:14] <Pygi> _ion: so we have applied all ubuntu patches now?
[11:15] <_ion> It would be nice to receive confirmation that the ported/recreated patches in the package are indeed okay.
[11:15] <_ion> Hm, let me see.
[11:15] <_ion> (Or, if they aren't, then we can fix them.)
[11:16] <Pygi> _ion: yes, but we can't know that until we patch drivers, and test it  out
[11:21] <_ion> Here's the patch situation: 10-dbus-api-fix: already in upstream. 20-linux-wlan-ng: "< pitti> _ion: 20-linux-wlan-ng.patch is my hack, if the others are cleared with Keybuk, then I will port that one". 30-blacklist-devices: not ported. 40-ubuntu-backend: ported, but waiting for confirmation from Keybuk. 50-disable-named-and-vpn-managers: ditto. 60-dispatch-more-events: not ported; looks like easy to port. 65-dispatcher-script-dir: ported. ...
[11:22] <_ion> ... 70-dont-deactivate-new-devices: ported.
[11:22] <Pygi> hm, k, so a few more to port
[11:22] <mdke> mjg59, when you come back, could you take a look at my mail about the doc freeze for 6.06, and maybe response / poke another TB person on it? Thanks
[11:23] <Pygi> _ion: all those are essential I suppose?
[11:26] <_ion> pygi: AFAIK 40-ubuntu-backend and 50-disable-named-and-vpn-managers were the *really* *essential* patches, but the others are there for a reason, so they probably should be ported as well.
[11:26] <Pygi> _ion: k, agreed
[11:27] <Pygi> _ion: can we get it all done by monday/tuesday perhaps, so we could put it for massive testing/reviewing?
[11:27] <_ion> Probably.
[11:28] <Pygi> k, great
[11:28] <_ion> I'll probably port 60-dispatch-more-events today, it seems very easy.
[11:29] <Pygi> _ion: my today is almost over ;)
[11:29] <_ion> Well, it's 00:29 here, but i woke up a while ago. :-)
[11:29] <Pygi> _ion: oh, 1 hour difference ;)
[11:29] <_ion> I might look at the blacklist stuff as well, if i'm not too tired.
[11:30] <_ion> I have been sick for quite a while, so i don't have very much energy, but i'll see what i can do.
[11:30] <Pygi> lemme see the blacklist patch
[11:30] <_ion> Ok.
[11:30] <Pygi> just rest, I can do some things as well
[11:31] <holycow> hey all
[11:31] <holycow> is sabayon being actively considered in ubuntu on any level? 
[11:32] <_ion> 30-blacklist-devices.patch is simple, but it probably depends on some stuff from 40-ubuntu-backend.patch. I.e. in order to get that blacklist stuff working one needs to port it from both of those patches.
[11:32] <kent> holycow: its installed on my Dapper-computer. So I assume the answere is yes.  But read the topic about support
[11:32] <Seveas> sivang, ping
[11:33] <Burgwork> holycow, as part of gnome, it is available
[11:33] <Burgwork> holycow, it is not designed to be installed on every desktop
[11:33] <holycow> kent, indeed and noted, was curious where that project is going as its hard to get a peep out of anyone on that end of things
[11:34] <Pygi> _ion: kk
[11:35] <holycow> Burgwork, *nod*, we are piloting ubuntu here and wondering if ubuntu is considering it as 'nice to have' or 'integral part' of the desktop experience
[11:35] <Burgwork> holycow, sabayon is not the kind of project which attracts a lot of people
[11:35] <Burgwork> holycow, I would put it in the middle
[11:35] <holycow> okay
[11:36] <holycow> cool, good to get an opinion on this :)
[11:36] <Burgwork> holycow, I believe there is nobody working full time on sabayon
[11:36] <holycow> thats what it seems like *nod*
[11:37] <Seveas> Burgwork, would you mind coming to #ubuntu-meeting for a second?
[11:38] <holycow> thanks for the info Burgwork 
[11:38] <Burgwork> holycow, np
[11:43] <Pygi> _ion: time to sleep...if you need anything , please mail me,ok?
[11:44] <_ion> pygi: Yeah, will do. G'night. :-)
[11:44] <Pygi> night to you as well _ion