[12:13] <shackan_> I know the hassle of burning a cd and rebooting, I haven't burned isos for years, always installed writing to my real disk from vmware (always without a hitch)
[12:13] <shackan_> but I install a new operating system at most a couple of times a year, how often do people try out new livecd, actually ?
[12:20] <bluefoxicy> shackan_:   What would be the overall detriment?
[12:20] <bluefoxicy> about 400-600k of space used on the livecd...
[12:21] <shackan_> it's just a lot of work (to get qvm86 into good shape) for an uncommon use case, people will just slap the cd and reboot
[12:22] <bluefoxicy> shackan_:  if I can make qvm86 run Ubuntu as-is I won't need much work.
[12:22] <shackan_> then, just do it :)
[12:29] <jdong> is feisty to adopt cdrkit instead of cdrecord?
[12:29] <jdong> apologies in advance if that's a stupid question
[12:30] <cjwatson> I believe so
[12:30] <cjwatson> it's already been synced and stuff
[12:30] <jdong> yeah, looking at my madison-lite it seems like it
[12:30] <jdong> cdrecord is being provided by cdrkit
[12:30] <jdong> cool
[12:30] <jdong> cjwatson: who is typicall in charge of the burning stuff?
[12:31] <cjwatson> we generally go with that sort of thing unless there's a particular reason not to
[12:31] <cjwatson> jdong: nobody really in Ubuntu
[12:31] <jdong> ok
[12:31] <jdong> I was just wondering if it'd be a worthwhile backport for Edgy
[12:31] <jdong> I've heard cdrkit is supposed to solve some cdrecord bugs
[12:32] <jdong> and it just built fine for edgy and I'm testing burning some ISO's at the moment
[12:32] <bluefoxicy> THE CLICKING IS PISSING ME OFF
[12:32] <cjwatson> it's a bit messy - transitional packages and stuff
[12:32] <jdong> bluefoxicy: capacitors
[12:32] <jdong> bluefoxicy: not CPU ;-)
[12:32] <bluefoxicy> jdong:  throttle someone
[12:32] <jdong> I love you too, bluefoxicy :)
[12:33] <bluefoxicy> jdong:  how's your pax kernel :)
[12:33] <jdong> bluefoxicy: vdso=0 didn't do the trick
[12:33] <jdong> but oh well
[12:33] <jdong> I should play with the options a lot more when I get a chance
[12:33] <jdong> I definitely believe it's PaX causing it
[12:33] <jdong> but even pax_softmode doesn't help
[12:33] <jdong> and I can't exactly stack trace or coredump in initramfs
[12:34] <jdong> grsecurity.... blocks dumping core because it's greater than 4096bytes
[12:34] <jdong> and btw, bluefoxicy, I have seen a case where a livecd does cause windows to fail booting up
[12:34] <jdong> as silly as it sounds
[12:34] <bluefoxicy> jdong:  nods
[12:34] <shackan_> how?
[12:35] <jdong> it happens on a lot of Dell consumer PC's when XP was first released (around that time)
[12:35] <bluefoxicy> jdong: you got time this weekend to pop in #pax?
[12:35] <jdong> windows has its special ways of shutting down the machine
[12:35] <jdong> linux doesn't do it the same way
[12:35] <jdong> if Linux does the shutdown, XP BSOD's on the next bootup
[12:36] <jdong> but another 2 or 3 boot cycles will make XP boot ok again
[12:36] <jdong> really peculiar
[12:36] <shackan_> eeek
[12:36] <jdong> but I've personally witnessed it happen
[12:36] <jdong> and it was the scariest experience
[12:36] <jdong> so keep that in mind before popping in LiveCD's everywhere :)
[12:37] <jdong> cjwatson: the transitioning requires a dist-upgrade to effect the upgrade....
[12:37] <jdong> so hmm
[12:37] <jdong> though Edgy's update-manager auto-offers dist-upgrade if a standard update can't do the trick
[12:38] <jdong> wow, update-manager does it without dist-upgrade
[12:38] <jdong> only at the CLI a regular apt-get upgrade will hold back the cdrecord stuff
[12:38] <jdong> adept handles it well too
[12:43] <jdong> requires postinst configuration too
[12:43] <jdong> ok, no cdrkit for Edgy
[12:43] <jdong> unless I get a really compelling reason
[01:35] <shawarma> infinity: Do you know anything about the IA64 buildds?
[01:37] <wasabi> so, there's an odd loop in initramfs which is bugging me. I'd appreciate a knowledgeble body  helping me pinpoint the bug. =)
[01:37] <wasabi> latest feisty, using md + lvm.
[01:37] <wasabi> During boot, it looks like, right after premount, the HD's start going into an activity loop.   lights on, lights off, lights on, lights off.
[01:38] <wasabi> If I run scripts/init-premount/udev and scripts/local-top/mdadm|lvm manually after breaking at premount, and then continue, it works.
[01:40] <Fujitsu_> wasabi: You can actually tell it to continue? I've never been able to work out how.
[01:40] <wasabi> just exit apparently.
[01:40] <wasabi> =)
[01:40] <Fujitsu_> Argh, that would have made some recovery I was doing a while ago a whole lot easier.
[01:40] <wasabi> maybe_break seems to just fork a sub shell.
[01:41] <wasabi> yeah, so I'm running the scripts in order as they're run on their own, and it works fine.
[01:41] <wasabi> I can only suspect a race.
[01:41] <wasabi> a race that somehow puts it into a neverending loop...
[01:56] <sladen> mdz: +1 for -discuss
[01:57] <sladen> *immediately* and with --force
[03:09] <psusi> is there a way to set up a batch type postinst step?  that will be done once after all packages are installed?  for something that several packages require, like update-initramfs?
[03:09] <psusi> rather than having each one do it again and again in their own postinst
[03:27] <infinity> shawarma: What do you want to know about the ia64 buildds?
[03:28] <psusi> that reminds me... is there a way to get shell access for pbuildering purposes on an ia64 server?  how about ppc?  the defrag package I updated recently failed to build on those platforms.... unfortunately, I only have amd64/i386
[03:32] <infinity> psusi: We don't have any machines acceissible for non-staff, yet.  It's on the TODO.
[03:32] <infinity> psusi: I could give you access to a PPC machine in my house, though.  Bug me on Monday?
[03:32] <psusi> ok... I'd just hate to upload the package a dozen times trying to get it to build over there
[03:32] <psusi> heh... ok
[03:40] <lifeless> psusi: someone needs to update defrag to do ext3 :(
[03:42] <psusi> lifeless, I have
[03:42] <psusi> want to be a test victim... err... volunteer?
[03:42] <psusi> ;)
[03:50] <lifeless> psusi: you have? seet.
[03:50] <lifeless> *sweet*
[03:51] <lifeless> now get ted t'so to review the patch :)
[03:55] <psusi> ahh, yea... he was one of the original authors wasn't he?
[03:55] <psusi> didn't he used to hang here?
[03:55] <lifeless> dont think so
[04:05] <psusi> hrm... is the man page for udev right or is this an error?
[04:05] <psusi> it says the key will match if the external program returns NONZERO
[04:06] <psusi> that flys in the face of convention though... nonzero means it failed
[04:06] <mjg59> Well, except for APIs where that isn't the convention
[04:07] <psusi> talking shell here, not C ;)
[04:07] <psusi> program exit()s with 0 means it worked correctly
[04:07] <psusi> and the shell treats that as TRUE
[04:07] <psusi> so it doesn't make any sense that udev would do the reverse
[04:08] <mjg59> Well, unless the applications tend to do something like return the number of matches
[04:08] <mjg59> Why don't you test it and find out?
[04:08] <psusi> I suppose I will have to
[04:55] <Chipzz> ieks
[04:56] <Chipzz> after upgrading to feisty, my c's look all weird
[05:00] <jdong> Chipzz: you mean you c a problem?
[05:00] <jdong> a ha ha ha
[05:00] <jdong> I crack myself up
[05:01] <Chipzz> jdong: no, c's are very thin, to the point of being allmost invisible
[05:02] <jdong> i c
[05:03] <Chipzz> :P
[05:03] <Chipzz> o's too apparently
[05:06] <Chipzz> jdong: http://chipzz.safehex.be/oc.png
[05:06] <Chipzz> look at the c in december, and the o in subscriptions
[05:07] <jdong> O, i C, just with the big letters
[05:07] <Chipzz> snap out of it ;)
[05:08] <jdong> Chipzz: u r acting like you haven't herd 1 or 2 bad puns around here recently ;-)
[05:08] <Chipzz> jdong: sure I have :)
[05:08] <Chipzz> but the joke got old real fast ;)
[05:09] <Chipzz> anyway, Russel Coker doesn't show the problem for some reason
[05:09] <Chipzz> seems to be a bigger problem anyway
[05:09] <Chipzz> Subscriptions is antialiassed very badly
[05:10] <Chipzz> look at the top of the S and T
[05:10] <Chipzz> any idea which package I should file a bug against?
[05:13] <Chipzz> Setting up ttf-bitstream-vera (1.10-7) ...
[05:13] <Chipzz> Regenerating fonts cache... failed; see /var/log/fontconfig.log for more information.
[05:13] <Chipzz> done.
[05:16] <Chipzz> hrrrm
[05:17] <Chipzz> apparently fontconfig problem
[05:17] <Chipzz> after reconfiguring it it's gone
[07:46] <holycow> hello
[07:46] <holycow> not sure if this is the right channel so boot me if its not
[07:46] <holycow> :)
[07:47] <holycow> is feisty looking like it will keep metacity or use something like compiz as a compositing manager?
[07:47] <holycow> just curious about aiglx + metacity and whether or not any discussion has been had around that
[07:56] <Phoenix7477> well, your in the right place i think, but its late and i think anyone who knows is probably asleep or afk :)
[07:56] <holycow> fair enough its friday, and unlike me,they have a life
[07:56] <holycow> -_-
[07:56] <Hobbsee> and it's a saturday
[07:56] <holycow> touche
[07:56] <holycow> lol
[07:57] <Phoenix7477> lol
[07:58] <superjon> Is feisty built with the new .gnu.hash improvements to speed up the linker?
[07:58] <superjon> Or *will* it be built with these improvements?
[07:59] <deltab> holycow: this? https://blueprints.launchpad.net/distros/ubuntu/+spec/composite-by-default
[07:59] <holycow> ah okay
[08:00] <holycow> oh jesus
[08:00] <holycow> beryl and compiz are actually being considered
[08:00] <holycow> lol thats what i was afraid of. 
[08:00] <holycow> k danke sir
[08:00] <holycow> deltab, appreciate that
[08:02] <Fujitsu> holycow: I don't believe they are being seriously considered any more, fortunately.
[08:02] <holycow> really? *phew*
[08:03] <holycow> would be nice NOT to become fedora i think, officially running pre alpha stuff ... heh
[08:03] <Fujitsu> A lot of people were rather... angry? ... when it was announced as a specification.
[08:04] <holycow> yeah, we are starting to weer into some uncharted territories
[08:06] <holycow> the distro for human beings i think means not using its userbase as a huge guinea pig population
[08:07] <holycow> there are distros that specialize in running very untested stuff ... some thought needs to be given to stability vs. latest and greatest
[08:07] <holycow> but thats just an opinion of a nobody at a time when there isn't anyone to read it :)
[08:08] <superjon> Yeah it is called Foresight Linux... distro that runs broken^H^H^H^H^H^H Bleeding edge code
[08:09] <holycow> heh never heard of that
[08:09] <holycow> i was thinking gentoo :) but y'know 
[08:09] <holycow> still funny
[08:11] <superjon> http://foresightlinux.com/ based on rpath's conary package manager, bleeding edge gnome+mono, etc, etc
[08:11] <holycow> wow
[08:13] <superjon> are you the same holycow that was always in #hula awhile back?
[08:14] <holycow> hey dude
[08:14] <holycow> indeed
[08:14] <holycow> :)
[08:14] <holycow> its funny you remember the nick i didn't make much noise in there
[08:14] <superjon> nice
[08:15] <holycow> i'm still keeping an eye on hula
[08:15] <superjon> well there were 2 cow users as I remember
[08:15] <holycow> i know novell stoped dropping resources on it but ya never know it could still end up being the bling
[08:15] <superjon> So am I, but they are furiously trying to work on hula-store which is a dead end
[08:16] <superjon> If they would just release a 1.0 of hula-lite, distributions would likely adopt it
[08:16] <holycow> actually that is probably some of themost sensible opinion i've heard on hula in a while
[08:16] <superjon> Who *wouldn't* want dragonfly's beautiful webmail ontop of a rock solid postfix / sa setup?
[08:16] <holycow> superjon, indeed
[08:17] <holycow> btw, if anyone cares ...
[08:17] <superjon> Alex Hudson seems to be the new "leader" from what I see in the ML, but he thinks hula-store is the way to go. Rewriting all of that is what caused campd to leave novell
[08:17] <holycow> the reason i'm asking about the metacity/aiglx stuff is because i'm piloting ubuntu at work
[08:17] <superjon> For normal desktops, or "techie" desktops?
[08:18] <holycow> normal deesktops *nod*
[08:18] <superjon> 3 people on my team of 5 run ubuntu desktops at work
[08:18] <holycow> i'm hoping NOT to hear that compiz/beryl become some sort of standard especially for the next lts
[08:18] <superjon> Well people dont quite understand what that means
[08:18] <holycow> dapper has turned out to be a seriously superb desktop
[08:19] <superjon> If beryl was used by default, it would use the heliodor window decorator which shares metacity themes and would be seriously toned down
[08:19] <superjon> No wobbly windows by default
[08:19] <holycow> its not that, its just seriously faulty software
[08:19] <superjon> The cube switcher, expose clone, dimming unresponsive windows, and minimize animations are actually more usable
[08:20] <superjon> Have you actually used a recent release?
[08:20] <holycow> no its beena while but the stuff is still what ... alpha?
[08:20] <_ion> Shadows are also nice. They actually improve usability IMO.
[08:20] <holycow> _ion, they do
[08:20] <_ion> They have matured nicely.
[08:20] <superjon> I've ran it for the past 3 months with few problems. The beryl leader, quinnstorm is solely working on bugfixing of the core
[08:20] <holycow> i think waiting to see how metacity starts handling stuff is a better strategy long term
[08:21] <holycow> we loooooove to reinvent the wheel in th eopen source world and thats fine as an experiment
[08:21] <superjon> holycow Read what Elijah Newren, the metacity maintainer says
[08:21] <holycow> but throwing out years of dev experince on metacity is kinda scary
[08:21] <holycow> okay googling
[08:21] <superjon> The guys at redhat (mainly Soren) who were doing the metacity compositor dropped it dead. They moved to compiz
[08:21] <jdub> holycow: pretty strong agreement on d-d-l that pushing it into metacity *isn't* the right thing to do
[08:21] <jdub> holycow: while most of the metacity window management rules have been lifted into compiz
[08:22] <holycow> jdub, really?
[08:22] <Hobbsee> jdub: d-d-l?
[08:22] <superjon> From what I read in the gnome mailinglist(s), compiz will likely be the longterm solution with metacity staying as a fallback and for thin clients
[08:22] <tepsipakki> desktop-devel-list
[08:22] <Hobbsee> ahhh
[08:23] <holycow> oh i see
[08:23] <holycow> hense the reference to metacity being a button / applet or checkbox or somesuch on the above linked page
[08:23] <holycow> interesting
[08:24] <holycow> jdub, thx for the heads up onthat
[08:24] <holycow> gives me a direction to watch for i think
[08:24] <superjon> jdub: Would you happen to know if feisty is being built with DT_GNU_HASH to improve the linker times?
[08:25] <tepsipakki> superjon: if that's what glibc-2.5 brings in, then yes, I suppose..
[08:26] <jdub> superjon: no idea
[08:27] <superjon> but it has to be enabled in the configure options
[08:27] <superjon> Just like -fstack_protector has to be added
[08:28] <superjon> http://www.elfenbeinturm.cc/2006/07/12/dt_gnu_hash-update/
[08:29] <superjon> http://sources.redhat.com/ml/binutils/2006-06/msg00418.html here is the actual post on it
[08:31] <Treenaks> superjon: -fstack_protector is being used by default afaik
[08:32] <superjon> Treenaks: Yes, that is correct. I was using that as an example though
[08:41] <Phoenix7477> anyone here familiar with programming in C?
[08:46] <Burgundavia> BenC: your KernelPatches page, can we talk about it in the UWN?
[08:47] <BenC> UWN?
[08:47] <Burgundavia> ubuntu weekly news
[08:47] <BenC> sure
[08:47] <BenC> is it news worthy? :)
[08:47] <Burgundavia> sounds good, thanks
[08:48] <Burgundavia> it is more "public information service" than specific news, but yes, it is news worthy
[08:48] <BenC> excellent
[08:49] <BenC> Burgundavia: I'll let you know if I create any more wiki pages out of shear frustration :)
[08:50] <Burgundavia> will do
[08:50] <Burgundavia> getting information out is one of the goals of the marketing team
[08:50] <Burgundavia> sometimes that means internally
[08:52] <superjon> BenC: Is the Feisty toolchain using DT_GNU_HASH linker improvements by default? You of all people would know this
[08:53] <BenC> no, doko and jbailey of all people would know this
[08:53] <superjon> Ok, so you don't know?
[08:53] <BenC> I've been meaning to ask them though
[08:53] <BenC> no, not off hand
[08:53] <superjon> Alright, thanks
[08:53] <BenC> np
[08:53] <superjon> I'll shoot them an email
[10:14] <shawarma> infinity: Well, I have a build that fails on ia64 (and sparc, as it turns out). The package is apcalc and it fails during regression testing. The test that fails is a check to see if file descriptor 3 is attached to a tty.. So it could either be the detection code that messes it up, or file descriptor 3 on ia64 and sparc buildd's could actually be attached to a tty. 
[10:16] <shawarma> infinity: So the question is: Is anything special being done on ia64 and sparc buildd's that could make file descriptor 3 attached to a tty?
[10:16] <shawarma> infinity: The Debian builds of it worked fine. :-/
[10:27] <Fujitsu> Is MoM not updating, or am I imagining it?
[10:27] <infinity> shawarma: There's nothing "special" about them, compared to the other arches.
[10:28] <Hobbsee> Fujitsu: i'm not sure, i just tried to do a merge and found it was already done
[10:29] <Fujitsu> Hobbsee: I've tried to do quite a number, and found they'd been done. Quite a number of syncs have been filed, and they've already been done... It's all being nice and counter-productive.
[10:29] <Hobbsee> heh
[10:30] <Riddell> infinity: do you know what the status of the digikam 1:0.9.0~rc2-0ubuntu2 build is?  it seems to have been building since yesterday on i386
[10:32] <shawarma> infinity: That's odd.
[10:32] <infinity> shawarma: The existance of that as a rgression test seems odd anyway.  Why would we care if fd3 is a tty?
[10:33] <shawarma> infinity: Oh, well, qemu can emulate a sparc, so I guess I could try doing a build in one of those.
[10:33] <shawarma> infinity: Oh, I don't think that's the purpose. I think the purpose is to check if isatty does the right thing, and it's assumed that fd 3 i not a tty.
[10:33] <infinity> Riddell: Err, it's not building, it's dep-wait.
[10:34] <Riddell> hmm.  hmm.  launchpad said it was building just a second ago
[10:34] <infinity> shawarma: Odd assumption to make, given the sorts of perverse shell tricks people like me are known to pull. :)
[10:34] <shawarma> infinity: But yes, it would seem quite odd to have a regression test that was actually testing the build environment. :-)
[10:34] <infinity> Riddell: Probably a dep-wait loop, cause it has a build-dep in universe.
[10:35] <infinity> libexiv2-dev
[10:35] <Riddell> yep, thanks
[10:35] <shawarma> infinity: Indeed. Maybe I should just change it to file descriptor 38. That should be good enough for most people. :-)
[10:35] <infinity> Riddell: Time for an MIR for exiv2.
[10:36] <infinity> shawarma: Alternately, of course, it could be that isatty is actually misbehaving.
[10:36] <Riddell> yeah, we have one, it was just for exiv2 to pass NEW
[10:36] <infinity> shawarma: Given than I can think of no reason why fd3 would be any different on ia64 and sparc than on the other arches.
[10:36] <shawarma> infinity: True. The code looks very innocent though. And if it fails on fd 38, it's *definitely* the code that's failing.
[10:36] <infinity> Riddell: Oh, there's an approved MIR already?  I can promote it, if that's the case.  (it's in universe currently)
[10:37] <Riddell> infinity: it's not been approved by pitti yet
[10:37] <infinity> Riddell: Ahh, kay.  Check.
[10:38] <shawarma> Hmm... I just got a second notice about the same build failing.. Why would that happen?
[10:39] <shawarma> Do I have to acknowledge it or something to shut it up?
[10:51] <infinity> shawarma: Because I retried it for kicks.
[10:52] <jdub> oh man
[10:52] <jdub> i'm || <- this close to turning off my ubuntu and canonical aliases
[10:52] <Hobbsee> jdub: why?
[10:52] <infinity> jdub: I'd question why you still have a canonical one anyway. :P
[10:53] <jdub> Hobbsee: horrific spammage
[10:53] <Hobbsee> ah
[11:05] <CyberT3> first_auth_command=<BEGIN_COMMAND>dhclient %i<END_COMMAND>
[11:05] <CyberT3> whats wrong with above line?
[11:36] <cjwatson> Riddell: fixed the lack of disk choice in the KDE frontend - just needed to s/disk_buttongroup\.show()/disk_frame.show()/
[11:37] <cjwatson> thanks for the help!
[11:54] <szachista_> hello
[11:55] <szachista_> i'm not sure if it's a good place for this question, but
[11:55] <szachista_> where can i report misuse of ubuntu licence?
[11:55] <szachista_> i have read on fsf site that first it should be reported to the copyright holder
[11:55] <szachista_> does it mean canonical?
[11:56] <Riddell> cjwatson: cool
[11:56] <szachista_> the case is there is oen regional distro, just created few day before, which uses packages from ubuntu repository but it licence says the whole distro is freeware
[11:56] <Riddell> cjwatson: I'm looking at porting it to qt4 just now
[11:57] <cjwatson> szachista_: I'd be inclined to mail info@ubuntu.com; most of the time that sort of thing is just a misunderstanding
[11:58] <cjwatson> they probably aren't actually breaking our licence (and note that we are only the copyright holder of parts of it), just misrepresenting it
[11:58] <cjwatson> Riddell: neat
[11:59] <szachista_> cjwatson: well, i was talking with it's author and looks like he really interprets gpl the wrong way :/
[12:00] <szachista_> cjwatson: ohh... and there is no english version for this licence for now, so is worth to write to cannonical about that?
[12:00] <cjwatson> if you can provide a reliable translation, sure
[12:01] <cjwatson> (I think there may be a better address than info@, but I don't remember what it would be ...)
[01:06] <rob> ajmitch: ping
[01:06] <StevenK> rob: He is likely sleeping, it's around 1am
[01:06] <rob> in NZ?
[01:07] <StevenK> Well, ajmitch is, I'm not. :-)
[01:07] <rob> ah ok, I'm in aus, its only 10am here (should have thought about that)
[01:07] <rob> yeah
[01:07] <rob> err 10 pm rather
[01:07] <Fujitsu> rob: SA?
[01:07] <Hobbsee> yes, but you're in queensland
[01:07] <Fujitsu> Ah.
[01:07] <Fujitsu> That'd do it.
[01:07] <rob> yep
[01:08] <Hobbsee> Fujitsu: SA's only half an hour behind.  the flight attendants told us so.
[01:08] <Fujitsu> A..ha.
[01:08] <jdub> Hobbsee: half an hour and twenty years.
[01:08] <rob> I just noticed on sourceforge that he is involved with a project called Scrappy, which sounds like something my wife would be interested in using eventually
[01:08] <StevenK> Yup. And NT is 1 and a half hours, just to be confusing.
[01:09] <Hobbsee> jdub: *grin*
[01:12] <StevenK> Fujitsu: Commonly called "Keybuk"
[01:12] <rob> I was thinking chocolates, but sure, ok :D
[01:18] <geser> Fujitsu: wait till it pops up again before pressing it
[01:19] <StevenK> Keybuk or MoM? :-P
[01:19] <StevenK> MoM might be crashing
[01:19] <Fujitsu> StevenK: I presume it is crashing, yes.
[01:19] <Fujitsu> It has a habit of that, of late.
[01:21] <infinity> Special.  apt-get in my hoary chroot has spontaenously decided to start segfaulting.
[01:21] <infinity> Fanfreakingtastic.
[01:21] <Fujitsu> Sounds ideal!
[01:21] <Hobbsee> infinity: *way cool* - why do you have a hoary chroot?
[01:21] <infinity> Hobbsee: Why not?
[01:21] <pitti> infinity: it might be aware that its's supposed to be entirely dead now...
[01:21] <Hobbsee> infinity: because it's EOL'd?
[01:21] <Fujitsu> +1 pitti 
[01:22] <Hobbsee> haha
[01:22] <infinity> Hobbsee: Old habits die hard.
[01:22] <infinity> I suppose I should delete EOL chroots.
[01:22] <infinity> Hell, I still have potato chroots.
[01:22] <Hobbsee> infinity: got warty ones too, then?
[01:22] <Fujitsu> Buzz!
[01:22] <infinity> Hobbsee: Yes.
[01:22] <Hobbsee> heh
[01:22] <bhale> Hobbsee: at my parents i found a cdr labeled Warty RC
[01:22] <bhale> with a solid inch of dust on it
[01:22] <bhale> history in the making
[01:22] <Hobbsee> bhale: ...wow
[01:23] <infinity> (base)adconrad@cthulhu:/chroot$ find * -maxdepth 0 -type d
[01:23] <infinity> breezy
[01:23] <infinity> dapper
[01:23] <infinity> edgy
[01:23] <infinity> etch
[01:23] <infinity> feisty
[01:23] <infinity> hoary
[01:23] <infinity> potato
[01:23] <infinity> sarge
[01:23] <infinity> sid
[01:23] <infinity> warty
[01:23] <infinity> woody
[01:23] <Fujitsu> Good old woody.
[01:23] <infinity> Is woody EOL now too?  Or is Debian still doing oldstable updates?
[01:24] <pitti> ended ages ago
[01:24] <infinity> Right.  Guess I can make that go too.
[01:24] <pitti> infinity: woody support ended in June 2006 IIRC
[01:25] <pitti> (one year after sarge was released)
[01:25] <pitti> http://www.debian.org/releases/woody/ agrees
[01:29] <Whoopie> Hi, is there any plan when the edgy-commercial repo is filled with the packages from dapper-commercial?
[01:36] <cjwatson> Whoopie: I don't believe that's going to happen automatically; it depends what the companies supporting those packages want to do
[01:38] <StevenK> infinity: Just one?
[01:38] <Whoopie> cjwatson: ah, I thought somebody of the devs is filling the repo. So you are waiting until the companies are ready with packages for edgy?
[01:38] <szachista_> errr... what was that email where i can report ubuntu licence violation? 
[01:38] <szachista_> sorry, my web browser has crashed ;(
[01:38] <cjwatson> Whoopie: well, it's not my responsibility, that's just what I vaguely remember
[01:38] <infinity> StevenK: Several, truth be told.  Woody was a good release, with many fond memories.
[01:39] <szachista_> i mean i use opera for irc ;)
[01:39] <StevenK> Heh
[01:39] <cjwatson> szachista_: info@ubuntu.com was what I suggested, although as I said it may not be quite right
[01:39] <szachista_> cjwatson: thank you :)
[01:39] <StevenK> infinity: Do packages need to be given back manually if a dependancy didn't exist?
[01:39] <Whoopie> cjwatson: ok, thanks.
[01:39] <infinity> StevenK: Should go into dep-wait, which will be auto-cleared.
[01:39] <infinity> StevenK: Package in question?
[01:40] <cjwatson> Whoopie: mdy@c.c deals with that sort of thing from the corporate end, I believe
[01:40] <StevenK> infinity: libept
[01:41] <cjwatson> well, libtagcoll2-dev still doesn't exist ...
[01:42] <infinity> StevenK: https://launchpad.net/+builds/+build/282546
[01:42] <infinity> StevenK: auto-dep-wait.  It'll clear when the dep can be found. :)
[01:43] <pitti> do import requests from experimental require an ubuntu-archive bug, or is an IRC ping enough?
[01:43] <StevenK> Ah, I know why. libtagcoll2 has built, and is stuck in binary NEW.
[01:43] <infinity> pitti: Paper trails are nice, but IRC can do the trick, if someone's in the mood to do the sync.
[01:44] <pitti> ok; I'd like to get postgresql-8.2 into feisty, but I cannot upload it to unstable yet since it would disrupt the etch release process
[01:44] <Fujitsu> cjwatson: I note that gcl has built on all archs.
[01:44] <StevenK> (Well, I think that's it. I can't check, of course. :-)
[01:45] <Lure> pitti: re exiv2 MIR - are we supposed to hunt upstream regarding soname or is it possible to accept it as is?
[01:45] <infinity> StevenK: It's not anymore. :P
[01:46] <StevenK> Neat, so hopefully libept will be stuck in the same fate soon. :-)
[01:46] <infinity> Ungh, someone put the tagcoll2 source in universe.
[01:46] <infinity> And it produces binaries in main.
[01:46] <pitti> Lure: asking upstream about sane sonames is always a good idea, but I won't insist that it's done before promotion
[01:46] <infinity> And is, I assume, replacing a previous SOVER from main.
[01:46] <infinity> GO US.
[01:46] <StevenK> Ohh, nice.
[01:47] <Lure> pitti: ok, thanks - I will ping upstream
[01:47] <infinity> StevenK: Should be good after the next publisher run.
[01:47] <pitti> Lure: great, thanks
[01:47] <infinity> StevenK: If not... Bug someone else.  I won't be around. :)
[01:47] <StevenK> infinity: Nice, thanks.
[01:48] <StevenK> infinity: :-)
[01:49] <cjwatson> Fujitsu: yes, I went to deal with it earlier this morning but saw the comment on the bug implying that it may not be properly fixed
[01:51] <cjwatson> Fujitsu: so I'd like an answer to that before proceeding
[01:51] <StevenK> cjwatson: I've been meaning to ask, why not Kamion any more?
[01:53] <cjwatson> I switched while away somewhere because I couldn't get to my home server, and liked it better
[01:53] <StevenK> Heh, fair enough.
[01:53] <cjwatson> conversations with Keybuk are easier to follow, if nothing else ...
[01:53] <Fujitsu> cjwatson: Yeah, I noted that... I think it must be a different bug, as it is fixed for everybody else, and the fix makes sense.
[01:53] <StevenK> cjwatson: Bwaha
[01:54] <cjwatson> Fujitsu: I'll wait until Monday for a response from that user, then go ahead
[01:54] <StevenK> cjwatson: My client hilights the nick of people talking to or about me in red, which makes it simpler.
[01:55] <Fujitsu> cjwatson: Sounds good.
[01:55] <jdub> freespire shipping upstart
[01:55] <Fujitsu> StevenK: Have you not read through conversations where K{eybuk,amion} have been talking to each other, and been confused?
[01:56] <StevenK> Not usually.
[01:56] <StevenK> It happens occasionally. :-)
[01:57] <Fujitsu> When is Keybuk normally around?
[01:59] <cjwatson> StevenK: so does mine, but it doesn't highlight my own statements visibly enough to avoid confusion when reading back through scrollback
[01:59] <StevenK> Ahh. My own statements have the <> hilighted in red, which gives me enough of a clue.
[02:15] <sivang> Lathiat: and now? :)
[02:26] <sivang> Lathiat: Well, when you do see this message, I was just wondering if you could walk me through again to set up Xorg to work using hardware accel, using the ATI prop driver,
[02:26] <sivang> Lathiat: you see, the FLOSS one is terrible in even movie playing performance wise.
[02:28] <Treenaks> sivang: it works OK on my mac mini
[02:29] <Treenaks> but somehow it forces AGP to 1x always
[03:57] <bhale> cjwatson: this is a silly question, but does ubiquity call xrandr after the keyboard map selector page?
[03:57] <bhale> cjwatson: the screen goes totally ape, and it even seems to be rotated on its side from what I can make out
[04:00] <Riddell> bhale: I also get X corruption at that stage
[04:00] <Riddell> filing a bug is on my todo list
[05:37] <bluefoxicy> GAH
[05:37] <bluefoxicy> Qu'vatlh ghuy'cha' ><
[05:37] <bluefoxicy> bhale:  ping.  Confirm this for me:  NX-bit supplied 32-bit platform (i.e. amd64 in 32-bit mode), no NX bit, edgy, kernel 2.6.19-7-generic
[05:38] <bluefoxicy> cpuinfo says I have it
[05:38] <bluefoxicy> maps says it's set
[05:38] <bluefoxicy> paxtest says vulnerable to every-fucking-thing
[05:38] <bluefoxicy> it wasn't like this before
[07:13] <jdong> 2.6.19 made reiserfs stop retardedly caching its bitmaps at mount, right?
[07:13] <jdong> so it doesn't take 3 minutes to mount my external HD?
[07:13] <jdong> ok, I'll assume so and install my test feisty partition as reiser
[07:13] <jdong> and come back here and nag you guys in 3 hours if it wasn't the case
[07:13] <jdong> sound good? of course it does :)
[07:14] <wasabi> xfs yay =)
[07:14] <wasabi> xfs won't kill your wife, just your files.
[07:14] <jdong> wasabi: xfs is no friend of the pbuilder though ;-)

