[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<EMAIL_ADDRESS>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.  :-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_<EMAIL_ADDRESS>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<EMAIL_ADDRESS>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 <IP_ADDRESS>-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


[12:05] <Seveas> mpt, lol :)
[12:08] <mpt> :-) goodnight
[12:19] <dilys> Merge to<EMAIL_ADDRESS>[trivial]  fix for bug 2871: i set the launchpad team's emblem, and it appears lots of times. Use the correct method on Person, and add a title to the icon so people aren't so confused. Also Another externalsystem fix: cope with an unfindable version number, so I can debug better. Lintage. Prayers. And add a missing patch-log. (patch-2604<EMAIL_ADDRESS>[12:19] <Ubugtu> Malone bug #2871: i set the launchpad team's emblem, and it appears lots of times Fix req. for: upstream launchpad, Severity: Normal, Assigned to: Christian Reis, Status: PendingUpload http://launchpad.net/malone/bugs/2871
[12:19] <kiko> FINALLY
[12:19] <kiko> FINALLY
[12:19] <kiko> my god
[12:19] <kiko> this was suffering at it's best
[01:04] <dilys> Merge to<EMAIL_ADDRESS>[r=salgado]  add a bugtarget search portlet (patch-2605<EMAIL_ADDRESS>[01:08] <bradb> later
[01:10] <kiko> rock rock rock
[03:34] <dilys> Merge to<EMAIL_ADDRESS>r=kiko Validate product series name using the right validator. Leftover of bug 355. Patch by Diogo Matsubara<EMAIL_ADDRESS>(patch-2606<EMAIL_ADDRESS><EMAIL_ADDRESS>[03:34] <Ubugtu> Error: Could not parse Data returned by Malone: 'NoneType' object has no attribute 'group'
[05:23] <hertz> can anyone tell me what is karma for and how it is working?
[05:30] <ajmitch> hertz: boasting to your friends :)
[05:32] <hertz> ajmitch, :)
[05:32] <hertz> https://wiki.launchpad.canonical.com/KarmaImplementation?highlight=%28karma%29
[05:33] <hertz> https://wiki.launchpad.canonical.com/KarmaTypes?highlight=%28karma%29
[02:55] <dilys> Merge to<EMAIL_ADDRESS>[trivial]  Fix bug # 2944, Presenting buildlog properly in Soyuz. (patch-2607<EMAIL_ADDRESS>[03:05] <offray> Hi all
[03:05] <offray> anybody awake?
[03:06] <kiko> offray, always
[03:06] <kiko> matsubara, yo?
[03:09] <matsubara> ?
[03:11] <offray> Hi all. I'm a newbie on launchpad, but I like a lot the concept (its like sourceforge, but without burocracy and bloated things :))
[03:11] <kiko> offray, cool that you like the idea
[03:12] <kiko> matsubara, did you get my email? I'm still waiting for a reply (and another commit?) to merge
[03:12] <offray> I'm wondering if its posible to start a project related with translation in Plone, but its not a software translation project, but a documentation translation project. In fact, Its part of a "new kind of translation project" i'm thinking on
[03:14] <matsubara> just read it. I'm changing the tal names and will check the tests again
[03:15] <zygis> offray, if your documentation is compatible with gnome-doc-utils, then you can export documentation in regular po files, then yes
[03:15] <zygis> offray, see, how this is done in gnome http://kvota.net/doc-l10n/by-modules.html
[03:16] <zygis> this is done with xml2po
[03:17] <zygis> and then back with po2xml
[03:17] <offray> zygis, thanks, but I see that all this po files are for software. I want to translate the "Definitive Guide to Plone", at least in part
[03:18] <offray> its document translation, not interface translation
[03:18] <zygis> offray, well, XML format is *not* for software, it's for any use out there
[03:19] <zygis> as you can see from URL, this is not interface translations, but documentation translations
[03:19] <offray> yea, I know, but my question is: Can launchpad be a place to start a documentation translation project even if it doesnt generate a po file or is not for a component of software
[03:20] <offray> ohhh I see
[03:21] <markuman> hi all
[03:21] <markuman> find and import my fingerprint dont work here
[03:21] <markuman> http://paste.debian.net/2210
[03:21] <zygis> offray, you see, you can convert plain documentation xml to standart po file
[03:22] <offray> ohhh ok
[03:24] <zygis> offray, http://gnome.org/start/2.12/ look at the translations of this page
[03:24] <zygis> they were done in the same manner
[03:24] <zygis> just plain po files for translators
[03:24] <zygis> ;)
[03:26] <zygis> this is what I suggest you,since I know that this approach will work with launchpad for sure :)
[03:28] <offray> Ok. Thanks a lot zygis. I will to take a breakfast and give a look at it :)
[03:30] <kiko> markuman, let me check that
[03:30] <kiko> zygis, thanks for the help
[03:30] <kiko> offray, if you can generate pofiles, rosetta can help you translate
[03:30] <kiko> markuman, was this generated just now?
[03:31] <markuman> kiko no i tried this last week too. same error
[03:31] <kiko> markuman, let me guess: your key is sign-only, right?
[03:32] <zygis> you're welcome
[03:32] <markuman> kiko, yes, my key is signed
[03:33] <kiko> markuman, no, I meant your key is a sign-only key -- DSA (sign only)
[03:33] <markuman> hm
[03:33] <kiko> markuman, can you --list-key?
[03:34] <markuman> you mean on my system? but there are 2 other key from friends
[03:34] <markuman>  gpg --list-key DDE93F54
[03:34] <markuman> you mean?`
[03:34] <kiko> --list-keys sorry
[03:34] <kiko> yep
[03:35] <matsubara> kiko, I'm fixing another broken pagetest related to targeting fix to release
[03:35] <kiko> matsubara, ah, rock n roll, thanks
[03:35] <kiko> matsubara, do you need help?
[03:35] <markuman> kiko: did you mean this? http://paste.debian.net/2211
[03:36] <kiko> https://launchpad.net/products/launchpad/+bug/1972
[03:36] <Ubugtu> Error: Could not parse Data returned by Malone: 'NoneType' object has no attribute 'group'
[03:36] <matsubara> i think i can handle it :) tks anyway
[03:36] <kiko> Seveas, hey
[03:37] <kiko> markuman, yeah, you have no subkey -- that's a sign-only key
[03:37] <markuman> uhm...so what i have to do???
[03:37] <kiko> markuman, there's a bug that we currently don't support sign-only keys, unfortunately
[03:37] <kiko> you can convert your key, I believe
[03:38] <markuman> hm
[03:43] <ddaa> hi offray, are you texmacs' "Offray Luna" by any chance?
[03:44] <kiko> hey ddaa
[03:45] <ddaa> hi kiko
[03:45] <ddaa> I see matsubara is my new "fix registry for me" monkey ;)
[03:47] <kiko> ddaa, we're working on it
[03:47] <kiko> still a lot to learn
[03:48] <markuman> kiko: http://paste.debian.net/2212 can you watch at them?
[04:08] <Seveas> kiko, hi
[04:09] <kiko> Seveas, did you see the exception above in Ubugtu?
[04:09] <Seveas> yeah
[04:09] <Seveas> it's because he cannot access that page
[04:09] <kiko> Seveas, okay, it should ideally return a nice error
[04:09] <Seveas> It should :)
[04:09] <Seveas> (And it will in ~5 minutes)
[04:09] <kiko> cool
[04:10] <Seveas> I thought all bugs were public and since the 'parser' is simply a regex, this is just an unforseen error
[04:12] <kiko> some are private because of larger code snippets I think
[04:12] <kiko> markuman, that should work now -- have you tried?
[04:20] <Seveas> https://launchpad.net/products/launchpad/+bug/1972
[04:20] <Ubugtu> Error: I cannot access this bug
[04:20] <Seveas> there :)
[04:20] <kiko> cool!
[04:20] <Seveas> That's the zillionth malone special case in the script :)
[04:21] <kiko> heh
[04:21] <kiko> welcome to the real world
[04:21] <Seveas> ;)
[04:22] <Seveas> I'm gonna rewrite the plugin next week to handle these things more gracefully
[04:26] <sivang> hey guys, yo kiko didn't know there was so much action here on th saturday
[04:26] <sivang> :)
[04:26] <kiko> saturday rox
[04:28] <markuman> kiko, same error
[04:29] <\sh> kiko: right...u can drink alcohol while u r working ;)
[04:29] <sivang> kiko: I see alot of specs registered in the spec tracker, are those new or already tracking your work?
[04:29] <kiko> tracking existing work
[04:31] <sivang> ah I see, very nice btw
[04:31] <kiko> yeah, the tracker is quite neat
[04:32] <sivang> the spec, support and sprint trackers are very interesting to me, duonno why :)
[05:04] <azeem> Hello.  How would I go forth requesting bazaar.ubuntu.com repos for the CVS modules at http://savannah.gnu.org/cgi-bin/viewcvs/hurd/ ?
[05:04] <azeem> Some of the respective developers would like to move to a distributed VC, and this might be a good place.  I cannot guarantee that it will be immmensely used, though
[05:05] <kiko> azeem, talk to jblack to get you guys set up on the supermirror
[05:08] <kiko> it should be pretty easy
[05:08] <kiko> azeem, and ddaa can get your CVS repository synced into bazaar in no time (usually)
[05:09] <kiko> markuman, that's odd.
[05:11] <kiko> I'm adding a comment to the bug
[05:13] <\sh> azeem: can u join -motu pls? :)
[05:13] <ddaa> azeem: first thing is to setup launchpad project/product for hurd
[05:13] <ddaa> kiko: do we have a wiki page or something for that?
[05:13] <azeem> haha, I thought ddaa was a script/program at first :)
[05:13] <azeem> hang on
[05:13] <kiko> azeem, he's one of those too
[05:14] <kiko> ddaa, on setting up new products and projects? No, but the site should be self-explanatory :)
[05:14] <ddaa> kiko: dude, people DO the wrong thing
[05:14] <kiko> :)
[05:14] <kiko> then we are not self-explanatory
[05:15] <ddaa> the distinction between a product and project is neither simple, nor obvious, nor even clear cut.
[05:15] <ddaa> It's nothing that can be explained in a few words.
[05:16] <kiko> it's also broken
[05:17] <markuman> damn and now?
[05:18] <kiko> markuman, I'm confused. I thought the issue was with sign-only keys, but I am finding it's not. I'll need to delve into the gpgme code a bit
[05:19] <kiko> markuman, you did --send-key after adding the new subkey, right?
[05:20] <markuman> of course ive send the key
[05:28] <markuman> kiko: or can you insert my key manually ?
[05:32] <kiko> markuman, hmmm, not easily
[05:32] <kiko> I needed Kinnison or lifeless to help me here
[05:32] <markuman> hm
[05:32] <kiko> or jamesh
[05:33] <kiko> matsubara?
[05:36] <Kinnison> cprov might be able to help
[05:37] <kiko> Kinnison, I just wanted you to check out his key
[05:37] <markuman> hm, im away now but will come back....
[05:37] <matsubara> ?
[05:37] <kiko> Kinnison, gpg --recv-key DDE93F54
[05:38] <matsubara> kiko?
[05:38] <kiko> matsubara, why did you change the user in tests 10 and 20?
[05:38] <markuman> kiko, if youll find out something pls leave me a message on freenode
[05:39] <kiko> will do
[05:39] <kiko> thanks mark
[05:39] <kiko> thanks marku
[05:39] <kiko> man
[05:39] <matsubara> foo.bar user isn't needed to run those tests. You told me to change it, just left the needed ones.
[05:39] <kiko> ah, rock
[05:40] <kiko> I didn't know
[05:40] <kiko> did you say explicitly where you used the foo.bar user that he was needed?
[05:41] <matsubara> nope. on those tests I didn't use the foo.bar. I'm doing this kind of change on ALL pagetests.
[05:41] <Kinnison> kiko: Right, that's a 1024 bit DSA signing key, with an el-gamal encryption subkey
[05:41] <Kinnison> self-signed
[05:41] <kiko> Kinnison, should it work?
[05:42] <Kinnison> and also signed by mvogt
[05:42] <kiko> Kinnison, when I --list-key it it doesn't list a uid line
[05:42] <kiko> which strikes me as odd
[05:42] <Kinnison> by rights, it should
[05:42] <Kinnison> gpg --list-key DDE93F54
[05:42] <Kinnison> pub   1024D/DDE93F54 2005-09-20 [expires: 2007-09-26]
[05:42] <Kinnison> uid                  Markus Bergholz (markuman<EMAIL_ADDRESS>[05:42] <Kinnison> sub   1024g/B825D25C 2005-09-20 [expires: 2007-09-25]
[05:43] <kiko> weird
[05:43] <kiko> not for me
[05:43] <kiko> anyway
[05:43] <Kinnison> the packetstream seems clean
[05:43] <kiko> I thought adding the subkey would fix the problem
[05:43] <Kinnison> Is it causing problems with launchpad?
[05:43] <kiko> yes
[05:43] <kiko> it fails
[05:43] <kiko> with the same error as bug 1972
[05:43] <Ubugtu> Error: I cannot access this bug
[05:45] <Kinnison> it's a seemingly sane looking subkey
[05:46] <kiko> so why does gpgme barf on it !#@!@
[05:46] <Kinnison> dunno
[05:46] <Kinnison> especially since gpgme runs gpg
[05:46] <Kinnison> and gpg seems fine
[05:46] <kiko> thanks I really appreciate it
[05:46] <kiko> could it be the expiration?
[05:47] <Kinnison> since it's so long away, it's doubtful but possible
[05:47] <Kinnison> even so, it *should* be irrelevant
[05:47] <Ubugtu> Error: I cannot access this bug
[05:48] <Kinnison> Ubugtu: what are you and why do you keep wibbling on in-band?
[05:49] <kiko> Kinnison, he's a bot
[05:50] <Kinnison> whose bot?
[05:50] <kiko> Seveas.
[05:50] <Seveas> mine, mpt asked for it to be here
[05:50] <Kinnison> Seveas: can it please not mumble in-band unless it has something positive to say?
[05:50] <Seveas> Kinnison, sure
[05:50] <Kinnison> Seveas: esp. since it seems unable to access launchpad bugs
[05:50] <Seveas> it can, this bug is just restricted
[05:51] <kiko> Kinnison, it can access launchpad bugs, just not private ones
[05:51] <kiko> I don't mind it complaining
[05:51] <Seveas> and kiko asked for it to give a sane error :)
[05:51] <Kinnison> kiko: 1972 is showing as 'Secrecy: Public'
[05:51] <Kinnison> or am I mad
[05:51] <Kinnison> ?
[05:51] <kiko> you are mad
[05:51] <Seveas> well, Ubugtu and myself cannot access it
[05:51] <kiko> weird
[05:51] <kiko> weird
[05:52] <kiko> weird
[05:52] <kiko> you can't see it Seveas? what happens?
[05:52] <Seveas> if i'm not logged in, i get redirected to the login page
[05:52] <kiko> and if you log in?
[05:52] <Seveas> Sorry, you don't have permission to access this page.
[05:52] <Seveas> You are logged in as Dennis Kaarsemaker.
[05:52] <Seveas>
[05:53] <kiko> ah
[05:53] <Kinnison> kiko: http://users.pepperfish.net/dsilvers/1972.png
[05:53] <kiko> that's cute
[05:53] <kiko> one of the dupes is private
[05:53] <Kinnison> so the entire group is treated as such?
[05:54] <kiko> I'll fix it
[05:54] <kiko> and report a bug
[05:54] <sivang> Kinnie!
[05:54] <Seveas> So should I mute the errors or let it mumble in-band?
[05:55] <kiko> it's actually proven to point out a bug, so I think it's useful
[05:55] <Kinnison> Seveas: I think, the first time in a short period, it is asked to access a bug which is private, it should say... "I'm sorry, I am not permitted to access bug NNNN"
[05:56] <Kinnison> Seveas: but it shouldn't keep saying that every time someone mentions that bug during that conversation
[05:56] <Seveas> right, I was planning to put a timer in the rewritten plugin
[05:56] <kiko> bug 1972
[05:56] <Ubugtu> Malone bug #1972: Problem validating sign-only GPG key Fix req. for: upstream launchpad, Severity: Normal, Assigned to: Celso Providelo, Status: Accepted http://launchpad.net/malone/bugs/1972
[05:56] <kiko> I roxoringor
[05:57] <Seveas> so this will be fixed next week
[05:57] <Kinnison> Seveas: that'd be cool, otherwise the next time I talk about bug 1972 we get spammed again.
[05:57] <Ubugtu> Malone bug #1972: Problem validating sign-only GPG key Fix req. for: upstream launchpad, Severity: Normal, Assigned to: Celso Providelo, Status: Accepted http://launchpad.net/malone/bugs/1972
[05:57] <Kinnison> see :-)
[05:57] <Seveas> exactly
[05:58] <Seveas> that was the original reason for the timer :)
[05:58] <Kinnison> Seveas: of course, if Ubugtu was addressed directly, it should disregard any timer issues
[05:58] <Seveas> of course
[05:58] <Kinnison> Seveas: E.g. if someone just logged into the channel we'd want to give them the info without having to wait for the timeout
[05:58] <Seveas> and the timer is per-channel
[05:59] <Seveas> anyway, off to fix real life bugs (read: cleaning so my fiancee won't get mad)
[06:00] <Kinnison> I hear ya
[06:01] <Kinnison> kiko: I seriously can't find any reason for pyme to be barfing
[06:01] <kiko> me neither
[06:01] <kiko> stupid pyme
[06:01] <kiko> should I sic jamesh on this bug?
[06:02] <Kinnison> he's probably the best bet
[06:02] <Lathiat> interesting, on techboard, communitycouncil and ubuntu-core-dev
[06:02] <Lathiat> there is a member repated twice in all of them
[06:02] <Kinnison> on the launchpad team listing?
[06:02] <Lathiat> yeh
[06:02] <Lathiat> matthias klose in ubuntu-core-dev
[06:02] <Lathiat> mdz in techboard
[06:02] <kiko> Lathiat, it's a bug -- stub is going to fix it
[06:02] <Lathiat> and cjwatcson in cc
[06:02] <Lathiat> kiko: ah ok
[06:02] <Lathiat> thats what iw as wondering
[06:02] <Lathiat> :)
[06:03] <Kinnison> Lathiat: yeah, there was a team-membership related bug in people-merge
[06:03] <Kinnison> I think we fixed the bug and just need to clean up the fallout
[06:03] <Lathiat> people-merge?
[06:03] <Lathiat> ah ok
[06:03] <kiko> yep
[06:03] <Kinnison> Lathiat: yeah, if you find you have two launchpad accounts, you can merge them
[06:03] <Kinnison> Lathiat: E.g. I had 'dsilvers' and 'kinnison'
[06:04] <Lathiat> ah ok
[06:34] <kiko> time to skip out
[07:07] <dilys> Merge to<EMAIL_ADDRESS>r=kiko Additional fixes for bug 2467 and 2468: deal with distro bugtasks with no source package name in some corner cases, adding tests for them. Patch by Diogo Matsubara<EMAIL_ADDRESS>(patch-2608<EMAIL_ADDRESS><EMAIL_ADDRESS>[07:07] <Ubugtu> Malone bug #2467: System error when requesting fix in a distribution without specifying a source package Fix req. for: upstream malone, Severity: Normal, Assigned to: Diogo Matsubara, Status: New http://launchpad.net/malone/bugs/2467
[07:08] <Kinnison> Hmm, Ubugtu should probably ignore dilys
[07:09] <Kinnison> Seveas: ^^
[07:09] <Seveas> Kinnison, http://ubuntulinux.nl/quotes?minid=10
[07:09] <Seveas> ;)
[07:09] <Seveas> but yeah, he should
[07:11] <Kinnison> heh
 ignore dilys!*@*
 The operation succeeded.
[07:13] <Kinnison> oolio
[07:14] <Kinnison> s/^/c/
[07:23] <Lathiat> hrm, where do i find team creation?
[08:03] <eruin> ,
[11:39] <uriel> I'm a bit confused, can I host a project in launchpad? so far I only found a page to "Register an upstream open source product", and well, I want launchpad to host the upstream version... maybe I'm reading the title of that page wrong...
[11:42] <sivang> uriel: launchapd can track upstream projects, it's not yet acting as a software repository but rather as a controlling eye on those that come off from sf.net , gnome.org, gnu etc.
[11:42] <sivang> (someone please correct me if I am talking rubbish)
[11:42] <uriel> sivang: ok, I understand better now
[11:43] <sivang> uriel: so if you crate a bazaar archive somewhere of your software, you can then have launchpad track changes etc
[11:43] <uriel> yea, I just was hopping it would host my bazaar archive too =)
[11:43] <sivang> uriel: which software product do you maintain?
[11:44] <sivang> Kinnison: ping, you here?
[11:44] <uriel> I'm discusing taking over: http://www.lava.net/~newsham/plan9/ from it's current maintainer, and I wanted a place to host it with baz
[11:46] <uriel> I thought of moving to sf.net, but I dislike their whole system which is also rather unreliable, so I thought maybe launchpad would let me do the same and be more baz friendly too
[11:51] <sivang> uriel: take a look at supermirror, http://www.sourcecontrol.net
[11:53] <sivang> uriel: I think it's waht you look for, you can then link lauchpad to your repo there, AFAICT :)
[11:54] <uriel> sivang: thanks, that sounds quite useful...
[11:54] <uriel> sivang: are there any plans to make launchpad more or a sf.net replacement in the future? (being able to host a home page and so on all in the same place would be nice)
[11:56] <sivang> uriel: from what I've heared, in some point in the future launchapd could be used as such, not sure if it would be the actual source repository but that's no issue with it's ability to track upstream branches, so that's a partial yes =)
[11:58] <sivang> uriel: creating some sort of a home page, per team, per product I think already is possible, you shoudl talk to one of the devels here when they are not away, and get an authoritice answers :-)
[11:59] <uriel> sivang: ok, cool :)
[11:59] <uriel> even more obviously stupid question: projects have to be related to ubuntu in any way? or any project is welcome?
[12:02] <sivang> uriel: any project, launchapd is designed for FOSS wide support =)