[12:11] <jono> hey
[12:11] <mdke> evenin
[12:18] <pygi> night
[01:16] <Kamion> jcole: you'll need silo installed for that to work; otherwise, download silo_1.4.10-0ubuntu4_sparc.deb from the archive, 'mkdir boot1; ar p silo_1.4.10-0ubuntu4_sparc.deb data.tar.gz | tar zxf - -C boot1 ./boot/{isofs,second}.b', and change '-G /boot/isofs.b -B ...' to '-G boot1/boot/isofs.b -B ... boot1'
[01:17] <Kamion> (the latter was derived from how debian-cd does it)
[01:29] <jcole> Kamion: i'll try that
[01:29] <jcole> Kamion: thatnks
[01:42] <mdke> mmmm good news http://blogs.gnome.org/view/carlosg/2006/06/06/0
[01:47] <nexu> when will ubuntu be ready to ship dbus 0.61?
[01:47] <nexu> python-dbus 0.60 has a very annoything bug
[01:50] <mdke> nexu: did you find it in our bugtracker?
[01:50] <nexu> mdke: negative
[01:52] <mdke> nexu: it's going to be difficult for it to get fixed if it isn't in there
[01:52] <mdke> nay, impossible
[01:52] <ajmitch> morning
[01:54] <nexu> mdke: i heard dbus guys saying that ubuntu hasnt bumped the dbus to 0.61 due to some binary incompactibility with something i cant really remember what it was but that was from 2 months ago 
[01:54] <nexu> heard from *
[01:54] <Keybuk> when was 0.61 released?
[01:55] <nexu> "there was a minor binary imcompatible change that required a rebuild of gnome-power-manager 2 months ago"
[01:55] <Keybuk> it's likely that it was too close to our UpstreamVersionFreeze to be considered for dapper
[01:56] <nexu> is there *any*  repo atm which has 0.61 dbus ?
[01:56] <Keybuk> Ubuntu, no?
[01:56] <Keybuk> we haven't opened our new development release yet
[01:57] <mdke> nexu: if the bugfix is backportable, and you file a bug, you never know, it might be considered for Ubuntu 6.06
[01:57] <nexu> mdke : i pretty much suck at bug reporting heh
[02:00] <mdke> nexu: but the Ubuntu developers pretty much suck at fixing bugs they don't know about, so it's worth a try
[02:01] <mdke> maybe they know about it already, maybe not
[02:01] <nexu> mdke: haha ok, fair enough
[02:01] <nexu> i'll give it a try
[02:01] <nexu> gonna try to diff the python2.4-dbus source atm first
[02:01] <nexu> see whats the difference
[02:01] <nexu> that of ubuntu and dbus cvs
[02:02] <mdke> good luck
[02:02] <nexu> ty
[02:03] <jcole> bug 46665
[02:03] <Ubugtu> Malone bug 46665 in debian-installer "[ia64]  Failure to mount root filesystem after install" [Normal,Unconfirmed]  http://launchpad.net/bugs/46665
[02:03] <Keybuk> *sigh*
[02:03] <Keybuk> mom needs more hamsters
[02:03] <Keybuk> jcole: ?
[02:04] <jcole> Keybuk: sorry about that, we're talking about that bug in another room
[02:04] <Keybuk> ah
[02:04] <Keybuk> it's one of those general "d-i does things differently to udev" bugs :-/
[02:05] <Keybuk> it would be nice if we could fix all of them
[02:08] <svu> why not change ppc ubuntu builds to ppc64?
[02:08] <Keybuk> they are ppc64s I think
[02:09] <infinity> The builds, not the buildds.
[02:09] <infinity> svu: There's no value in building binaries for ppc64 by default.
[02:09] <svu> Keybuk, only the kernel. all the rest is ppc32, according to file /usr/bin/*
[02:09] <infinity> svu: They just end up bigger and slower.
[02:09] <Keybuk> svu: that's normal
[02:09] <Keybuk> you don't want a 64-bit userland on ppc (or sparc)
[02:09] <svu> infinity, why slower? wouldn't it take advantage of faster operations on long operands?
[02:10] <mjr> cache-hogs
[02:10] <Keybuk> infinity: heh, clearly it is getting late
[02:10] <svu> Keybuk, why? why do people create 64-bit CPUs anyway?:)
[02:11] <infinity> svu: we provide a 64-bit libc, and for specific applications that will benefit from being compiled for ppc64, that can be done.
[02:11] <Keybuk> I think the AMD64 is pretty unique that it actually runs better in 64-bit mode than 32-bit, no?
[02:11] <mjr> Keybuk, pretty much
[02:11] <infinity> svu: In the general case, you lose performance.
[02:11] <Keybuk> that's more the suckage of ia32 though
[02:12] <infinity> Keybuk: Yeah, amd64's architecture changes made porting a huge win.
[02:12] <mjr> Keybuk, pretty much :)
[02:12] <infinity> Keybuk: But that's a rarity.
[02:12] <svu> infinity, funny. Is there a special page in wiki regarding libc64 and all the apps taking advantage of 64-bit mode?
[02:12] <infinity> svu: The same is true for sparc/sparc64, hppa/hppa64... You always want a 64-bit kernel, but you almost never want a 64-bit userland unless you know you do.
[02:12] <Chipzz> I'm wondering if we couldn't optimize gcc to use 16-bit registers on i386
[02:13] <Chipzz> or even 8-bit :P
[02:13] <svu> infinity, what kind of advantage do I get with 64-bit kernel then?
[02:14] <Keybuk> I still have the Osbourne 4 and 8-bit Microprocessor Handbook somewhere
[02:14] <infinity> svu: The advantage of being able to run a few 64-bit binaries if you really need them?
[02:14] <Chipzz> I was only half-kidding actually
[02:14] <infinity> svu: And just the obvious case that on your hardware, people are probably testing the 64-bit kernel codepath more than the 32-bit one.
[02:14] <ajmitch> Keybuk: nice, all I have is one on 6502 assembly 
[02:14] <dieman> and you can actualy use your memory if you have it
[02:14] <svu> infinity, :)) I see. I can run 64-bit binaries - but they are just not there in ubuntu:)
[02:14] <dieman> whomever came up with PAE on i386 should be shot, too
[02:15] <dieman> they should have just decided 'damnit, lets do something 64 bit'
[02:15] <infinity> svu: What specific binary did you want t obe 64-bit?  Or is it just the principle of the thing?
[02:15] <dieman> rather than confusing the hell out of people who dont know how PAE works
[02:15] <Chipzz> a wild guess would be 40% or even 50% of all integer vars would fit in 16-bit containers
[02:15] <dieman> and thinking they can allocate over 4gb of memory
[02:15] <infinity> dieman: PAE is scary.
[02:15] <dieman> infinity: yes
[02:16] <dieman> infinity: you ever see the benchmarks that heanet.ie did with apache and pae?
[02:16] <svu> infinity, well, just the principle. In particular, I wonder would all the build tools (autotools/gcc/ld/....) work faster if they were 64-bit. Also OOo
[02:16] <dieman> infinity: 4GB was about the same peformance as 12GB
[02:16] <dieman> infinity: but 32GB you'd actually be doing fairly well
[02:16] <Chipzz> svu: OOo definately not
[02:16] <Keybuk> svu: why would they be faster?
[02:16] <mjr> svu, they wouldn't.
[02:16] <dieman> infinity: (mostly acting as disk cache)
[02:16] <svu> Keybuk, faster data operations?
[02:16] <Keybuk> autotools is written in shell/perl -- that'd be hauling twice as much around, so be half the speed
[02:16] <HrdwrBoB> at that point, you'd be better off with a RAMSAN
[02:17] <infinity> svu: No, no, and no.  And OOo won't even compile on 64-bit systems.
[02:17] <HrdwrBoB> (though I think everyone is better off with RAMSAN)
[02:17] <Keybuk> svu: what makes you think 64-bit data operations are faster than 32-bit ones?
[02:17] <Chipzz> svu: doesn't matter one bit for small integers
[02:17] <HrdwrBoB> infinity: we're lucky it compiles at all
[02:17] <svu> infinity, ok, I see.
[02:17] <Keybuk> svu: unless you're dealing with >32-bit word sizes
[02:17] <dieman> HrdwrBoB: they've got way too much disk though, i think
[02:17] <dieman> HrdwrBoB: its not just for a few GB of files, its more like a few TB im guessing.
[02:17] <svu> Keybuk, in SOME cases people use "long long", or even memcpy...?
[02:17] <Chipzz> svu: less cache hits, especially with OOo
[02:18] <dieman> HrdwrBoB: and i think they still use the apache disk cache module to pull popular files automatically to a striped raid
[02:18] <Keybuk> svu: you win some, but lose a lot from the larger instruction and data sizes
[02:18] <dieman> HrdwrBoB: and then an assload of ram for disk caching
[02:18] <Keybuk> 64-bit is basically useful for doing complex integer math
[02:18] <Keybuk> eg. SSL or MPEG or something
[02:18] <svu> infinity, what about altivec extension? is it used by ubuntu?
[02:18] <infinity> Keybuk: Or hauling massive datasets around.
[02:18] <HrdwrBoB> dieman: well.. damn!
[02:18] <Chipzz> svu: just about the only thing it does make sense for by default is things like memcpy, and those are in glibc
[02:19] <dieman> HrdwrBoB: yah
[02:19] <infinity> Keybuk: Some SQL servers seem to win from being 64-bit (if you have massive tables and indexes)
[02:19] <svu> Keybuk, ok, I see now...
[02:19] <Keybuk> yeah, that I can believe
[02:19] <infinity> Keybuk: But for most SQL usecases, 32-bit wins, so you really need to KNOW that you want 64-bit before you take the hit.
[02:19] <infinity> svu: ^^^^
[02:19] <svu> Chipzz, yeah, that's what I meant - massive memory operations
[02:19] <Keybuk> I always find it amusing that almost the only 64-bit app in Solaris 9 was "sort"
[02:20] <Keybuk> it was the only one that benefited
[02:20] <infinity> svu: As a general rule, if you think that a dedicated machine of some sort may benefit from having something specific recompiled (say, postgresql, for instance), we provide the tools for you to easily do that and benchmark.
[02:21] <infinity> svu: Down the road, we intend to have better multiarch support, so it'll be trivial for us to provide ppc64 versions of certain libraries and applications that you MAY want 64-bit.
[02:21] <infinity> svu: But, the general use cases for just about everything will show you that 32-bit wins.  If 64-bit wins for you, you're an oddity.
[02:21] <infinity> svu: (ie: massive data warehousing, etc)
[02:21] <svu> infinity, ok. I am not a gentoo person, I so I am not trying to squeeze every grain of performance - just trying to get a feeling, is there possible major win against the current arch...
[02:21] <Chipzz> infinity: but you can't mix 32 and 64-bits libraries anyway, right/
[02:21] <Chipzz> ?
[02:21] <Keybuk> Chipzz: depends on the instruction set
[02:22] <Chipzz> I'm thinking calling conventions for one
[02:22] <infinity> Chipzz: Can't link both in the same memory space, no.  (or, not worth trying)
[02:22] <svu> infinity, ok. But I did not get the answer regarding the altivec extension?
[02:22] <Chipzz> svu: stuff like that is hand-coded assembly in most cases anyway
[02:23] <infinity> svu: altivec is orthogonal to the 32/64-bit thing, and where we can use it effectively, we do (mplayer autodetects altivec support and uses it, libssl has an altivec optimised version, IIRC, etc)
[02:23] <Kamion> svu: altivec needs to be hand-coded, as Chipzz says
[02:23] <svu> Chipzz, I know - so I am asking is there that kind of assembly somewhere in kernel or openssl or smth
[02:23] <infinity> Actually not positive about the libssl thing.  Does powerpc have hwcap support?
[02:23] <Kamion> there are hand-coded versions of a few things, yes
[02:23] <Chipzz> Kamion: not per se I think, but your compiler needs good support for it when you don't (which is only the case in recent gcc's)
[02:24] <Kamion> ok, very very recent gcc can do automatic vectorisation
[02:24] <svu> infinity, i know it is orthogonal, it was a separate question:)  do you ship altivec-optimized mplayer or libssl?
[02:24] <Kamion> no altivec code in openssl
[02:25] <infinity> svu: mplayer, yes.  A quick look at my PPC system seems to show that we don't do hwcap on PPC, so we can't pull the "multiple optimised builds" trick that we do on i386.
[02:26] <svu> infinity, heh:( BTW, would xorg opensource drivers benefit of altivec anyhow (2D/3D accel)?
[02:26] <infinity> svu: libssl doesn't do run-time capabilities detection, so enabling altivec there would result in a big SIGILL on systems like mine.
[02:27] <svu> infinity, I see, so you would need plenty of libssl builds
[02:27] <infinity> svu: And glibc support for hwcap selection on powerpc (which appears to not exist, afaict)
[02:27] <svu> (actually at some point RH provided different rpms for openssl for 386/586/686 IIRC)
[02:27] <Kamion> no reason we can't do hwcap on powerpc
[02:27] <infinity> (See /usr/lib/i686/ on an i386 system, for instance)
[02:28] <infinity> Kamion: Nope, should be trivial, we just don't appear to do so.
[02:28] <Kamion> 'strace id' shows us looking at stuff like /usr/lib/tls/ppc7450
[02:28] <infinity> Kamion: Heck, I'm committing hwcap to m68k reasonably soon.
[02:28] <Kamion> which looks like hwcappery to me
[02:28] <Kamion> and there are hwcap defines for powerpc in glibc
[02:28] <infinity> Kamion: Oh.  So PPC does have hwcap, and we just don't use it?  Even better.
[02:29] <Kamion> #define PPC_FEATURE_HAS_ALTIVEC         0x10000000 /* SIMD/Vector Unit.  */
[02:29] <Kamion> dunno what that corresponds to in terms of ld.so, mind
[02:29] <infinity> Mayve libssl just has crap hand-tuning on PPC so no one cares.
[02:29] <svu> so, we are talking about ... err tiny patch to libssl?:)
[02:30] <infinity> We're talking about a patch I don't much care about, since my system's a G3. :)
[02:30] <infinity> If you can convince someone with a whizzbang CPU to care more than I do, go nuts.
[02:31] <svu> infinity, oops:))
[02:31] <desrt> but i still have a cluster of G5s at work
[02:31] <Kamion> oh, actually, I think infinity's right and we don't have proper glibc support for hwcap on powerpc
[02:31] <svu> s/bye/buy
[02:31] <Kamion> there's no _dl_string_hwcap implementation for powerpc
[02:32] <infinity> Kamion: Hrm, but the strace above seemed to indicate otherwise...
[02:32] <infinity> Kamion: It could just be implemented differently.
[02:32] <Kamion> yeah, dunno where that was coming from, I have a feeling it was something generic
[02:33] <Kamion> at any rate I'm not seeing the linker touching /lib/altivec or anything here, which I'd expect
[02:34] <Kamion> and the only matches for '"altivec"' in sysdeps are in .machine directives in assembly code, which aren't relevant
[02:35] <svu> ok, so it seems the only real use is mplayer...
[02:35] <svu> thanks lads, you are just eye openers;)
[02:36] <Keybuk> and nobody watches *that* much porn to make it a serious benefit? :p
[02:37] <infinity> svu: I had tossed around the idea of buying a quad-core G5 at one point, but I weighed that against paying rent, and opted for the latter.
[02:37] <infinity> svu: If you want to send me one, I won't complain.
[02:38] <infinity> For now, the old 1GHz G3 is good 'nuff.
[02:39] <svu> infinity, actually I won my dual G5 at linux-powerpc contest by IBM. I would never buy any mac from my pocket:)
[02:40] <dredg> i end up not breaking it :)
[02:40] <desrt> svu; i tried to enter that contest and failed.
[02:41] <dredg> i use ubuntu quite a lot for work, but my machine tends to be broken a fair bit :)
[02:41] <svu> desrt, I  was lucky. My application just had to be "configure/make/make install"-ed - and it worked :)
[02:41] <dredg> so i use a mac for doing most things, and ssh when i need linux
[02:41] <desrt> crikey
[02:41] <desrt> i wrote an email to them saying "please let me port a compiler backend" and got rejected
[02:41] <desrt> or, more precisely, they never even replied
[02:43] <svu> dredg, I am thinking about removing macos altogether - but not yet...
[02:43] <desrt> holy crap!
[02:44] <desrt> anyone have chips.exe laying around? :)
[02:44] <desrt> oh yes.
[02:44] <desrt>  /home/desrt/archives/old nt server/rlortie/bin/chips/CHIPS.EXE
[02:45] <dredg> svu: i need one machine that works at all times, so i refuse to change/break/kill the OS on the machine :)
[02:47] <desrt> that ws NEAT!
[02:47] <desrt> wine CHIPS.EXE -> my machine instantly reboots
[02:47] <desrt> i'm pretty sure that's not supposed to be possible
[02:48] <Keybuk> isn't wine setuid root, or something crazy?
[02:48] <desrt> nope.
[02:48] <desrt> nor is wineserver
[02:48] <svu> dredg, I have ubuntu for it:)
[02:48] <desrt> i think i've found a security problem
[02:49] <ajmitch> desrt: probably triggering kernel or X bugs, it's probably not unusual :)
[02:49] <Keybuk> desrt: likely wine crashed X, which runs as root
[02:49] <dredg> svu: right, the primary project i'm working on at the moment involves customising ubuntu for our users. if i put ubuntu on the mac i'd end up using it for testing or something :)
[02:49] <desrt> Keybuk; and caused the kernel to reboot?
[02:49] <dredg> i _need_ an unbroken machine :)
[02:50] <dredg> it's a slippery slope ;)
[02:50] <Keybuk> desrt: sure, X runs as root and does nasty things to the hardware
[02:50] <svu> dredg, well, I am trying to balance between development of gnome and keeping relatively stable machine (which is also controlling my X10 stuff at home)
[02:50] <Keybuk> desrt: it's very easy to get X to crash the machine hard enough to reboot it
[02:51] <desrt> wrong.
[02:51] <desrt> it's a kernel bug
[02:51] <desrt> the ssh server rebooted
[02:51] <desrt> read: remote user can bring the sytem down
[02:52] <Keybuk> ssh server rebooted?
[02:52] <Keybuk> ssh servers don't reboot
[02:52] <desrt> the machine running the ssh server :p
[02:52] <Keybuk> it's a local root exploit
[02:52] <Keybuk> not a remote one
[02:52] <Keybuk> you ssh'd in with authorisation
[02:52] <Keybuk> there's plenty of those
[02:52] <desrt> heh.
[02:53] <desrt> i didn't say it was 'remote root'
[02:53] <desrt> it's probably not even local root
[02:53] <desrt> just DoS
[02:53] <dredg> svu: ow. good luck with that :)
[02:54] <svu> dredg, thanks:)
[02:55] <dredg> and this week i get to work on a laptop cos i'm in santa monica. like fun, but subtly different :)
[03:00] <desrt> running under cedega freezes the system solid (but no reboot)
[03:02] <BenC> so is edgy open yet? :)
[03:02] <desrt> BenC; when do you think about this bug?
[03:03] <desrt> BenC; it's probably related to somethng weird like allowing userspace processes to manipulate the local descriptor table
[03:04] <Kamion> BenC: needs an LP rollout in about two hours
[03:05] <BenC> desrt: which bug...I missed some context
[03:05] <desrt> BenC; i can reboot my system over ssh 
[03:05] <BenC> are you not supposed to be able to do that? :)
[03:06] <desrt> i can do it from a normal user account just by running wine on an old windows game
[03:06] <BenC> ah, wine
[03:06] <BenC> wine is running as root?
[03:06] <desrt> no.  i don't think so.
[03:06] <BenC> if it's not running as root, then that's a super serious bug
[03:07] <BenC> err, super serial
[03:07] <desrt> https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/48769
[03:08] <desrt> finding out more...
[03:08] <BenC> does it happen on console as well as over ssh?
[03:09] <desrt> it happens when i use X directly and with X forwarding over X
[03:09] <desrt> *over ssh
[03:09] <desrt> afaik wine won't run without having an X server somewhere
[03:09] <BenC> right
[03:09] <BenC> can you email me a copy of that game?
[03:09] <desrt> sure
[03:09] <BenC> or do you have a copy?
[03:10] <desrt> it happens with my totally unprivilged jail user too
[03:10] <desrt> so it's not likely to be something like accessing the soundcard in an odd way
[03:10] <BenC> I have wine running under amd64, so it may do something different
[03:10] <desrt> i already tried running it on my friends dapper (amd32) box and it doesn't crash
[03:10] <BenC> it does run in 32-bit mode, but the kernel's a bit different about it since it's emulation
[03:11] <desrt> i attached to the bug
[03:12] <elmo> desrt: err, don't do that
[03:12] <elmo> seriously
[03:12] <desrt> surely this falls under fair use :p
[03:12] <elmo> no, it doesn't
[03:13] <desrt> is it possible to remove attachments?
[03:15] <desrt> damn.  it kills my laptop too :(
[03:15] <DarkMageZ> chips challenge?
[03:15] <desrt> rawr :(
[03:15] <DarkMageZ> u using wine from the dapper repos?
[03:16] <desrt> mhm.
[03:25] <bddebian> Hey
[03:40] <Toadstool> heya devs :)
[04:54] <LaserJock> and then Caritas will soon be uttering, "ok, very very recent gcc can do automatic vectorisation" and "i know it is orthogonal, it was a separate question:)  do you ship altivec-optimized mplayer or libssl?" to quote
[04:54] <LaserJock> crap
[04:54] <LaserJock> sorry guys
[04:54] <ajmitch> heh
[04:56] <bddebian> :-)
[05:37] <tale_> I'm trying to compile eye of gnome from cvs, can somebody help me configure my environment?
[05:40] <Chipzz> tale_: no; this channel is about development OF ubuntu, not development WITH ubuntu
[05:41] <Chipzz> and you want apt-get build-dep eog
[05:41] <tale_> Chipzz: I'm trying to find some docs that help configure ubuntu for development
[05:41] <Burgundavia> tale_: #gnome-love on gimp.net can help you with that
[05:42] <tale_> ok
[05:42] <tale_> I'll give it a try
[06:01] <whiprush_> mako: congratulations
[06:05] <tale_> where do the developers hang out to talk about developer stuff when not coordinating/
[06:05] <tale_> ?
[06:07] <Burgundavia> tale_: of GNOME or Ubuntu?
[06:09] <mako> whiprush_: thank
[06:09] <mako> s
[06:10] <whiprush_> I see you wore the aviators for the wedding, heh.
[06:10] <Burgundavia> mako: indeed, congrats you crazy married man
[06:11] <mako> :)
[06:13] <ajmitch> hey mako 
[06:15] <mako> ajmitch: oi
[06:19] <licio> oi?
[06:20] <licio> oi means hello in portuguese
[07:13] <stub> Launchpad will be going down in 20 minutes for its regular code update. Estimated down time is 10 minutes.
[08:32] <pitti> Good morning
[08:33] <ajmitch> morning pitti 
[08:33] <Burgundavia> hey pitti, can you take a look at https://wiki.ubuntu.com/FirefoxFAQ
[08:35] <Burgundavia> pitti: specifically the 2nd part
[08:35] <Burgundavia> hey mvo
[08:36] <ajmitch> morning mvo 
[08:37] <Hobbsee> Burgundavia: that second part is pretty unclear - and isnt exactly correct, IIRc
[08:37] <Burgundavia> Hobbsee: it needs to be fixed. I banged it out, hence the request for review
[08:38] <ajmitch> ah firefox
[08:38] <ajmitch> that flagship application of the free software movement..
[08:38] <Hobbsee> Burgundavia: the idea is that ubuntu has security updates, and the minor versions of firefox are released due to their security fixes.  feature-only upgrades arent included in that - that's my understanding of it anyway
[08:38] <Hobbsee> mmm...lovely firefox :)
[08:39] <Burgundavia> Hobbsee: yep, but we backport FF because moz has a broken security policy
[08:39] <Hobbsee> true
[08:39] <mvo> good morning Burgundavia ajmitch
[08:40] <Hobbsee> hi mvo 
[08:47] <mvo> hi Hobbsee
[08:49] <ajmitch> hey dholbach 
[08:50] <dholbach> good morning!
[09:53] <sivang> howdy all
[09:53] <sivang> finally with a good network connection.
[09:53] <pitti> hi sivang 
[09:53] <sivang> hey pitti , 'sup?
[09:54] <Hobbsee> hey sivang 
[09:55] <Hobbsee> :P
[10:00] <sivang> it's pretty quite the last couple of days, which is goo :-)
[10:02] <ajmitch> sivang: because we're all working hard
[10:04] <sivang> ajmitch: nice, on specs? :)
[10:04] <ajmitch> & SoC
[10:04] <dholbach> <- bugs
[10:05] <Hobbsee> bye all
[10:05] <sivang> ajmitch: ah right, how is Net Quth going ?
[10:05] <ajmitch> bye Hobbsee 
[10:06] <ajmitch> sivang: going well enough, got plenty to work on :)
[10:07] <sivang> cool 
[10:19] <pygi> sivang, finally ;)
[10:20] <sivang> pygi: I had terrible network problems yesterday
[10:20] <sivang> pygi: I've switched locations and am back to good
[10:20] <pygi> sivang, I know, don't worry :)
[10:24] <pygi> sivang, you are writing to HomeBackupNg I suppose?
[10:29] <sivang> pygi: I think I will just refresh the already existing spec page. -NG should be saved to the more featureful versoin. for edgy, it's  okay to call it the same name, just this time make it with all the planned features that were planned for dapper. I will save the NG page for edgy+1 and take from there all the relevant ides for edgy version.
[10:29] <pygi> sivang, ah, ok
[11:20] <ajmitch> morning sabdfl 
[11:21] <sabdfl> hi there ajmitch
[11:36] <tepsipakki> sabdfl: when will we (=!Canonical) hear more about landscape?-) I can't wait..
[11:41] <jono> hey ajmitch, sabdfl
[11:41] <ajmitch> hi jono 
[11:44] <mdke> is there a list of languages supported on the desktop cd?
[11:46] <infinity> mdke: apt-cache show ubuntu-live
[11:46] <nomed> mdke, the manifest file ?
[11:47] <nomed> well.. apt-cache seems much better :)
[11:48] <infinity> The manifest is more correct (in the sense that it matches the ISO, while ubuntu-live chould change the next time we upload it), but checking ubuntu-live's depends was a nice lazy shortcut. :)
[11:49] <mdke> thanks infinity 
[11:49] <mdke> argh, no italian
[11:50] <mdke> welsh, but no italian
[11:50] <jono> mdke: its a crazy world
[11:51] <mdke> that is pretty crazy. Loads of ubuntu users in italy, no idea how many welsh, estonian, amharic, hindi users there are. Perhaps those language packs are just smaller
[11:53] <pitti> mdke: we sorted first by number of people speaking a language (the 'top 12'), then just alphabetically
[11:54] <mdke> pitti: number of people speaking a language in the worl, regardless of how large the linux/Ubuntu communities are?
[11:55] <ajmitch> looks like the version numbers took a huge jump after 0.81
[12:00] <pitti> mdke: yes, it was the least subjective measure we could come up with at the time we defined it
[12:00] <fabbione> Kamion: ping?
[12:01] <mdke> pitti: I can understand that, sure. It's a bummer for communities like -it with really large Ubuntu followings though. I don't really know what we can do to alleviate the problem either... there are some unofficial italian ISOs but obviously they aren't available from shipit.
[12:03] <pitti> mdke: that's precisely why we avoided introducing hard-to-measure numbers, to avoid discussions like '... but we are more important'
[12:04] <pitti> mdke: so we need an objective standard
[12:04] <pitti> mdke: maybe we should change it in future releases, from #people to the percentage of translated strings
[12:04] <fabbione> Kamion: unping :)
[12:06] <pitti> mdke: that would mean to fit fewer langpacks on the CD, but might eventually be better, since bigger coverage usually means bigger community participation
[12:06] <pitti> mdke: and it could have the interesting side effect of challenge :) (translation rave to win the space on CD :) )
[12:07] <ivoks> we should kick gnome out, so we can put translations... for gnome :)
[12:10] <mdz> mjg59: are you coming to Paris?
[12:11] <Kamion> fabbione: er, ok ;)
[12:11] <fabbione> Kamion: thanks anyway .. i figured :)
[12:14] <carlos> pitti: hi
[12:14] <pitti> hey carlos 
[12:14] <ivoks> pitti: btw, if we are going for 1.2.1, do you think it's wise to enable snmp printer detection?
[12:14] <pitti> ivoks: no, not for -updates
[12:14] <ivoks> pitti: i agree
[12:14] <pitti> ivoks: also, I think I rather backport fixes
[12:14] <carlos> pitti: could we schedule our voip call to talk about language packs for Universe?
[12:15] <carlos> pitti: I would like to have something already done before Paris
[12:15] <ivoks> pitti: that's fine with me
[12:15] <pitti> carlos: voip doesn't work well here, let's use the normal phone
[12:15] <carlos> pitti: skype?
[12:15] <ivoks> khm.. ekiga guys :)
[12:15] <pitti> carlos: no, I have too much latency over the chain of wireless networks here
[12:15] <pitti> carlos: I'll phone you
[12:16] <\sh> pitti: getting rid of the printing problems? 
[12:16] <carlos> pitti: no, don't worry, I could phone you using a voip gateway
[12:16] <carlos> so it's not so expensive
[12:16] <ivoks> \sh: actully, there is only one printing problem
[12:17] <pitti> \sh: ... some :) at least we are about to kill bug 34112
[12:17] <\sh> ivoks: hehe :) you did read kurts next article about your package? ;)
[12:17] <ivoks> \sh: nope
[12:18] <ivoks> \sh: kde domain are offten broken, so i don't visit them :)
[12:19] <ivoks> \sh: lol those packages aren't dapper 1.2.1 preview packages :)
[12:20] <\sh> ivoks: you are famous now ;) 
[12:20] <ivoks> "add their own README.Canonical.gz"?
[12:21] <mjg59> mdz: Nope
[12:21] <ivoks> he has some issues that ubuntu and cups can't resolve :)
[12:26] <mdke> pitti: yeah I see all your points about the objective standard. I was just trying to figure out what communities who have been left out can do to provide localised CDs
[12:28] <giftnudel> lol, the black box while printing was a cups bug? and we bugged our prof + assistants at the university about it telling them they are too dumb to produce valid pdf files (they used powerpoint) ...
[12:29] <pitti> giftnudel: shall I add '* Fix printing of broken PowerPoint PDF files" into the changelog? :-P
[12:29] <giftnudel> hehe
[12:29] <pitti> giftnudel: seriously, it's more of a side effect
[12:29] <giftnudel> yes, I noticed
[12:29] <giftnudel> but still it's funny
[12:41] <ivoks> time to go... see you
[12:48] <zul> heylo
[12:53] <makko> my ubuntu has a strange behaviour: all my mc (midnight commander) file browsing is recorded in the bash_history like (in this format: cd `echo -en "..."`); what's even more interesting is that each number within a path is represented as some sort of escaped codes (as though it is writing any digit in its ascii code). any idea what this is?
[12:53] <makko> my ubuntu has a strange behaviour: all my mc (midnight commander) file browsing is recorded in the bash_history (in this format: cd `echo -en "..."`); what's even more interesting is that each number within a path is represented as some sort of escaped codes (as though it is writing any digit in its ascii code). any idea what this is?
[12:53] <makko> (corrected)
[12:55] <Chipzz> makko: no support in this channel kthxbye
[12:56] <makko> Chipzz: does it look like i'm asking for support?
[12:56] <mdke> makko: yes, twice
[12:56] <Chipzz> "any idea what this is?"
[12:56] <fabbione> yes
[12:56] <Chipzz> YES
[12:56] <fabbione> makko: -> #ubuntu
[12:56] <zul> certainly yes
[12:57] <makko> Chip: i got around it! now i just wanted to talk about it as of something curious.
[12:58] <makko> Chip: asking for support means asking for help. i am asking for debate.
[12:58] <makko> Chip: never mind.
[12:58] <Chipzz> then you should have asked differently
[12:58] <Chipzz> 5 people agreed within 10 seconds that yes you were asking for support
[12:58] <makko> Chipzz: please show me how
[12:59] <makko> Chipzz: boy, i love these democratic arguments :)
[12:59] <Chipzz> dunnow, don't care either
[12:59] <Chipzz> makko: take this upstream or whatever
[12:59] <makko> Chipzz: yes. and you have to agree it's quite curious.
[01:00] <Chipzz> makko: since you are on irc, I suppose you can read
[01:00] <jsgotangco> the point is we don't need more noise in this channel
[01:00] <Chipzz> read the little thingies called letters please
[01:00] <makko> jsgotangco: got it, and i agree.
[01:01] <Chipzz> most of the people here don't even *use* mc so would have little or nothing to contribute to your "discussion"
[01:01] <Chipzz> even if that were, in some bizarre way, relevant
[01:03] <makko> Chipzz: well, is there anything else you would like to add? because, if not, i will leave the channel.
[01:03] <makko> Chipzz: ok
[01:04] <zul> shesh
[01:05] <Chipzz> actually I did have sth to add... "Stop highlighting me" :P
[01:06] <Chipzz> but that may have been too rude :P
[01:10] <zul> pitti: ping
[01:27] <pitti> hi zul
[01:27] <sivang> mvo: hi , besides update-manager we also have an upgrade manager right?
[01:27] <zul> pitti: did you have a look at my email?
[01:28] <pitti> zul: I'm at phone right now, will TTYL
[01:28] <zul> pitti: ok ill be around
[02:01] <pitti> zul: re
[02:01] <pitti> zul: thanks for the update, I'll update the wiki page and ubuntu-cve
[02:04] <zul> ok should i upload it today or wait still?
[02:04] <pitti> zul: please wait, the queue is eating uploads ATM
[02:05] <pitti> zul: and I'd like to get a comment from Ben about the three issues that aren't fixed in hoary and breezy
[02:17] <zul> pitti: yep no problem
[03:41] <tseng> mdz: I am thinking on the topic of making beagle sensible on the edgy livecd
[03:41] <tseng> mdz: we can build a static index of /home (example content and such) and then autostart beagled with all the indexers disabled
[03:42] <tseng> mdz: as to not thrash the live system
[03:42] <Mithrandir> tseng: we can't tell it to just look in /home?
[03:42] <tseng> mdz: but how to handle having it behave differently on livecd than in install?
[03:42] <HiddenWolf> tseng: I guess a problem would be to fit mono on the cd.
[03:42] <Mithrandir> walking through that should be fast enough.
[03:43] <tseng> HiddenWolf: sure it would
[03:43] <tseng> Mithrandir: it does that
[03:43] <Mithrandir> tseng: oh, ok.
[03:43] <tseng> I am honestly not sure if it would be that bad on a fast box
[03:43] <Mithrandir> tseng: I prefer to have all hacks related to the live cd in casper and not random other packages.
[03:44] <tseng> it seems at first thought like something we would want to avoid
[03:45] <tseng> I guess we will have a good idea when we respin the mono-live cd
[03:45] <tseng> with dapper
[03:45] <\sh> re
[03:45] <Mithrandir> is there any way to reject specs which doesn't make sense?
[03:45] <tseng> you mean mine?
[03:45] <tseng> :P
[03:45] <ogra> Mithrandir, i think only mdz and sabdfl can reject specs 
[03:46] <Mithrandir> no, I mean https://launchpad.net/distros/ubuntu/+spec/livecd-apt-install-to-usbflash which is covered by the live cd persistency stuff.
[03:47] <tseng> I wonder if we create a static index of home and leave all backends running
[03:47] <tseng> if it would touch each file and then go to sleep
[03:48] <Mithrandir> you need casper to mount / with user_xattr, don't you?
[03:48] <tseng> it isnt required
[03:48] <tseng> but it runs like crap w/o it
[03:48] <Mithrandir> so you need it. :-P
[03:48] <tseng> :)
[03:48] <tseng> I have been running user_xattr since before UDU
[03:56] <Kamion> Mithrandir: you could mutate it into a "polish up UI for livecdpersistency" spec
[03:56] <Kamion> Mithrandir: (livecdpersistency is great, but it's kind of a kit of parts at the moment ...)
[03:57] <Mithrandir> Kamion: true dat.. problem is, that's hard to do. :-)
[03:57] <Mithrandir> (if not, I'd just have done it)
[03:58] <Kamion> yeah, worth a spec then maybe so it gets resources assigned? :)
[03:58] <Kamion> that'll be fun to merge
[03:59] <Mithrandir> uh, to kbd?  Isn't kbd even more crufty than c-t?
[03:59] <Kamion> Mithrandir: it alternates; one year one is more crufty, one year it's the other
[03:59] <Kamion> this year apparently kbd is being maintained
[03:59] <Kamion> (by Denis Barbier)
[04:00] <Mithrandir> if we get lcxkb in, we'll have another implementation which can collect cruft, then.
[04:00] <Mithrandir> (hopefully, it'll kill off both kbd and c-t)
[04:00] <Kamion> doesn't lcxkb sit on top of one of them?
[04:00] <Kamion> maybe not ...
[04:00] <Kamion> I was just starting to write SaneInstallerKeyboard, hence why I noticed this
[04:01] <Mithrandir> so far it sits on top of my head as a pile of ideas, mostly.
[04:01] <Kamion> I'll link to zinoviev's console-setup
[04:01] <Kamion> I realise it needs a perl->c rewrite but that might be easier than a nothing->c rewrite
[04:02] <Kamion> given he's probably ironed out at least a few of the bugs
[04:02] <Mithrandir> I'm thinking we want to write a library for parsing xkb file written since there's none so far.
[04:03] <Mithrandir> and then we can write something on top of that.
[04:03] <Mithrandir> that should make xkb upstream happy too.
[04:04] <Kamion> I just don't want to throw away entirely what Anton's been doing, since apparently he does have something that actually works
[04:05] <Mithrandir> sure, looking at it while rewriting it in C would work.
[04:06] <Kamion> hmm, you know, I wonder if it's actually a problem that it's in perl; kbd-chooser wants a static list of keymaps rather than "everything expressible in xkb" anyway
[04:06] <Kamion> so why not just precompile the list of stuff we care about at kbd-chooser build time?
[04:07] <Kamion> the less we have to stuff in the d-i initrd, the better, anyway
[04:08] <Mithrandir> true, but sizeof compressed /etc/X11/xkb < sizeof compressed /usr/share/keymaps
[04:08] <Mithrandir> and not having an intermediate format is a win
[04:10] <Mithrandir> while I agree having to write less software is better, too.
[04:12] <sivang> geez, finally caught up with ubuntu-devel , that was long
[04:12] <Kamion> well, this is why I wrote "investigate" in the rationale, I guess. :)
[04:15] <mdz> tseng: sounds interesting, would be cool to be able to demo beagle on the live CD
[04:15] <mdz> tseng: can it work on squashfs?
[04:16] <tseng> mdz: you know what, I didnt think of that, no idea how it will work
[04:16] <mdz> Kamion: didn't we all move from kbd to console-tools not too long ago?
[04:16] <tseng> mdz: we are rolling mono-live with dapper, I will have a better idea what happens after that
[04:16] <tseng> just thinking of ways to make a smooth experience on live fs
[04:17] <tseng> i noticed it was on your EdgyIdeas
[04:17] <Kamion> mdz: yep, about three or four years back; like I say, it appears to oscillates
[04:17] <Kamion> s/s$//
[04:21] <Mithrandir> mdz: the question is less whether it works on squashfs than on unionfs.  And I can't really see a reason why it won't.
[04:22] <mdz> Mithrandir: if we want to ship it with a pre-generated index (and we do), then it would need to be stored in the squashfs
[04:22] <Mithrandir> mdz: true.
[04:29] <tseng> i dont know whether or not beagle-build-index makes any use of xattr
[04:29] <tseng> i have a feeling it doesnt
[04:30] <tseng> which would seem to make the underlying filesystem irrelevant
[04:30] <pitti> mdz: what do you think about bug 34112? I'd like to see the updated package in dapper-updates, given the insane number of duplicates and people who are bitten by this
[04:30] <Ubugtu> Malone bug 34112 in libgnomeprint "gnome programs don't respect ~/.cups/lpoptions" [Unknown,Unknown]  http://launchpad.net/bugs/34112
[04:31] <pitti> mdz: the bug title is a bit misleading, btw, the ~/.cups/lptions part is already fixed in dapper
[04:33] <mdz> pitti: it's long and the summary doesn't help; what's the issue?
[04:33] <pitti> mdz: none of the printing options you set in the gnome print dialog becomes effective
[04:33] <pitti> mdz: i. e. paper size, 2-on-1, gray or color, etc.
[04:34] <pitti> mdz: and it's even impossible to print some PFDs, it only yields black boxes instead of pictures
[04:34] <pitti> mdz: the last item is a bit magical, but I heard two reports that it's fixed by this as well
[04:34] <bddebian> Hello
[04:35] <ajmitch> hi
[04:35] <zul> hey
[04:36] <bddebian> Heya zul
[04:36] <ajmitch> there is only zul!
[04:36] <zul> thats is correct..
[04:36] <Hobbsee> there are two hobbsees :(
[04:37] <bddebian> ajmitch: I already said Hello to you in -motu :-)
[04:37] <kagou> mdz, i can say as pitti that resolving this bug is really wanted/needed. Printing from gnome applications (using libgnomeprint, evolution/gedit/evince..., not OpenOffice, not firefox) do not works, or works really bad. it would be great to fix this bug
[04:37] <bddebian> Is this still the cups bug?
[04:37] <kagou> bddebian, yep
[04:38] <mdz> kagou: I printed from evince recently in dapper and it worked very well
[04:38] <mdke> I've printed several times today from evince
[04:39] <pitti> then you never tried to alter any printer option
[04:39] <mdz> that is possible
[04:39] <pitti> I seldomly do, either, that's why I never noticed that
[04:39] <kagou> mdz, try to change your settings to grayscale/draft. and reprint with evince
[04:39] <pitti> well, I hardly ever print in the first place..
[04:40] <kagou> mdz, some user force the use of their black carttridge, but evince do not matter and use 3 colors to render black (for example)
[04:42] <mdz> kagou: why does changing the options trigger this problem?
[04:42] <mdz> does it matter which setting(s) is/are changed?
[04:42] <pitti> mdz: the problem is that changing the options doesn't work in the first place
[04:42] <kagou> indeed
[04:42] <pitti> mdz: 2 on 1, 4 on 1, grayscale, paper format, etc - it's all just ignored
[04:43] <mdz> pitti: ignored is one thing; breaks printing is another
[04:43] <pitti> mdz: I just ask because there's a neverending flood of bugs
[04:44] <mdz> pitti: which is it?
[04:44] <pitti> mdz: which is what?
[04:44] <giftnudel> bug 34112 ?
[04:44] <Ubugtu> Malone bug 34112 in libgnomeprint "gnome programs don't respect ~/.cups/lpoptions" [Unknown,Unknown]  http://launchpad.net/bugs/34112
[04:44] <mdke> ah, that's right, 2 on 1 doesn't work. But it does successfully print
[04:44] <mdke> so it's "ignored" rather than "breaks"
[04:45] <pitti> yeah, it's just that 27 duplicates indicate that this really seems to bite a lot
[04:46] <mdke> heh
[04:46] <mdz> pitti: is the problem that the options are ignored, or that printing stops working entirely if you change an option?
[04:46] <pitti> mdz: the former
[04:46] <mdz> ok
[04:46] <mdz> so kagou seems to be exaggerating the problem
[04:47] <mdz> kagou: are you the author of the patch?
[04:47] <kagou> mdz, no :)
[04:48] <pitti> mdz: not being able to change the paper size and orientation is probably the thing that hurts most
[04:48] <pitti> mdz: i. e. impossible to print landscape or on A3/A5/whatever
[04:48] <pitti> so you can still print, but it might not actually be useful
[04:49] <kagou> mdz, Bug #21722
[04:49] <Ubugtu> Malone bug 21722 in gnome-cups-manager "A4 paper size unalterable in printer setup" [Medium,Needs info]  http://launchpad.net/bugs/21722
[04:52] <mdz> pitti: who did write the patch?  is it upstream?
[04:53] <pitti> mdz: Pascal de Vuyst; it's not upstream since upstream is dead for some time
[04:53] <mdz> pitti: oh wonderful
[04:53] <pitti> mdz: that's why it is in such a bad shape in the first place, people are concentrating on gtk print support 
[05:00] <mdz> pitti: this has always been broken?
[05:00] <pitti> mdz: I didn't check breezy
[05:01] <pitti> shall I?
[05:01] <giftnudel> I can test in 3 minutes (need to boot computer)
[05:02] <mdz> pitti: if you can
[05:03] <mdz> I do have a ~/.lpoptions which sets the page size, and that seems to work
[05:04] <kagou> mdz, under breezy ? or dapper ?
[05:04] <mdz> kagou: dapper
[05:05] <kagou> it's strange because i'v seen that libgnomecups or cups delete this ~/.lpoptions and create ~/.cups/lpoptions
[05:06] <kagou> mdke, if you create this file by hand, be sure to do this in ~/.cups/
[05:06] <kagou> sorry mdke , i mean mdz 
[05:06] <mdz> kagou: I have a ~/.lpoptions
[05:06] <iwj> mdz, pitti: I wanted to draw your attention to https://lists.ubuntu.com/archives/ubuntu-devel/2006-June/018506.html, about Firefox 1.0.8 and security support for it in Breezy.
[05:07] <iwj> I would have CC'd you but then you'd get a mailbox full of `courtesy' copies so I thought I'd ping you on IRC about it instead.
[05:07] <giftnudel> mdz: setting pagesize to A5 chops off the edges of the document
[05:08] <giftnudel> mdz: setting 4-1 doesn't do anything for me
[05:09] <pitti> mdz: doesn't work in breezy either
[05:10] <kagou> mdz, may be you have created by hands ~/.lpoptions , but use g-c-m to change default printer and default parameters, and your ~/.lpoptions will be deleted and re-created in ~/.cups/lpoptions
[05:10] <mdz> kagou: I have not
[05:10] <mdz> pitti: the patch looks sane to me
[05:11] <pitti> iwj: please note that it is possible to get split-out patches for 1.5.0.4 in mozilla's bugzilla and backport them one by one
[05:11] <kagou> mdz, do you use g-c-m or kdeprint or ... ?
[05:11] <pitti> iwj: upstream offered that vendors can even use the tags and other stuff for coordinating backporting
[05:12] <pitti> kagou, mdz: ~/.lpoptions is the old location, it was deprecated in favor of ~/.cups/lpoptions at some point; this is entirely unrelated to 34112, though
[05:12] <Kamion> iwj: s/Breezy/Hoary and Breezy/g, at least for the next six months. :-(
[05:12] <Kamion> well, no, I guess it's just over four months now
[05:12] <pitti> bah, Ctrl-W does *not* delete a word in xchat, sorry
[05:13] <iwj> Kamion: OMG, hoary too ?  I haven't even _looked_ at hoary's firefox.  I dread to think.
[05:14] <iwj> pitti: Yes, but that's not really the problem.  Split out patches is all very well but the real difficulty is the bugs we don't hear about and the ones where the code is all changed around.
[05:14] <kagou> pitti, i know  that :) but mdz say that he have ~/.lpoptions and no  ~/.cups/lpoptions so it's a bug because using g-c-m DELETE ~/.lpoptions and create ~/.cups/lpoptions (tested here)
[05:14] <Kamion> Hoary is supported until <counts on fingers> 8 October 2006.
[05:14] <Kamion> also, top tip for console web browsing, 'ssh lists.ubuntu.com/archives/ubuntu-announce/' isn't useful.
[05:14] <iwj> pitti: Also, we _know_ that their processes are hopeless so why would we think that their split out patches correspond to anything when the `security and stability' release with published release notes doesn't ?
[05:14] <pitti> iwj: it'll just help to sort out the security relevant ones from all the other stuff
[05:15] <pitti> iwj: true that
[05:15] <iwj> pitti: Yes, but what about the security relevant ones they forgot to list in the changelog ?
[05:15] <iwj> I really think our best bet is to follow the herd here.  At least that way most of the jungle will have been trampled by other people.
[05:15] <pitti> iwj: right, upstream said that vendors might need to fish them out and mark as 'blocking-1.0.9' themselves
[05:15] <Kamion> mozilla-firefox | 1.0.2-0ubuntu2 |         hoary | sparc
[05:15] <Kamion> mozilla-firefox | 1.0.2-0ubuntu5 |         hoary | source, amd64, i386, ia64, powerpc
[05:15] <iwj> Urgh.
[05:15] <Kamion> mozilla-firefox | 1.0.7-0ubuntu0.1 | hoary-security | sparc
[05:16] <Kamion> for the record
[05:16] <Kamion> mozilla-firefox | 1.0.8-0ubuntu5.04 | hoary-security | source, amd64, i386, ia64, powerpc
[05:16] <kagou> must go to the crib. see you later 
[05:16] <jsgotangco> man
[05:16] <Kamion> hoary-security seems close to breezy-security, since we dumped 1.0.8 in there
[05:16] <pitti> yes, indeed
[05:16] <pitti> even warty has 1.0.8 in -security
[05:16] <Kamion> but obviously all the locales stuff and extensions would need to be fudged if upgrading to 1.5
[05:16] <pitti> right
[05:17] <Kamion> probably differently
[05:17] <pitti> and all the gtkmozembed stuff, like epiphany, yelp, etc.
[05:17] <iwj> pitti: Really ?  The API is so different ?  I thought it was quite narrow.
[05:17] <pitti> upgrading hoary and breezy to tbird 1.5 might be reasonably easy
[05:17] <iwj> I haven't tried it, it's true.
[05:17] <pitti> mozilla might hurt in hoary
[05:17] <pitti> but ffox is really painful
[05:18] <iwj> If it's a question of having to rebuild epiphany et al then it's trickier.
[05:18] <pitti> iwj: but my gut feeling is that it's still the least of all evils...
[05:18] <iwj> I really don't fancy trying to cherry pick patches out of a swamp.  They're likely to be rotten.
[05:18] <pitti> iwj: it's not only cherrypicking, the 1.5 codebase changed significantly
[05:18] <iwj> Quite.
[05:19] <pitti> which also implies that few people will continue to audit 1.0.x
[05:19] <pitti> i. e. most of the 1.0 vulnerabilities will never even be known in the future
[05:19] <pitti> iwj: just to get an idea, let's try to build the dapper firefox on breezy and see how much breaks
[05:20] <iwj> pitti: That's a good idea.
[05:20] <iwj> I've got a breezy here somewhere, let me dig it out.
[05:20] <pitti> iwj: I have chroots, I can try it here, too
[05:20] <pitti> having two people try it can't hurt
[05:21] <pitti> (oh, I have an installed breezy here, too)
[05:21] <iwj> egrep . /media/hda*/etc/lsb-release 
[05:21] <iwj> There's one, hda4.
[05:22] <iwj> Urrr.  It seems a bit busted.
[05:23] <giftnudel> iwj: never touched since release?
[05:23] <iwj> No, worse, I think I must have done some destructive test in it.
[05:23] <iwj> Oh, well, reinstalls are quick :-).
[05:24] <pitti> mdz: sorry for getting offline due to rebooting; did you already decide about 34112, or do you want to wait for more feedback?
[05:24] <mdz> pitti: the patch looks sane to me
[05:25] <pitti> iwj: 1.5.0.3 breezy build is running here
[05:28] <pitti> mdz: yes, it's not really a bug fix, but the missing glue between the dialog and cupsAddOption()
[05:28] <lemsx1> hello all
[05:29] <lemsx1> infinity: ping
[05:29] <lemsx1> infinity: that problem with libgcc_s.so.1 i was having was because -lgcc_s wasn't in the compile flags :-) just for future reference
[05:31] <bddebian> Hello lemsx1
[05:40] <mdz> mvo: update-notifier is still reminding me about language pack organization
[05:50] <bSON> hi
[05:50] <bSON> does ubuntu have any strategy concerning easy third-party installation?
[05:53] <siretart> bSON: see https://wiki.ubuntu.com/ThirdPartyPackages and https://wiki.ubuntu.com/ThirdPartyApt
[05:53] <pitti> mdz: so, fine to upload libgnomeprint?
[05:55] <bSON> siretart: thanks
[05:58] <bddebian> mdz: So, what do you have for me? ;-)
[06:04] <mdz> pitti: yes
[06:04] <mdz> bddebian: pardon?
[06:05] <bddebian> mdz: You said to talk to you so what do you want me to do? ;-P
[06:07] <mdz> bddebian: what I said was that I was available to help you if you had any difficulty in getting your packages reviewed and uploaded
[06:07] <bddebian> :)
[06:09] <iwj> Hmm, this new Breezy install's grub is broken.
[06:14] <Keybuk> . o O { I wonder what would happen if I uploaded udev without udevplug? }
[06:20] <Kamion> Keybuk: the installer would temporarily break, but possibly who cares ...
[06:20] <Kamion> what else calls udevplug? initramfs-tools I guess
[06:21] <Keybuk> that's what I'm just trying to find out
[06:21] <Keybuk> casey needs more CPUs ;P
[06:21] <Keybuk> or, probably, better IO
[06:25] <Kamion> I think all the udevplug calls in d-i are consolidated into update-dev in di-utils now, and upstream I've made that call udevtrigger/udevsettle if available
[06:25] <Keybuk> ok
[06:25] <Keybuk> that's my vague plan
[06:25] <Keybuk> port our udevplug extras into udevtrigger
[06:26] <Keybuk> I could ship udevplug as a small shell-script if something uses it and doesn't fall back to udevtrigger
[06:26] <Keybuk> e.g.
[06:26] <Keybuk> udevtrigger "$@"
[06:26] <Keybuk> exec udevsettle
[06:36] <eXistenZ> Any cups developer?
[06:37] <ivoks> maintainers?
[06:37] <eXistenZ> yeah
[06:38] <eXistenZ> when will cups be upgraded?
[06:38] <ivoks> yup, what's on your mind?
[06:38] <ivoks> eXistenZ: to 1.2.1?
[06:38] <eXistenZ> yep
[06:39] <eXistenZ> ivoks, I still cannot use my printer because of a bug in cups =/
[06:39] <ivoks> well, that's what we are disscusing now
[06:39] <eXistenZ> ivoks, I'm waiting for the next version
[06:39] <ivoks> eXistenZ: does 1.2.1 works for you?
[06:39] <eXistenZ> Where can I get it from?
[06:39] <ivoks> no where
[06:39] <eXistenZ> I believe it should've been fixed by 1.2.1
[06:39] <ivoks> eXistenZ: what printer is that?
[06:39] <ivoks> did you fill bug report?
[06:40] <eXistenZ> ivoks, It is on a windows xp system, (HP DeskJet 710C)
[06:40] <highvoltage> mvo: ping
[06:40] <eXistenZ> ivoks, there is already a bug filed.
[06:40] <mvo> highvoltage: pong
[06:40] <ivoks> eXistenZ: on windows?
[06:40] <ivoks> eXistenZ: so, this has to do with samba, right?
[06:40] <highvoltage> mvo: who's the developers of gnome-app-install?
[06:41] <eXistenZ> ivoks, nope, with some of the drivers.
[06:41] <eXistenZ> ivoks, let me show you the bug
[06:41] <mvo> highvoltage: that would be me I guess
[06:41] <highvoltage> mvo: cool. any chance of changing the wording of "Show commercial applications"?
[06:42] <ivoks> eXistenZ: bug numer would be enough
[06:42] <highvoltage> it kind of implies that proprietary software is commercial, and free software not. i think it adds confusion to new users of free software.
[06:44] <mvo> highvoltage: see bug 44925
[06:44] <Ubugtu> Malone bug 44925 in gnome-app-install "proprietary != commercial" [Medium,Confirmed]  http://launchpad.net/bugs/44925
[06:44] <eXistenZ> ivoks, This is from the cups error log: http://pastebin.com/765514 . I believe it is similar to the bug no. 45099
[06:44] <ivoks> eXistenZ: i'm aware of 45099
[06:44] <eXistenZ> ivoks, Can you please check out the error from my cups log
[06:45] <ivoks> eXistenZ: did you, as i have proposed, change driver to raw/queue?
[06:45] <eXistenZ> ivoks, Let me try
[06:46] <janderso> [sorry if this is the wrong place to ask this]  why are ubuntu-desktop, ubuntu-standard, and ubuntu-minimal separate, rather than higherarchically dependent?
[06:47] <eXistenZ> ivoks, why the right driver of the printer doesn't work?
[06:47] <ivoks> eXistenZ: does raw works?
[06:49] <ivoks> janderso: so you can remove evms, but still have ubuntu-desktop :)
[06:49] <eXistenZ> ivoks, nope =/
[06:49] <ivoks> eXistenZ: your problem has nothing to do with 45099
[06:49] <ivoks> eXistenZ: 45099 is a IPP problem, windows, atm, don't do IPP sharing
[06:50] <ivoks> eXistenZ: how is that printer shared from windows?
[06:50] <ivoks> eXistenZ: over SMB?
[06:50] <janderso> ivoks: I guess my main question is, why do I need ubuntu-minimal and ubuntu-standard if I have ubuntu-desktop?
[06:51] <eXistenZ> ivoks, I'm not sure. But I have a windows xp OS here, and I can print well.
[06:51] <ivoks> janderso: ubuntu-minimal installs set of some must have and some good to have apps
[06:51] <ivoks> janderso: you can remove it if you want
[06:52] <ivoks> janderso: i.e, if you don't want memtest86+, you can remove it
[06:52] <eXistenZ> ivoks, After I install my printer, then I check its properties. I find out that there are no username or password, although I've set them up in the settings while configuring the printer.
[06:52] <ivoks> janderso: but sill have ubuntu-desktop
[06:52] <ivoks> eXistenZ: that's a known bug
[06:52] <eXistenZ> ivoks, Is there a fix/workaround to this bug?
[06:52] <ivoks> eXistenZ: can you print from remote windows to that printer?
[06:53] <eXistenZ> ivoks, 
[06:53] <ivoks> eXistenZ: not that i'm aware of, could you paste log from your error_log with raw as printer driver?
[06:53] <eXistenZ> ivoks, yes
[06:54] <eXistenZ> ivoks, sure
[06:54] <eXistenZ> ivoks, it shows nothing other than the known: E [07/Jun/2006:19:54:16 +0300]  cupsdAuthorize: Local authentication certificate not found!
[06:54] <ivoks> ok
[06:55] <eXistenZ> ivoks, I wonder whether you can take remote desktop
[06:55] <ivoks> i'm not help service :)
[06:55] <eXistenZ> ivoks, Alright. I am not sure that it is something wrong that I did.
[06:55] <eXistenZ> ivoks, because it worked wonders in breezy
[06:56] <eXistenZ> ivoks, anyways, it is your own volition.
[06:56] <ivoks> smb://username:password@machine/printer_share
[06:56] <ivoks> that's syntax, you did it like that?
[06:56] <janderso> ivoks: this _is_ a development issue, though: when I removed ubuntu-standard and ubuntu-minimal, I lost pcmcia-utils, and my pcmcia network cards stopped working
[06:57] <janderso> ivoks: I had to go back and install pcmcia-utils myself; shouldn't that be a part of ubuntu-desktop?
[06:57] <eXistenZ> ivoks, I try that, but nothing happens
[06:58] <ivoks> janderso: err... removing ubuntu-standard and -minimal does not remove pcmciautils
[06:58] <ivoks> janderso: you have removed it by your self
[06:58] <ivoks> eXistenZ: ok
[06:59] <eXistenZ> ivoks, Want to see the error when I configure my printer with the right configuration?
[06:59] <ivoks> eXistenZ: i saw it
[06:59] <janderso> ivoks: well, no; but I used deborphan to remove packages that were dependencies of ubuntu-minimal and ubuntu-standard (which I had removed) but not ubuntu-desktop (which remained on the system)
[06:59] <ivoks> eXistenZ: fill a bug on LP
[06:59] <janderso> ivoks: my point is, I think that pcmciautils should be a dependency of ubuntu-desktop
[06:59] <ivoks> janderso: deborphan isn't AI
[07:00] <ivoks> it's very simple tool
[07:00] <eXistenZ> ivoks, I filled a bug, and it was removed as a duplicate for that 40599 bug
[07:00] <ivoks> if nothing depends on it - remove it
[07:00] <ivoks> janderso: you see that it would remove almost all tools :)
[07:01] <ivoks> eXistenZ: oh, i see...
[07:01] <ivoks> eXistenZ: i'll fix that
[07:01] <janderso> ivoks: I know, I'm not blaming deborphan. I'm just wondering why ubuntu-desktop doesn't depend on pcmciautils
[07:01] <bddebian> Is there a way to get reverse build-depends like apt-cache rdepends?
[07:02] <eXistenZ> ivoks, Can I get 1.2.1 from somewhere & try it?
[07:03] <bSON> hi
[07:03] <ivoks> eXistenZ: fixes for 1.2.1, regarding this bug were implemented in our 1.2.0
[07:03] <ivoks> eXistenZ: i doubt it will help you, but soon there will be new cups packages
[07:03] <ivoks> eXistenZ: when we finish them, i'll let you now and you could test them
[07:03] <ivoks> eXistenZ: ok?
[07:03] <eXistenZ> ivoks, it is so irritating to move to windows each time I want to print a document
[07:04] <ivoks> eXistenZ: yeah, i know... it's a bug, and we'll try to fix it, don't worry
[07:04] <bSON> can anybody package a new version of compiz? (the last one not using glx 1.3 and therefore works with the actual version of dapper's libs)
[07:05] <ivoks> bSON: that will not happen for dapper
[07:05] <bSON> when does edgy eft development start?
[07:05] <Keybuk> bSON: october :)
[07:05] <Keybuk> we add two days every time someone asks
[07:05] <Keybuk> and that many people have asked!
[07:05] <bSON> oh
[07:06] <crimsun> Keybuk: wow, nice vacation ;)
[07:06] <fabbione> crimsun: you wish :)
[07:06] <mdz> crimsun,pitti: is it worth revisiting polypaudio for edgy?  it seems to be revived
[07:06] <bSON> thats important, now that dapper is no exciting everything-can-change beta more ;)
[07:07] <crimsun> mdz: hmm, it does "suck less" than esd. Will need to read up on it now.
[07:07] <eXistenZ> ivoks, Is it that difficult to put new versions of cups into a package?
[07:07] <ivoks> eXistenZ: fixes from 1.2.1 will get backported to our cups package
[07:08] <ivoks> some of them allready are
[07:09] <pitti> mdz: I heard about it, but TBH I would rather get rid of esd entirely instead of reintroducing a sound daemon
[07:10] <mdz> pitti: until all apps use alsa, I don't see how we can avoid a sound daemon
[07:11] <Kinnison> pitti: are you advocating alsa+dmix or something?
[07:11] <froud> Are there any apps going into dapper that still have no documentation?
[07:11] <pitti> Kinnison: at least to the extend we have in dapper
[07:11] <pitti> mdz: right
[07:11] <pitti> mdz: and esound is dead anyway
[07:11] <bluefoxicy> what does enlightenment use these days
[07:11] <Keybuk> mdz: btw, can we really _not_ revisit network-manager for edgy
[07:12] <Keybuk> it's on your EdgyIdeas page; and I just cannot see it being sufficiently more mature in four months time than it is now
[07:13] <mdz> Keybuk: do we have another answer for WPA or switching wireless networks? that's all I really care about
[07:13] <Keybuk> mdz: wpa can be set through /e/n/i -- and there's the usual gnome applet for switching wireless networks
[07:14] <bluefoxicy> mdz:  someone really needs to get WPA into network-admin, but I don't think anyone's around that wants to code it
[07:14] <bluefoxicy> Keybuk: I'm pretty sure you can point-and-click through wireless networks through network-admin configuration applet ... were you speaking of a panel applet that does this as well?
[07:15] <mdz> Keybuk: since when does the gnome applet switch wireless networks?  I thought it just launched the awful network config tool
[07:16] <ivoks> fwiw, /me likes NM
[07:16] <ivoks> :)
Me too</aol>
[07:17] <Keybuk> dunno, people keep telling me they switched through the panel applet and it broke n-m
[07:18] <bluefoxicy> I haven't used NM TBH.  If you can do all the configuration through NM that you can through network-admin, maybe you should consider replacing network-admin.  I just don't personally think there should be 2 config applets to screw with the same thing.
[07:20] <bluefoxicy> ... why am I talking?  *goes to play a playstation game*
[07:24] <eXistenZ> ivoks, how can I restart cups? what is its process name?
[07:24] <ivoks> eXistenZ: sudo /etc/init.d/cupsys restart
[07:26] <bluefoxicy> pitti:  Edgy is using gcc 4.1 right?
[07:27] <ivoks> there is no edgy :)
[07:27] <sivang> at least not yet :)
[07:27] <ivoks> edgy is a myth
[07:27] <ivoks> an urban legend
[07:27] <bddebian> hehe
[07:28] <jjesse> does that mean i shouldn't have changed my sources.list from dapper to edyg yet :)
[07:28] <bluefoxicy> you guys know what I mean -.-
[07:28] <bddebian> Anyone know how Scribus determines it's default font?
[07:28] <fabbione> jjesse: none of us will change to edgy for the next 3 weeks. 
[07:29] <fabbione> because we know it's broken and it will break a lot
[07:29] <eXistenZ> ivoks, what is the mode of files which everyone can see?
[07:29] <eXistenZ> ivoks, 777?
[07:29] <jjesse> fabbione: i was being sarcastic ;)
[07:29] <fabbione> jjesse: i am not :)
[07:29] <ivoks> eXistenZ: 555
[07:29] <zul> Keybuk: thats another two days..
[07:30] <ivoks> eXistenZ: 555 for dir, 444 for files
[07:30] <bluefoxicy> I am rather certain attempting to PIE everything will be a pain in the ass ;)  A good bit breaks from it and then you have to disable pie specifically for those packages
[07:30] <bddebian> fabbione: Think it would be worth trying to "fix" any packages using xmkmf for Edgy?  (I.E. not have them use xmkmf?)
[07:30] <Keybuk> zul: it'll be November before infinity wakes up
[07:30] <bluefoxicy> (PIE only affects main executables, not libraries)
[07:30] <bddebian> hehe
[07:30] <bluefoxicy> the other two should be minimally intrusive
[07:30] <fabbione> bddebian: i am not an X maintainer anymore...
[07:30] <bddebian> WHAT?
[07:30] <bddebian> Doh :-(
[07:30] <zul> wohoo!
[07:31] <bddebian> fabbione: Who is going to maintain X?
[07:31] <ivoks> bddebian: xorg :)
[07:32] <fabbione> for once i won't need to go around trying to hide with my ninja/jedi skills from upset users
[07:32] <bddebian> heh
[07:32] <fabbione> bddebian: <sarcastic answer>I can't care less</sarcastic answer>
[07:32] <bddebian> *sigh*
[07:33] <ivoks> why does everybody wants to go with edgy? dapper is a great release
[07:33] <fabbione> ivoks: it's already 6 days old!
[07:33] <ivoks> do people like to have broken X or kernel?
[07:33] <jjesse> they are bored with it already?
[07:33] <Keybuk> you guys are SO BEHIND
[07:33] <bddebian> hehe
[07:33] <ivoks> :)
[07:33] <ivoks> Keybuk: tell us, tell us, is it broken? :)
[07:34] <Keybuk> ivoks: yes :p
[07:34] <ivoks> oh, no... i want some edgys! :)
[07:34] <eXistenZ> ivoks, I sent a reply. Can you please check whether the files open?
[07:34] <bddebian> ivoks: I don't necessarily want to run it yet, just trying to line up some tasks to make myself "useful" since apparently I'm useless so far :-)
[07:34] <bluefoxicy> ivoks:  I am hoping to get Xorg 7.1 (working 3D driver maybe...), stack smash protection, and maybe (on a huge long shot) PIE.
[07:34] <ivoks> eXistenZ: i won't be fixed today :)
[07:34] <eXistenZ> ivoks, I know. Just check whether you can open them.
[07:35] <ivoks> bddebian: nag, nag... you are allways useless :)
[07:35] <eXistenZ> ivoks, I don't know whether I correctly set the mode.
[07:35] <bddebian> ivoks: I know
[07:35] <ivoks> i'll be rolling out dapper on server like ford did T-Model :)
[07:37] <ivoks> eXistenZ: reply to what? there's nothing on 48173 yet...
[07:39] <bddebian> pitti: ping?
[07:40] <eXistenZ> ivoks, I sent you an email
[07:40] <eXistenZ> ivoks, Do you mean you want me to attach files to the bug reply?
[07:41] <ivoks> eXistenZ: https://launchpad.net/distros/ubuntu/+source/cupsys/+bug/48173/+addattachment
[07:41] <Ubugtu> Malone bug 48173 in cupsys "Printing on remote Windows shared printer doesn't work" [Medium,Confirmed]  
[07:42] <eXistenZ> ivoks, Shall I compress the files?
[07:42] <ivoks> don't compress cupsd.conf and printers.conf
[07:42] <ivoks> error_log... well, if it's too big...
[07:42] <eXistenZ> ivoks, Can I add more than one attachment for one thread?
[07:43] <ivoks> eXistenZ: no, add each individualy
[07:43] <sivang> Keybuk: so can I dist-upgrade already? ;-)
[07:44] <Keybuk> sivang: no point
[07:44] <Keybuk> no changes in the archive
[07:45] <sivang> ah
[07:45] <bddebian> Keybuk: Well get merging man! :-)
[07:45] <Keybuk> bddebian: first we need a toolchain
[07:46] <Keybuk> which is what broke when I installed it
[07:46] <bddebian> Doh
[07:46] <Keybuk> well, leaned in an unpleasant way
[07:47] <Tonio_> hi all
[07:47] <bddebian> Heya Tonio_
[07:48] <eXistenZ> ivoks, ok, done. ;-)
[07:49] <ivoks> eXistenZ: ok, i see it
[07:50] <eXistenZ> ivoks, Do you know why I'm not allowed to give wiki.ubuntu.com/Existenz , but rather Existenz2?
[07:51] <eXistenZ> ivoks, Some other user has taken it, although my user is eXistenZ, anyways.
[08:11] <eXistenZ> Will vim7 be added to the dapper repos?
[08:11] <tseng> no.
[08:13] <mdz> eXistenZ: it can potentially go into dapper-backports
[08:17] <bddebian> Heya tseng
[08:26] <pitti> bddebian: pong
[08:26] <bddebian> pitti: You do Scribus?
[08:26] <pitti> bddebian: never touched it
[08:28] <bddebian> Oh duh, I saw your name as creator and thought it was Maintainer, sorry
[08:34] <ogra> pitti, you must have touched it if your name is in the crator field :)
[08:34] <ogra> *creator
[08:35] <ogra> bddebian, scribus is in main because of edubuntu, so that'd be the edubuntu development team (which is me in fact)
[08:35] <pitti> bddebian: oh god, I just fixed the .desktop file for langpack support
[08:36] <ogra> pitti, there is a bug open about the creator wording
[08:39] <bddebian> pitti: :-)
[08:39] <bddebian> ogra: Do you know how it determines it's default font?
[08:40] <ogra> bddebian, QT i think
[08:42] <bddebian> Well it's picking some weird ass font that breaks stuff :-)
[08:43] <bddebian> Bug #45565
[08:43] <Ubugtu> Malone bug 45565 in scribus "Can't enter text into textboxes in any way" [Critical,Confirmed]  http://launchpad.net/bugs/45565
[08:47] <ogra> well, looks like upstream works on it so we'll get the fix in edgy
[08:53] <eXistenZ> ivoks, Is it a general or specific problem? what can I/we do about it?
[08:58] <ogra> mdz, any word on the g-s-s upload ? 
[08:59] <mdz> ogra: ?
[08:59] <ogra> i dont see it on -changes
[08:59] <Keybuk> where did you upload it to?
[08:59] <Keybuk> when did you upload it?
[08:59] <Keybuk> was it approved?
[08:59] <Keybuk> who approved it?
[08:59] <ogra> yesterday dapper-updates
[08:59] <Keybuk> when did you get approval for it?
[09:00] <ogra> and mdz asked for the upstream changelog
[09:01] <ogra> Keybuk, no it apparently wasnt approved yet, thats why i pinged mdz ;)
[09:01] <mdz> ogra: no one is notified when a new package lands in unapproved
[09:02] <ogra> mdz, well, since you asked for the changelog i thought you'd still look at it
[09:04] <Keybuk> (and half of gnome appears to be unapproved, currently)
[09:06] <ogra> whee
[09:08] <shadeofgrey> hello everyboidy
[09:08] <highvoltage> hello shadeofgrey 
[09:09] <shadeofgrey> i just did a fresh install of ubuntu using the new 6.06 installation CD and i love the fact that you integrated the livecd in with the installation system, so that people can test stuff and then immediately do an install
[09:09] <shadeofgrey> but i have a pretty complicated question...
[09:10] <shadeofgrey> my full ubuntu installation now resides on my primary disk -- hda -- but i have a previous installation of it on sda -- my third harddrive and i was just wondering what the best method for removcal of the old system is
[09:10] <shadeofgrey> do i just use the drives portion of the system --> administration disk panel and format?
[09:42] <Kamion> eXistenZ: the vim7 packaging has changed a fair bit, so personally I think it'll be a hard job to backport sanely, but fortunately not my problem ...
[09:42] <tseng> Kamion: it builds clean on dapper
[09:42] <eXistenZ> Kamion, Do you imply that you use emacs? :-)
[09:42] <tseng> Kamion: but i am still not an advocate
[09:43] <tseng> (of backports on the archive in general)
[09:43] <Kamion> tseng: sure, but it builds a different set of packages :) so upgrade fun
[09:43] <Kamion> eXistenZ: no, I use vim
[09:43] <tseng> oh, yeah
[09:43] <tseng> have to fight with apt a bit
[09:43] <eXistenZ> Kamion, do you use vim6?
[09:43] <tseng> I do, fwiw
[09:44] <Kamion> actually, it might not be a different set of packages, could be wrong there
[09:44] <Kamion> eXistenZ: on some machines, vim7 on others; that's not especially relevant though
[09:44] <ivoks> urgh...
[09:45] <ivoks> pitti: ping
[09:45] <ivoks> anyone around with windows? :)
[09:45] <Keybuk> yeah, they're all open though because it's hot outside
[09:45] <Keybuk> I have a couple of doors too
[09:45] <eXistenZ> ivoks, I can switch to windows.
[09:45] <ivoks> eXistenZ: but i know your printer doesn't work on linux
[09:45] <ivoks> Keybuk: this is serious :)
[09:46] <Chipzz> Kamion: http://johan.kiviniemi.name/ubuntu/dists/dapper/
[09:46] <Keybuk> ivoks: which version of Windows?  which architecture?
[09:46] <ivoks> Keybuk: XP, if you have it on UltraSPARC, that would be fine :)
[09:47] <Keybuk> XP or XP64?
[09:47] <_ion> One might want to use the mirror at http://hassers.fi/ubuntu/dists/dapper/, as it's behind a 99x faster connection.
[09:47] <ivoks> Keybuk: i just want to see can you/someone_else print from dapper to windows
[09:47] <ivoks> Keybuk: i think that's irrelevant
[09:48] <Keybuk> ah, windows is on my dapper machine, so I couldn't test that
[09:48] <Keybuk> sorry
[09:48] <ivoks> np
[09:48] <ivoks> i'll find another victim :)
[09:50] <Kamion> Chipzz: don't need it, thanks :)
[09:50] <eXistenZ> ivoks, Are you sure the problem is in gs-esp?
[09:51] <Kamion> I generally have very little interest in bothering with backports, except in cases where I have enough activation energy to just do the job myself
[09:51] <ivoks> eXistenZ: ATM, yes
[09:51] <ivoks> eXistenZ: but that could change... :)
[09:52] <bddebian> What is the determining factor if something should be fixed in -updates, -backports, or just done in Edgy?
[09:52] <eXistenZ> haha, nice.
[09:52] <eXistenZ> ivoks, installing a newer version might help?
[09:52] <ivoks> eXistenZ: there's no newer version
[09:53] <ivoks> hm, it works ok
[09:53] <ivoks> eXistenZ: mine deskjet 940c works ok
[09:54] <eXistenZ> ivoks, network printer?
[09:54] <bddebian> mdz: Still around?
[09:54] <ivoks> eXistenZ: yes, shared on windows via smb
[09:54] <eXistenZ> ivoks, Does it help if I get the printer and attach it to this computer?
[09:54] <ivoks> eXistenZ: could you do apt-get --force-all --purge gs-esp
[09:54] <ivoks> eXistenZ: and then apt-get install gs-esp
[09:55] <ivoks> eXistenZ: yes, but try this first
[09:55] <Kamion> bddebian: -updates needs to be reasonably safe, obvious, reviewable-by-humans-without-going-insane, and address known bugs
[09:55] <eXistenZ> ivoks, force-all?
[09:55] <ivoks> eXistenZ: yes
[09:55] <Kamion> bddebian: other stuff should go to edgy, and may later be pulled into -backports by the backports team if there's significant demand for the newer upstream version (generally features)
[09:55] <eXistenZ> ivoks, "--force-all is not understood"
[09:56] <mdz> bddebian: yes
[09:56] <ivoks> eXistenZ: ah, sorry, dpkg --force-all --purge
[09:56] <bddebian> mdz: Have a minute or are you busy?
[09:56] <mdz> bddebian: (if it was about your question, Kamion answered as I would have)
[09:56] <mdz> bddebian: what can i do for you?
[09:56] <bddebian> mdz: It's more general but I won't bother you if you don't have time
[09:57] <mdz> bddebian: what is your question?
[09:58] <bddebian> I would rather ask in /query if you are not opposed
[09:58] <eXistenZ> ivoks, same =/ didn't work
[09:59] <ivoks> ok
[09:59] <ivoks> same error?
[09:59] <eXistenZ> ivoks, I'll get my printer here. I'll check whether it is a network problem or a gsp-esp problem
[09:59] <ivoks> eXistenZ: the thing is that gs-esp dies
[09:59] <ivoks> eXistenZ: but that can be due lots of things...
[09:59] <eXistenZ> ok
[10:00] <eXistenZ> brb
[10:01] <eXistenZ> ok, here is the printer :] 
[10:06] <eXistenZ> ivoks, I got the same problem
[10:06] <ivoks> you see...
[10:07] <ivoks> eXistenZ: do you have ubuntu-desktop package installed? is this a breezy -> dapper upgrade or fresh dapper instalation?
[10:07] <eXistenZ> ivoks, fresh; very fresh.
[10:07] <eXistenZ> I'm going to get a new laser printer soon anyways
[10:08] <ivoks> ok
[10:08] <eXistenZ> maybe that will fix it
[10:08] <ivoks> eXistenZ: but that'll not solve issues for other people
[10:08] <eXistenZ> ivoks, I'm ready to give you anything that might help fix this problem.
[10:09] <tritium> Against what should a bug be filed for vga settings via F4 selection not being preserved after live session on desktop install CD?
[10:09] <ivoks> eXistenZ: there's nothing else i need
[10:09] <ivoks> eXistenZ: error_log clearly says gs-esp dies
[10:10] <ivoks> eXistenZ: now i just need time to figure out why :)
[10:12] <Kamion> tritium: you mean after installation?
[10:12] <mjg59> tritium: Either gfxboot or ubiquity
[10:12] <mjg59> I'd guess, but kamion will know better
[10:12] <Kamion> not gfxboot. ubiquity sounds good
[10:12] <tritium> Kamion: yes (my /boot/grub/menu.lst doesn't contain any vga= settings)
[10:13] <Kamion> but you lot made me deliberately exclude vga=
[10:13] <tritium> I had selected 1400x1050, 32 bit, during installagin
[10:13] <Kamion> because it breaks suspend/resume
[10:13] <mjg59> Ah, yes
[10:13] <Kamion> actually perhaps the right answer is to drop the option to use vga= from the live CD
[10:13] <eXistenZ> ivoks, check out: https://launchpad.net/distros/ubuntu/+source/gs-esp/+bug/38060
[10:13] <Kamion> which would be a gfxboot-theme-ubuntu bug
[10:13] <Ubugtu> Malone bug 38060 in gs-esp "es-gsp crashes on various input causing a faliure to print" [Medium,Fix released]  
[10:13] <tritium> It breaks suspend/resume?
[10:13] <Kamion> yes
[10:13] <Kamion> vga= -> vesafb -> no working resume
[10:14] <Keybuk> same reason we don't use high-res in usplash
[10:14] <mdz> is it not possible to unload vesafb later on?
[10:14] <Kamion> I was under the impression that vesafb managing to be modular at all was a bit of a miracle, let alone unloading
[10:14] <ivoks> eXistenZ: :* :* :* :)
[10:14] <tritium> Oh, interesting.  I'll have to see if that fixes one of my bugs...
[10:14] <eXistenZ> ivoks, this bug was filed before dapper
[10:15] <ivoks> eXistenZ: no, during dapper
[10:15] <mjg59> mdz: Nope
[10:15] <mdz> eXistenZ: as were thousands of others
[10:15] <ivoks> eXistenZ: install gs-gpl
[10:15] <mjg59> mdz: Right now, there's no real way of unbinding framebuffer drivers from the console
[10:15] <mdz> mjg59: the sab is very keen on a prettier usplash, maybe we could try it on desktops
[10:16] <mjg59> mdz: Still breaks suspend/resume, but arguably we care less
[10:16] <mdz> right
[10:16] <Kamion> desktops have better displays for prettiness either
[10:16] <mjg59> Kamion: Too?
[10:16] <Keybuk> prettier usplash should be easy now, I've moved all of the hardcoded stuff into a struct the .so file exports
[10:16] <Kamion> will you let me put vga= preservation back in on desktops? :)
[10:16] <Kamion> mjg59: er, yes, too
[10:17] <mjg59> I wonder how small we could get a kdrive-based splash solution
[10:17] <eXistenZ> ivoks, just install it?
[10:17] <ivoks> eXistenZ: did you?
[10:17] <eXistenZ> ivoks, yep
[10:17] <ivoks> eXistenZ: now: sudo update-alternatives --set gs /usr/bin/gs-gpl
[10:18] <ivoks> eXistenZ: and then try to print
[10:18] <Keybuk> mjg59: how would kdrive help?
[10:18] <Keybuk> avoiding fb?
[10:18] <mjg59> Keybuk: Yeah
[10:19] <mjg59> Just use vesa
[10:19] <Keybuk> what's kdrive's card support like though, I thought it was pretty bad?
[10:19] <Keybuk> though I guess if it's vesa, it's enough
[10:19] <Kamion> bogl is not exactly that big though, is it?
[10:20] <mjg59> Kamion: bogl is pretty tiny, but ties us to a framebuffer driver
[10:20] <Keybuk> bogl isn't big, but it needs framebuffer
[10:20] <eXistenZ> ivoks, doesn't work =/ Do you want to see the error_log now?
[10:20] <ivoks> eXistenZ: yes
[10:20] <tritium> Kamion: I'll not file a bug, since it was intentional, then
[10:20] <Keybuk> is there no small vesa !fb library?
[10:21] <mjg59> Keybuk: libsvga?
[10:21] <mjg59> Not sure if it actually does vesa, though
[10:21] <bddebian> Heya tritium
[10:21] <tritium> hi bddebian.  What's happening?
[10:21] <mjg59> In principle we can do it, though
[10:21] <Kamion> tritium: could you file a bug on gfxboot-theme-ubuntu about it? like I say I should probably take out that option on the live CD, since it isn't all that useful there and it causes confusion
[10:21] <bddebian> tritium: Not much thanks, you?
[10:22] <tritium> Kamion: okay, sure.
[10:22] <Kamion> though I don't think we have any possibility of being able to detect laptop vs. desktop in gfxboot
[10:22] <Kamion> so it may have to remain at least somewhat confusin
[10:22] <Kamion> g
[10:22] <Kamion> I'll leave the bug open for a while and reassign to wherever we eventually decide to fix it
[10:22] <tritium> ok
[10:22] <sladen> Kamion: just fetch the DMI and grep it (which is basically all that 'laptop-detect' does (oh, and laptop-detect looks for a battery too)
[10:23] <jdub> Kamion: so, do you know much about the ld.so.conf "removal"? was this something we inherited from debian or upstream?
[10:23] <sladen> Keybuk: I think some previous occasion you were asking about detecting amd64 vs. i386 on boot.  It's a bit (called "lm" == long mode) in the cpuid flags
[10:23] <sladen> Keybuk: so then you can do your dual mode DVD's 
[10:23] <Keybuk> sladen: the discussion was whether we could make an all-arch dvd
[10:24] <sladen> Keybuk: my reckoning was, yes.
[10:24] <sladen> Keybuk: look up "TriplePlay" on the wiki
[10:25] <eXistenZ> ivoks, here is the link: http://existenz.googlepages.com/error_log
[10:26] <sladen> Keybuk: if you ditch HFS booting on PPC and only go for HFS+ booting (which starts at +1kB) you might even get sparc+ppc to co-exist
[10:27] <sladen> Keybuk: somehow Apple have managed i386 and ppc boot on their OSX disks, so you may even get Mactel i386 on there aswell
[10:27] <mjg59> sladen: ?
[10:27] <mjg59> sladen: The OSX DVDs are per-arch
[10:28] <Kamion> sladen: patches welcome. "just" in gfxboot is never that easy
[10:28] <Kamion> jdub: absolutely no clue
[10:28] <sladen> Kamion: ?  re: detecting laptop/desktop in the boot loader?
[10:28] <Kamion> sladen: yes.
[10:29] <Kamion> sladen: it's all hand-coded assembly, and my x86 assembly is passable enough to fix minor bugs but I'm no superstar at it
[10:29] <Kamion> sladen: and it would need to export an operator to the forth-like language too
[10:29] <jdub> Kamion: i've heard a bit of (mostly pointless) whinging about it; does sarge have ld.so.conf OOTB?
[10:29] <eXistenZ> ivoks, does gpl crash also?
[10:29] <Kamion> jdub: absolutely no clue
[10:29] <Kamion> please ask somebody else with clue :)
[10:32] <Kamion> interesting that selecting vga= in the boot loader is apparently sometimes a workaround for xresprobe leaving you with a blank screen in the middle of the install
[10:32] <Kamion> (d-i)
[10:32] <mjg59> So a stripped Xvesa build is 800K
[10:33] <mjg59> But depends on freetype and some other X libs
[10:33] <mjg59> Could probably be made smaller by building against uclibc
[10:33] <Keybuk> X is a bit heavy weight?
[10:34] <mjg59> Keybuk: I'd imagine that we could probably do an X-based solution in under 2MB
[10:34] <Keybuk> mjg59: it still seems rather over-kill
[10:35] <Keybuk> 47K -> 2,048K is silly for a bit of shine
[10:35] <Keybuk> especially for the initramfs, we're near the line already on the size of that
[10:35] <mjg59> Keybuk: A quick play suggests that performance wouldn't be an issue - it comes up in well under a second
[10:36] <sladen> kdrive on vesa?
[10:36] <mjg59> As for size, well. I think that's going to end up depending on just how much Mark wants bling
[10:36] <Keybuk> mjg59: it's not performace I'm worried about -- it's the fact we can't afford to load a 10MB initramfs!
[10:36] <mjg59> Keybuk: Because?
[10:36] <Keybuk> powerpc, amongst others, has size limits
[10:36] <mjg59> Hm. Why?
[10:36] <Keybuk> not to mention how long it takes to get off disk
[10:37] <Keybuk> bootloader something-or-other
[10:37] <mjg59> powerpc is actually less of a problem, since we can have sensible fb access anyway
[10:37] <Kamion> yaboot; 6MB limit on netbooting
[10:37] <Kamion> it's quite ingrained
[10:37] <mjg59> Only on netbooting?
[10:37] <Kamion> I *believe* so but wouldn't be prepared to swear to it
[10:38] <Kamion> doesn't bigger initramfs => more memory use too?
[10:38] <Keybuk> mjg59: libsvga seems to do vesa
[10:38] <mjg59> Kamion: Only at boot time
[10:38] <Keybuk> that would be a better idea, no?
[10:38] <mjg59> Keybuk: Ok, that might be saner
[10:38] <eXistenZ> ivoks, are you there?
[10:38] <Keybuk> libvga is only 340K ... and would be a lot less with just the important bits used
[10:39] <mjg59> Keybuk: Though, presumably, requires writing of actual real vesa code?
[10:39] <Keybuk> could use the vgagl thing ... acts like a framebuffer, but entirely in userspace
[10:41] <Keybuk> that seems rather more sane in general than X :)
[10:43] <bddebian> heh
[10:45] <Keybuk> if we can get X started that early, I'm sticking gdm in it, not a splash screen <g>
[10:45] <Keybuk> or, at least some kind of login screen so when we have a real X we can start their session
[10:46] <bddebian> a real X ?
[10:46] <Keybuk> one not using vesa :p
[10:46] <bddebian> Ah :-)
[10:49] <Trewas> I asked earlier on #ubuntu but unsurprisingly no-one answered... ubiquity is mentioned to automagically install grub, but in a system with both SATA and PATA disks where it will go, /dev/sda or /dev/hda?
[10:49] <Keybuk> which did you install to?
[10:50] <Trewas> I'm only planning to install, but it would go to /dev/hda but the system boots from /dev/sda, where xp is
[10:50] <Keybuk> if you install to hda, it will go to hda I believe
[10:52] <Trewas> ok, I guess I can convince windows' boot-manager to start grub from another disk if needed
[10:52] <Keybuk> I'd do it the other way, start windows boot manager from grub
[10:52] <shadeofgrey> pardon my intrusion but the retard level in the main support channel is redlining
[10:52] <Trewas> well, that might be easier but if ubiquity does not ask where it will install grub... :)
[10:52] <shadeofgrey> all i need to know is this -- did you guys do away with the .fonts folder in each users home?
[10:53] <shadeofgrey> and how do i take a whole crapload of fonts off a CD and put them someplace where they're abailable for acertain user?  i went hunting for the .fonts dir in my home, and there isnt one...  do ijust need to create one?
[10:54] <Keybuk> shadeofgrey: this is not a support channel
[10:54] <shadeofgrey> kwy:  yes im well aware of that.  unfortunatelyt theres no supporting going on.  i wouldnt just show up here unless it was important and i couldnt fiund helping hands elsewhere
[10:54] <crimsun> shadeofgrey: I'll address that in #ubuntu
[10:55] <shadeofgrey> oh!  hi crimsun!
[10:55] <Keybuk> shadeofgrey: and if we start supporting people in here, then we will lose a channel where we can discuss development matters
[10:55] <shadeofgrey> id id seen your name i wold have asked you
[10:55] <shadeofgrey> Key:  dont get excited...  i apologise wholeheartedly fot the intrusion
[10:58] <Keybuk> back in ~30 mins
[11:00] <shadeofgrey> this will be my last stop here for the evening..  i just wanted to say taht you guys did a fabulous job integrating installation with the desktop live CD ...  everything was implimented very well and the procedure for a full install has gottren really sexy and streamlined...  id just like to take a minute and thank everybody for all their hard work
[11:01] <shadeofgrey> in my opinion, 6.06 marks ubuntu's transition from adolescent angst into mature young adult...  now all we have to do is get the kernel laid, and ...  =)
[11:01] <shadeofgrey> just kidding.
[11:02] <shadeofgrey> anyway thanks very much everybody for making ubuntu what it is..  i know its easy for we peons to forget just how much effort blood sweat and tears go into each milestone release... i was on the dapper bandwagon since flight2, and i must say.,. thi s is by far the best release yet...
[11:02] <shadeofgrey> im honestly awestruck by how far we've come since warty
[11:03] <shadeofgrey> and we'd of never have made it without you and all your support teams and such
[11:04] <shadeofgrey> anyway..  i just want you all to know that i havent forgotten you and fully appreciate the sacrifices in timeand effort that you guys and gals make willingly in the ongoing determined effort to keep ubuntu on track and totally free
[11:04] <shadeofgrey> ...ubuntu kicks fedora's ass 
[11:04] <shadeofgrey> good night all.
[11:05] <bddebian> :-)
[11:10] <eXistenZ> ivoks, still there?
[11:16] <neutrinomass> If a spec requires the development of software (http://wiki.ubuntu.com/EasyUsbAdsl), is it appropriate to start a project at SF.net as a homepage or is something else preferred ?
[11:17] <Keybuk> launchpad and bzr would probably be "preferred"
[11:19] <neutrinomass> Keybuk: Launchpad can doSVN (or CVS) and you can upload files there, right? Can you have a homepage with "The status of this project is this, we need help on that, etc." ?
[11:20] <Keybuk> neutrinomass: Launchpad can do bzr
[11:20] <Keybuk> which is our preferred version control system
[11:20] <neutrinomass> Keybuk: Ok, thanks. I'm not familiar with bzr so I'll have to look it up. :)
[11:21] <Keybuk> it does not currently offer file upload, though that would be a great wishlist
[11:22] <Kamion> not files, but you can push a bzr repository
[11:22] <neutrinomass> Hm.. is that a showstopper for hosting projects there or can people do bzr checkouts easily ?
[11:22] <Kamion> bzr get URL
[11:22] <ogra> Kamion, you can push already ? i thought it only pulls from locations i give it
[11:22] <Keybuk> ogra: you can push
[11:22] <Kamion> where URL is http://bazaar.launchpad.net/~OWNER/PRODUCT/BRANCHNAME or something along those lines
[11:22] <ogra> wow
[11:23] <Kamion> ogra: we're going to be doing the seeds that way for edgy
[11:23] <Kamion> in fact it appears to have been pushed already
[11:23] <ogra> Kamion, yes i noticed that, i didnt know that was already a public feature beyond the seeds
[11:23] <Kamion> http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.edgy/
[11:23] <Kamion> sure, we just used an already-existing feature and Scott pushed for a couple of relevant bugs to be fixed and the fixes deployed
[11:24] <Keybuk> yeah, seems the push finally went through just now
[11:24] <Keybuk> admittedly, I had to corner lifeless and tickle him until he told us the already-existing feature existed
[11:24] <Keybuk> and how to actually use it
[11:24] <ogra> cool 
[11:24] <ogra> lol
[11:24] <ivoks> eXistenZ: hey
[11:24] <eXistenZ> ivoks, great to see you back again.
[11:25] <ivoks> eXistenZ: that file is binary file
[11:25] <eXistenZ> ivoks, binary?
[11:25] <Kamion> anyway, bedtime
[11:25] <ivoks> Kamion: i agree :)
[11:25] <eXistenZ> DId I do something wrong?
[11:25] <ivoks> eXistenZ: wait a second
[11:26] <Keybuk> Kamion: I wonder what suddenly magically happened just now
[11:26] <Keybuk> Kamion: do you think we should push the warty+ seeds as well, for historical value?
[11:27] <Kamion> Keybuk: sure; I'll do it tomorrow unless you want to do it right now
[11:27] <Kamion> I have checkouts of everything
[11:27] <Keybuk> I'll probably do it, I also have checkouts
[11:28] <Keybuk> want to make sure the pushed copies are up to date while I'm at it
[11:29] <ivoks> eXistenZ: this is old log
[11:29] <eXistenZ> ivoks, it is new!
[11:29] <ivoks> eXistenZ: 20:27 is clock
[11:29] <eXistenZ> ivoks, yep
[11:29] <ivoks> eXistenZ: and it says that runing gs is esp
[11:29] <eXistenZ> ivoks, ok, let me try now
[11:30] <eXistenZ> ivoks, Using `/usr/bin/gs-gpl' to provide `gs'.
[11:30] <ivoks> eXistenZ: paste news to bug you reported
[11:30] <ivoks> eXistenZ: i'm going off now
[11:30] <eXistenZ> ivoks, ok :] 
[11:30] <ivoks> 'night all
[11:30] <eXistenZ> ivoks, it is 12:30AM here
[11:30] <eXistenZ> ivoks, I believe I should go too