[07:14] <jdong> lol
[07:14] <jdong> wasabi: it's a shame XFS doesn't like to delete files in a timely manner :D
[07:14] <wasabi> Yeah. That is annoying.
[07:15] <wasabi> I do wish it had optional data journaling just for completeness too
[07:15] <jdong> aye
[07:15] <jdong> wasabi: also, on plebian x86 hardware, I can consistently corrupt XFS though intentional resets
[07:15] <jdong> so it ain't for general usage....
[07:16] <wasabi> You mean hard power off?
[07:16] <jdong> right
[07:16] <wasabi> Totally. It caches too much
[07:16] <jdong> hard poweroff and hard reset
[07:16] <wasabi> You need battery backed stuff.
[07:16] <jdong> well, not just caching...
[07:16] <jdong> caching can explain DATA being gone or corrupted
[07:16] <jdong> not XFS refusing to mount, and xfs_repair zapping everything to lost+found
[07:16] <jdong> that there is metadata corruption....
[07:16] <wasabi> Hmm. Haven't had that for a long time.
[07:16] <jdong> well
[07:16] <wasabi> There was a bug in... <2.6.16 I think
[07:16] <wasabi> Which introduced silent corruption.
[07:16] <jdong> this behavior came back in Edgy for me
[07:17] <jdong> silent corruption was 2.6.17.1-7
[07:17] <wasabi> Eh? Thought it was way before that.
[07:17] <jdong> but what I experienced was not that
[07:17] <jdong> wasabi: unless you aren't talking about that dnode corruption fiasco?
[07:17] <wasabi> I don't know what the exact issue was.
[07:17] <wasabi> I just remember using xfs_db to fix it. =(
[07:17] <jdong> that's dnode
[07:18] <jdong> introduced early in the 2.6.17 tree
[07:18] <jdong> fixed in the point-7 release IIRC
[07:18] <wasabi> Ahh, yeah, you're right. Just looked it up.
[07:18] <jdong> and to put salt in the wound xfs_repair wasn't able to detect/fix the issue :)
[07:18] <wasabi> I got bitten by that.
[07:18] <wasabi> Yeah. I had to backport it from edgy or something
[07:18] <jdong> yep
[07:18] <wasabi> That was depressing.
[07:19] <jdong> I bugged a while to get that updated xfstools past version freeze
[07:19] <wasabi> I really do like XFS though. It is noticible faster on the systmes I use it on, than ext, anyways.
[07:19] <jdong> wasabi: I love XFS too
[07:19] <wasabi> It really loves dual cores.
[07:19] <jdong> wasabi: I use it to store my multimedia files
[07:19] <wasabi> /dev/evms/shares      548G  528G   21G  97% /shares
[07:19] <jdong> which ext3 and reiser simply choke on
[07:19] <wasabi> same =)
[07:19] <jdong> aye, exactly
[07:19] <jdong> torrents, too
[07:20] <jdong> ext3 fragments my 20GB torrents into 5 fragments or so per MB by the time it's done
[07:20] <wasabi> I set up a new box at work last thurs... I started with ext3.
[07:20] <jdong> needless to say it doesn't exactly read back with ease ;-)
[07:20] <wasabi> As soon as I got under heavy IO node, xchat locked up.
[07:20] <wasabi> Blocking on it's log files.
[07:20] <wasabi> s/node/load/
[07:20] <jdong> yep
[07:20] <wasabi> That pissed me off, so I tar'd it all up and went back to xfs
[07:20] <jdong> reiser is better with data writes
[07:20] <jdong> but has the same issues with metadata
[07:20] <jdong> delete 1 million files, you won't be able to move your MOUSE until it finishes
[07:21] <wasabi> heh
[07:21] <jdong> (though to be fair it does it at a blistering pace)
[07:21] <wasabi> wonder why that stuff doesnt' get backgrounded in an intelligent manor.
[07:21] <wasabi> manner
[07:21] <jdong> if I understand correctly it's an issue of kernel locks
[07:21] <jdong> especially with reiserfs...
[07:21] <jdong> there's some serious scalability issues with reiserfs
[07:21] <wasabi> I've noticed that too though. Blowing away a 4GB file on XFS... basically locks everything up.
[07:22] <jdong> if you have like 20 or so of them mounted, all of them will be very sluggish
[07:22] <jdong> the problem isn't nearly as bad on XFS
[07:22] <jdong> but yes, it does show up
[07:22] <jdong> I think on XFS it's purely an issue of the IO scheduler not playing fairlty
[07:22] <wasabi> I don't really understand why.
[07:22] <jdong> same with ext3
[07:22] <wasabi> I've always though it would be a relatively small manner to just write down the delete in some log, and work on it in the background.
[07:23] <jdong> wasabi: apparently xfs deletion is quite some rocket science
[07:23] <jdong> I was told that on #xfs
[07:23] <jdong> there's quite a deal of B+tree rebalancing done in the process
[07:23] <wasabi> hmm.
[07:23] <jdong> and all that balancing is inturn eventually deleted anyway ;-)
[07:23] <jdong> especially if your'e removing a large directory tree
[07:23] <jdong> that is just screaming to be optimized ;-)
[07:23] <wasabi> guess nobody is being paid to work on it anymore eh?
[07:24] <wasabi> there were two sgi contractors i thought... before sgi ate it.
[07:24] <jdong> there's still sgi folk actively working on XFS
[07:24] <wasabi> sandeen or something
[07:24] <jdong> yep
[07:24] <jdong> Sandeen
[07:24] <jdong> and there's another one too
[07:24] <wasabi> Do they actually get paid by SGI?
[07:24] <jdong> based in Australia
[07:24] <jdong> yes, they're paid SGI employees
[07:25] <wasabi> I didn't realize SGI still had paid employees. ;)
[07:26] <jdong> lol
[07:26] <jdong> probably not for long :D
[07:26] <wasabi> so sad
[07:26] <Yagisan> I used to use JFS instead of XFS, almost same performance, but lower cpu use
[07:26] <jdong> personally... I hope ext4's promised changes will fix it
[07:26] <wasabi> I never really looked much at JFS.
[07:26] <jdong> and make it much more performance-competent
[07:26] <jdong> JFS is pretty nice
[07:26] <wasabi> It got merged into mainline after I made teh switch to XFS.
[07:26] <jdong> though there's a few oddities
[07:27] <wasabi> So I never really started learning about it
[07:27] <jdong> i.e. NEVER EVER MOUNT BEFORE FSCKING
[07:27] <wasabi> heh
[07:27] <Yagisan> it and xfs where slow on delete so I did recently change it
[07:27] <jdong> journal replay is done by fsck
[07:27] <wasabi> and mounting doesn't abort?
[07:27] <jdong> Yagisan: it's apparently due to the B+tree nature and the need to rebalance the trees on delete
[07:27] <jdong> wasabi: no, it happily mounts and then starts screaming about node corruption
[07:28] <wasabi> and that's not a 4 line patch? heh
[07:28] <jdong> wasabi: you're supposed to mount it ro, fsck it , then mount it rw
[07:28] <jdong> wasabi: apparently "everyone knows that" :D
[07:28] <Yagisan> first I heard of it
[07:28] <jdong> Yagisan: well, good I saved you from looking dumb :D
[07:28] <wasabi> On the topic of obscoure file systems. I started playing with AFS again
[07:28] <Yagisan> oddly, I found jfs outperformed xfs on my software raid
[07:28] <Yagisan> and xfs on non-raid
[07:29] <Yagisan> (media, torrents, and many many pbuilder runs)
[07:29] <Yagisan> in the end, I went back to slower ext3 with full journalling
[07:29] <jdong> Yagisan: jfs is not a bad performer by any stats
[07:29] <jdong> in fact, I have found JFS to be the most responsive under heavy IO
[07:29] <wasabi> pbuilder sucks because of deletes, right?
[07:29] <Yagisan> the low cpu usuage is really nice on jfs
[07:29] <jdong> wasabi: right
[07:30] <jdong> wasabi: takes 30s to clean up pbuilder on XFS, 10s on ext3, 1s on reiser
[07:30] <wasabi> heh.
[07:30] <jdong> Yagisan: JFS has _consistent_ performance
[07:30] <jdong> sure it may be slow at times compared to the compettiion
[07:30] <jdong> but it never wildly fluxuates from task to task
[07:30] <jdong> *ahem* reiser
[07:30] <wasabi> I'd sure like to see a file system with COW copies.
[07:31] <jdong> :)
[07:31] <wasabi> and yes I realize programs would have to take advantage of it
[07:31] <jdong> bzrfs
[07:31] <jdong> lol
[07:31] <jdong> one day
[07:31] <wasabi> bzrfs? hah
[07:31] <jdong> it's not at all impossible
[07:31] <jdong> python-fuse FTW?
[07:31] <Yagisan> I have resier on my www server for one reason
[07:31] <wasabi> I bet you could make a fuse thing do it pretty easy
[07:31] <wasabi> in fact... googles.
[07:31] <Yagisan> masses and masses of many small files
[07:31] <wasabi> I bet somebody else has already thought of it
[07:31] <Yagisan> (gigs of doxigenated source)
[07:32] <jdong> I have nothing against reiserfs at all
[07:33] <jdong> it's been rock-stable for me
[07:33] <jdong> the only complaint I've had about it is reiserfsck
[07:33] <wasabi> Oh, also, XFS needs shrinking.
[07:33] <Yagisan> I had it eat data when I first tried it back in the 2.4.x kernels
[07:33] <jdong> if you ever have a hardware malfunction that leaves you with a corrupt FS
[07:33] <wasabi> I love that about reiser.
[07:33] <jdong> YOU ARE SCREWED WITH REISER :)
[07:33] <wasabi> online shrinking and expanding
[07:33] <jdong> have fun :)
[07:33] <jdong> they should just symlink fsck.reiserfs to mkfs.reiserfs
[07:33] <jdong> it'll save time
[07:33] <jdong> and code
[07:39] <wasabi> I'd also like a way to re-collapse sparse files.
[07:39] <wasabi> Without closing them.
[07:42] <jdong> :)
[07:52] <Chipzz> wasabi: just wondering, how do you create a sparse file in the first place? just write all zeroes?
[07:53] <cjwatson> bhale,Riddell: no, it doesn't. It does call setupcon, which does ioctl(KDFONTOP), which seems to confuse X in various ways; there is a bug filed already
[07:55] <cjwatson> hoping not to have to turn that off again, as it's nice for setup-console-under-usplash as well as general simplicity, but I may have to if we can't work out the issue
[07:55] <wasabi> Chipzz: seek ahead in the file.
[07:55] <cjwatson> problem is that I haven't seen it on any of my own hardware so far
[07:55] <wasabi> Chipzz: which basically increases it's size, but writes nothing. the FS can interpret that as using fake blank space
[07:56] <wasabi> dd if=/dev/zero of=file bs=1M count=0 seek=100 or something
[08:03] <Chipzz> wasabi: wont that just return an EOF?
[08:03] <cjwatson> Chipzz: no, see lseek(2)
[08:04] <cjwatson> it has an explicit paragraph about that at the end of the DESCRIPTION section
[08:05] <Chipzz> uhu
[08:05] <Chipzz> thx :)
[08:05] <dLinkCrawxor> Is it true ubuntu dont fix all bugs thus getting more money through supporting the system?
[08:06] <Chipzz> heh
[08:06] <mjg59> Not deliberately, no
[08:06] <Chipzz> you're implying so bad things
[08:06] <Chipzz> if ubuntu would do that, they would be shooting theirselves in the foot
[08:06] <desrt> dLinkCrawxor; ubuntu doesn't get money from support...
[08:06] <desrt> dLinkCrawxor; except indirectly
[08:07] <dLinkCrawxor> ok
[08:07] <desrt> dLinkCrawxor; companies involved in (and sometimes working on -- that's the indirect) get the money
[08:07] <Chipzz> dLinkCrawxor: not every bug gets fixed; but I think that's more of a resources thing as to use for ransom
[08:08] <wasabi> is it true that mark eat's babies?
[08:08] <cjwatson> I can confidently say that I've never once deliberately failed to fix a bug in order to increase support revenue, nor have I ever been asked to
[08:08] <desrt> wasabi; that i can confirm.
[08:08] <cjwatson> the same is true of every technical company I've worked at
[08:09] <Chipzz> btw, I was wondering something
[08:09] <cjwatson> desrt: that's not true though - Canonical has a growing support department
[08:09] <Chipzz> whoopie brought up dapper-commercial earlier
[08:09] <desrt> cjwatson; canonical _is not_ ubuntu
[08:09] <cjwatson> desrt: *shrug* damn big slice of it
[08:09] <Chipzz> what is supposed to be best practice for commercial apps if they ship their own libraries we also ship?
[08:09] <Lathiat> desrt: while that is true
[08:09] <Lathiat> arguably, its a pretty fuzzy line
[08:09] <cjwatson> desrt: in practice a large chunk of that support revenue is going to feed straight back into Ubuntu
[08:10] <desrt> cjwatson; as i said above.  indirectly because canonical works on ubuntu.
[08:10] <Chipzz> make a .deb with their libs included, or alter to structure to have it ue our files?
[08:10] <cjwatson> desrt: which you may call indirect, but I think is direct
[08:10] <Chipzz> s/ue/use/
[08:10] <desrt> cjwatson; i claim that it's indirect for the time being
[08:10] <cjwatson> desrt: I respectfully disagree, and we can leave it at that
[08:11] <desrt> cjwatson; since if there was no support money, even now, mark would just be bankrolling the entire thing still
[08:11] <desrt> cjwatson; but this is not going to be true going into the future
[08:12] <bluefoxicy> yep
[08:12] <bluefoxicy> it's official, and it's pissing me off, wtf.
[08:12] <dLinkCrawxor> Ubuntu is just like everything else. It's about making profit. 
[08:12] <Chipzz> for example vmware-player ships its own version of gtk+, should we ship that too, or have it depend on our libgtk2-0?
[08:12] <dLinkCrawxor> Not saying that's a bad thing
[08:12] <dLinkCrawxor> Linux is a hippie thing anymore
[08:12] <dLinkCrawxor> isnt*
[08:13] <wasabi> Chipzz: I don't believe there is a policy. There should be. ;)
[08:13] <Chipzz> (maybe I should ask on -motu?)
[08:13] <wasabi> Chipzz: I'd like to see third parties ship ubuntu-certified packages.
[08:13] <dLinkCrawxor> Mark is a Giant Pooh. Jesus told me
[08:14] <wasabi> Chipzz: Like, one package for dapper, one for edgy, one for feisty, etc.
[08:14] <wasabi> Or maybe just for LTS releases.
[08:15] <Chipzz> wasabi: well, obviously depending on our own libs is better; otoh, when our libs upgrade to something incompatible with the commercial package, we'll have to include it again, so that makes stuff more difficult to upgrade these packages
[08:15] <Lathiat> vmware tries to use the distro libs anyway
[08:15] <Lathiat> if that fails it restarts with its own
[08:15] <Lathiat> interestingly, in dapper, it would fail with dappers and fell back to its own
[08:15] <wasabi> Chipzz: I feel the vendor should track our libs, and we should not change our libs in incompatible ways without very good reasons.
[08:15] <Lathiat> due to some change in gtk that caused vmware to crash
[08:15] <Lathiat> (it was a vmware bug, but none the less)
[08:15] <Chipzz> wasabi: yes, but what if the vendor doesn't ship binaries for ubuntu, just general binaries
[08:16] <Chipzz> and we happen to package their tarball
[08:16] <Chipzz> (like vmware)
[08:16] <wasabi> Got me.
[08:16] <wasabi> Probably up to whomever does the packaging.
[08:16] <wasabi> I would sure like to see vmware distribute vmware though. I'm not a fan of this commercial repository stuff.
[08:16] <Chipzz> vmware is not in dapper-commercial btw
[08:16] <Chipzz> it's in universe I think
[08:17] <wasabi> vmware-player is in multiverse or some such right?
[08:17] <Lathiat> vmware is in multiverse
[08:17] <Chipzz> yeah
[08:17] <wasabi> Chipzz: http://wiki.ubuntu.com/ThirdPartyApt   I pine about some stuff there. =)
[08:17] <wasabi> I would love it if we supported ISVs in supporting us.
[08:17] <wasabi> So they could push their own updates on their own schedules.
[08:17] <wasabi> But take advantage of our great package management framework, etc.
[08:18] <wasabi> Also update-manager and friends.
[08:18] <cjwatson> Ubiquity/DriverUpdates is progress towards that on one front that's perhaps slightly different from what you've been thinking of
[08:18] <wasabi> Yeah, it is.
[08:18] <wasabi> I really speak more about the propriatary world.
[08:18] <Chipzz> vmware should ship a new version compiled against latest dbus btw
[08:18] <cjwatson> remains to be seen what the vendor takeup would be
[08:18] <Chipzz> (and latest libsexy)
[08:18] <wasabi> I think it's a simple reality that all vendors will not want to put their software in our repository.
[08:19] <Chipzz> I poked chipx86 about that, but got no response
[08:19] <wasabi> Nor go through us to update/manage that.
[08:19] <wasabi> Chipzz: Also, as an example, vmware could depend on gtk>=2.5 <= 2.6 or some such.
[08:19] <wasabi> Or whatever gtk's no-ABI-change policy is
[08:19] <Chipzz> wasabi: gtk+ is not a problem, really
[08:19] <Chipzz> dbus is
[08:19] <wasabi> So, the upgrade to feisty would pop up and say "I can't do this. You've installed a third party piece of software. They need to update first."
[08:20] <wasabi> "Go talk to them."
[08:20] <wasabi> Same diff.
[08:20] <Chipzz> no not really ;)
[08:20] <wasabi> How so?
[08:20] <Chipzz> gtk+ is supposed not to be removing/changes functions throughout the 2.0 series
[08:21] <Chipzz> dbus did change api
[08:21] <wasabi> That's fine. The vmware guys know what version is going to be shipped in feisty.
[08:21] <wasabi> They can procuce updated packages. Smae way MS developers all "get ready for vista" and stuff.
[08:21] <wasabi> With the end goal being of course that Ubuntu is the only Linux distro that ISVs care to target. ;0
[08:21] <Chipzz> yeah but they seem reluctant to do so
[08:22] <wasabi> I don't think we engage them enough.
[08:22] <Chipzz> the problem with the dbus api is not just the library
[08:22] <wasabi> I've worked with MS ISVs for ages. There are classes you can go to. Services you can buy, programs you can sign up for.
[08:22] <wasabi> All with teh aim of having the entire ecosystem ready for Vista.
[08:22] <Chipzz> the bigger issue with dbus is the bus protocol (which is also an api)
[08:22] <wasabi> It's a matter of us, after freeze, talking to ISVs and helping them get their software in order.
[08:23] <Chipzz> so, has that happened for vmware yet? :)
[08:23] <wasabi> Nope.
[08:23] <wasabi> It was one of the reasons I went to UDS... just couldn't get many people to care.
[08:24] <okaratas> hi
[08:24] <wasabi> I think TD showed up, and the entire time was spent talking about autopackage.
[08:24] <wasabi> Or, less talking, and more arguing?
[08:25] <imbrandon> moins fellas
[08:25] <bluefoxicy> Question
[08:25] <bluefoxicy> 1)  If I check a bug as a security vulnerability, does it become invisible?
[08:26] <imbrandon> afaik yes
[08:26] <bluefoxicy> 2)  Should I check a failure to enforce memory protections (PROT_EXEC) as a vuln?
[08:26] <wasabi> Chipzz: I have a real strong feeling that stuff like that is why we aren't gaining traction as fast as we'd like among the ISVs.
[08:26] <wasabi> Our community and their... company... just run on different things.
[08:26] <bluefoxicy> I have a test case to show the failure
[08:26] <wasabi> MS really has that figured out well.
[08:26] <Chipzz> autopackage is the biggest pile of crap to come out of the open source community
[08:26] <wasabi> Haha.
[08:26] <wasabi> That's basically the position I took, with less nasty words. ;)
[08:27] <wasabi> Chipzz: So, honestly, as somebody in Vmware (you are still there right?) what do you think the interest would be from their side?
[08:27] <Chipzz> wasabi: I'm not ;)
[08:27] <wasabi> ahh.
[08:27] <wasabi> Oh.
[08:28] <wasabi> mistaken identity!
[08:28] <Chipzz> I did try nagging him though ;)
[08:28] <Chipzz> (in a polite way :))
[08:28] <wasabi> Who are you then? :)
[08:28] <Chipzz> that happens often ;)
[08:28] <Chipzz> just some random guy who has contributed some minor things to gnome and ubuntu
[08:28] <bluefoxicy> oh screw it
[08:28] <Chipzz> patches mostly
[08:28] <wasabi> ahh
[08:28] <bluefoxicy> I'll just leave it out in the open
[08:29] <Chipzz> and I have been in the gnome packaging team several years ago
[08:29] <Chipzz> (RH packaging)
[08:29] <wasabi> Anyways, so, I sort of think it's something somebody up in the Canonical stratosphere is going to have to do.
[08:29] <wasabi> Ya know, it's marketing at it's heart.
[08:29] <Chipzz> unofficial rpms
[08:33] <bluefoxicy> malone #75157
[08:33] <Ubugtu> Malone bug 75157 in linux-source-2.6.19 "noexec doesn't apply on 32-bit AMD64" [Undecided,Unconfirmed]  http://launchpad.net/bugs/75157
[08:49] <keescook> bluefoxicy: you have to enable PAE memory layout for nx to work in the 32bit kernel (on nx-enabled hardware)
[08:50] <bluefoxicy> keescook:  Isn't that enabled?
[08:50] <keescook> bluefoxicy: I don't think it is by default on the 32bit kernels because it a performance hit.
[08:50] <keescook> and this is just what I remember from digging around in the kernel code trying to figure out why nx wasn't working
[08:51] <bluefoxicy> keescook:  someone needs to turn that on then~
[08:51] <bluefoxicy> HIGHMEM4G is set
[08:52] <kylem> no. we don't.
[08:52] <bluefoxicy> kylem:  and why not?
[08:54] <kylem> if you run a server-bigiron kernel, it will work.
[08:55] <bluefoxicy> so security doesn't matter for desktops?
[08:55] <mjg59> bluefoxicy: Do tell us when you've stopped beating your wife
[08:55] <bluefoxicy> You are aware that every Ubuntu desktop system now has an executable stack and heap in every process, right?
[08:55] <bluefoxicy> mjg59:  I don't have a wife
[08:55] <kylem> so does everyone else.
[08:56] <mjg59> bluefoxicy: Security matters for desktops. So do other things.
[08:56] <kylem> things which don't matter for desktops: #1) addressing 36-bits of physical memory.
[08:56] <bluefoxicy> kylem:  I don't care about 36-bits of physical memory.
[08:57] <bluefoxicy> I care about not being able to blissfully execute memory that's not supposed to be executed.
[09:00] <bluefoxicy> bah, I'm going to throw this at devel@
[09:00] <kylem> itym devel-discuss.
[09:00] <bluefoxicy> itym??
[09:03] <bluefoxicy> this is stupid, what was the point of fixing #49192 and #49283
[09:09] <cjwatson> "I think you mean"
[09:11] <bluefoxicy> there is no devel-discuss
[09:11] <cjwatson> bluefoxicy: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-December/000227.html
[09:12] <bluefoxicy> cjwatson:  well, http://www.ubuntu.com/community/lists doesn't list it so I didn't post there.
[09:12] <bluefoxicy> (yes I looked when he said that)
[09:12] <bluefoxicy> it's not on the full list either.
[09:12] <cjwatson> the canonical list of Ubuntu mailing lists is on http://lists.ubuntu.com/, not there
[09:13] <bluefoxicy> nope, it's not
[09:13] <cjwatson> it not being on lists.u.c is a bug, which I'll file in RT now
[09:13] <bluefoxicy> https://lists.ubuntu.com/mailman/listinfo/ re?
[09:13] <cjwatson> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
[09:14] <bluefoxicy> well there you go.
[09:14] <cjwatson> should be sorted out shortly
[09:15] <bluefoxicy> heh, it would help if I actually read the list instead of just posting to it; it's the third message down
[09:15] <bluefoxicy> also I'm no longer allowed to post to it, yay.
[09:15] <cjwatson> "it"?
[09:15] <bluefoxicy> the list... ubuntu-devel.. am I the only one that has any context?
[09:16] <cjwatson> there were two possible referents, the other of which is ubuntu-devel-discuss
[09:16] <cjwatson> messages to ubuntu-devel are moderated, and will be approved if appropriate. if you don't think you'll ever post any appropriate messages, well, I suppose that speaks for itself
[09:17] <bluefoxicy> I think I'll be adding a new filter to my mailbox.
[09:18] <cjwatson> https://bugs.launchpad.net/products/ubuntu-website/+bug/75163
[09:18] <Ubugtu> Malone bug 75163 in ubuntu-website "/community/lists should mention ubuntu-devel-discuss" [Undecided,Unconfirmed]  
[09:28] <somerville32> Someone should change the topic in here
[09:28] <somerville32> "Home of the #ubuntu and #kubuntu operators" -> "Home of the #ubuntu, #xubuntu, and #kubuntu operators"
[09:28] <somerville32> ...
[09:28] <somerville32> Wrong channel.
[10:02] <mdke> somerville32: saw your question in -doc earlier. Documentation is subject to the same SRU procedure.
[10:05] <somerville32> mdke: So documentation doesn't qualify for an SRU?
[10:07] <mdke> somerville32: it can do, in the circumstances specified by the StableReleaseUpdates wiki page
[10:09] <somerville32> mdke: Why not have a more lenient SRU policy for documentation due to the low risk of regression?
[10:10] <desrt> (low risk and low impact)
[10:13] <rmjb> what's Adam Conrad's irc handle?
[10:13] <mdke> somerville32: I don't know, that's the policy
[10:13] <mdke> rmjb: infinity 
[10:13] <rmjb> thanks
[10:14] <mdke> somerville32: maybe there can be more lenience in the application of the policy
[10:14] <rmjb> infinity: I'm gonna try to tackle merging xbvl
[10:14] <mdke> somerville32: try and see
[10:14] <somerville32> fabbione, ping
[10:14] <somerville32> mdke: k
[11:14] <raphink> anyone has had network issues with feisty?
[11:14] <raphink> I keep losing my IP
[11:14] <raphink> and I can't add routes
[11:14] <raphink> it says 
[11:15] <raphink> SIOCADDRT: Network not available
[11:22] <deltab> raphink: you should ask in #ubuntu, if you haven't already
[11:22] <raphink> how so deltab?
[11:22] <raphink> I'll go ask in #ubuntu+1 rather
[11:22] <raphink> :)
[11:23] <deltab> it just sounds like a support issue, and the topic says this isn't the channel for that