[12:35] <slangasek> keescook: so the comments in the kdm init script say only that "reload" reloads the configuration (the standard behavior, anyway).  It would be great if kdm did support the same re-exec behavior as gdm, but I don't currently see any evidence of that.
[12:35] <slangasek> also, the other *dm's folks mentioned don't depend on libpam0g; the only ones that do are xdm, wdm, kdm, and gdm
[01:18] <Riddell> keescook: how's that pam fix doing?  worth me staying up to let it passed unapproved?
[01:19] <keescook> Riddell: I've got it ready -- I was going to do an upgrade test and am waiting for my feisty vm to finish doing regular updates.
[01:20] <keescook> Riddell: while we're at it, can I get a beta-freeze exception for apparmor?  there are some fixes we'd like to get into beta so people have a usable logging system.
[01:23] <Riddell> keescook: could do, although I'd need to see a proper changelog and be sure it was well tested
[01:23] <Riddell> this is on the CDs?
[01:24] <keescook> Riddell: it is on the CDs, yes.
[01:35] <wasabi> So, I'm trying to reply to this guy who is talking about installing newer upstream versions of .deb files. He seems to run some repository of backports.
[01:36] <wasabi> He's trying to make a case that installing newer versions of packages which also exist in Ubuntu's repositories is a good idea, and something users should be assisted in doing.
[01:36] <Burgundavia> wasabi: is that the guys that runs getdebs?
[01:36] <wasabi> Yes. ;0
[01:36] <Burgundavia> right
[01:37] <Burgundavia> the answer for that is to point him at dholbach
[01:37] <Burgundavia> that is now his job
[01:37] <wasabi> I personally don't think users should be assisted in doing this. I don't think it's a "good idea". I think a repository like that would be better served by distributing a renamed version of the package.
[01:37] <wasabi> Oh?
[01:37] <Burgundavia> dholbach is all about growing MOTU
[01:37] <slangasek> oh, I thought you were saying dholbach's job was to control the getdebs guy
[01:37] <Burgundavia> the real answer to get these people helping MOTU
[01:38] <wasabi> MOTU provides new versions to old releases?
[01:38] <wasabi> -backports being the answer, correct?
[01:38] <Burgundavia> a lot of getdebs stuff is completely new
[01:38] <Burgundavia> lots of games
[01:38] <wasabi> Also how did you know I was talking about getdebs?
[01:38] <Burgundavia> the debs are utter crack as per policy, but they appear to install/reinstall fine, in my limited experience
[01:38] <cjwatson> if you want something in backports, getting it through MOTU is the first step
[01:39] <ajmitch> slangasek: we wouldn't wish that on him
[01:39] <Burgundavia> wasabi: it was the biggest source I can think of
[01:40] <wasabi> Yeah, so my answer appears to be the same a) new versions of existing packages outside of Ubuntu repositories is silly. If you have a reason for it, it means MOTU is too hard or your packages are crack.
[01:41] <ajmitch> wasabi: we've talked with him before, he just wants newer stuff for stable releases
[01:41] <wasabi> b) if you have no intention of distributing said packages in ubuntu at all, perhaps because they are closed source, then they should not be named the same as packages in the repository.
[01:41] <wasabi> ajmitch: Which is the definition of -backports, no?
[01:41] <ajmitch> you'd think so
[01:41] <wasabi> (this arises because he has asked me to add pinning support to gapti)
[01:41] <ajmitch> but we don't backport everything
[01:42] <wasabi> My person opinion is pinning doesn't solve any of the actual issues with this.
[01:42] <ajmitch> certainly not
[01:42] <ajmitch> then you can end up pulling half of the development release in
[01:42] <wasabi> And if you really want to distribute your own duplicates, just rename them, and install them in another directory, so as not to step on toes.
[01:43] <Fujitsu> Hm, no. Asking them to make changes is going to just kill more stuff. Better to just have them upgrading things than moving and breaking things more.
[01:43] <wasabi> And then add Conflicts so the dependency graph can be intelligent about not allowing you to do stupid stuff.
[01:43] <cjwatson> is anyone here suffering from unionfs problems on a current live CD, who'd be willing to try an updated .ko from me to see if it fixes stuff?
[01:44] <cjwatson> (basically just applying unionfs 2.1.4)
[01:45] <wasabi> My main concern is new upstream versions of packages which are depended upon by official packages. Where an official version is released with an updated local version and updated dependencies, which is incorrectly fulfilled by the backport.
[01:45] <Fujitsu> Firefox FTW.
[01:47] <ScottK> wasabi: He's been talked to repeatedly about working within the Ubuntu process and declines.
[01:47] <wasabi> Does he have a reason?
[01:47] <ScottK> It's to hard.
[01:47] <_MMA_> wasabi: Lack of time and difficulty.
[01:48] <ajmitch> and that we focus on development releases
[01:48] <ScottK> He does hang out in #ubuntu-motu and we 'discuss' it now and then.
[01:48] <wasabi> Is that a genuine complaint?
[01:48] <KaiL> eeks, something in todays gutsy-updates kills grub :/
[01:48] <ScottK> wasabi: Which?
[01:48] <cjwatson> evand: could you try http://people.ubuntu.com/~cjwatson/tmp/unionfs.ko for me, please?
[01:49] <cjwatson> evand: easiest way to try it is:
[01:49] <wasabi> His MOTU complaint.
[01:49] <cjwatson> evand: boot without 'splash' and with 'break=mount'
[01:49] <evand> cjwatson: will do, let me just confirm that I can reproduce the unionfs errors first
[01:49] <ScottK> The hardest part of packaging is understanding policy/licensing stuff.  That's the part he gets to skip if he works in his own repository.
[01:49] <cjwatson> evand: at the initramfs prompt, wait a few seconds, then 'ipconfig eth0' (or whatever your most convenient network interface is)
[01:50] <ScottK> wasabi: I don't think it's significantly harder than it needs to be.
[01:50] <evand> shouldn't that be ifconfig eth0 up
[01:50] <elmo> cjwatson: is that a typo you keep making, or is there really an ipconfig command in that enviroment?
[01:50] <evand> I think you've been in Windows too much lately
[01:50] <cjwatson> evand: wget http://91.189.90.132/~cjwatson/tmp/unionfs.ko
[01:50] <cjwatson> evand: mv unionfs.ko /lib/modules/*/ubuntu/fs/unionfs/unionfs.ko
[01:50] <cjwatson> evand: no, it really is ipconfig
[01:50] <cjwatson> and no 'up'
[01:50] <evand> oh
[01:50] <evand> ok
[01:50] <cjwatson> it's a busybox dhcp client
[01:51] <cjwatson> and yes, you need to use people.u.c's IP address too - no resolver in the initramfs
[01:51] <cjwatson> when you've done the above and checked it all worked, 'exit 0' to resume the boot
[01:52] <cjwatson> it's behaving for me so far ...
[01:53] <cjwatson> (you should confirm that that's really rookery's IP address and that I'm not evil-cjwatson trying to trick you, of course)
[01:53] <evand> hahah
[01:54] <elmo> (because you know, evil-cjwatson couldn't possily MITM a http connection)
[01:54] <cjwatson> elmo: details
[01:54] <cjwatson> scping it from rookery to somewhere local first might be a good plan
[01:54] <evand> of course I can't get unionfs to die when I want it to
[01:55] <wasabi> Our -backports suffers from this problem too, though.
[01:55] <wasabi> Oh well.
[01:59] <Amaranth> wasabi: Suffers from what problem?
[02:00] <cjwatson> KaiL: kills in what way?
[02:00] <Amaranth> wasabi: oh
[02:00] <KaiL> cjwatson, doesn't start (and says nothing)
[02:01] <Riddell> keescook: I'm off to sleep, poke early risers Mithrandir or pitti to let through pam (or cjwatson if he's still awake when you upload)
[02:01] <wasabi> Amaranth: Example: foo (1-1ubuntu1) and bar (1-1ubuntu1) bar depends on foo (>= 1-1ubuntu1). Very typical. foo is upgraded to (1-1ubuntu2), which adds some sort of local patch which bar now depends on. bar's dependency is updated. Backport of foo (2) was installed. foo now satisfies bar's dependency even though it doesn't.
[02:01] <keescook> Riddell: (dang, just missed you) okay, it's uploaded.
[02:01] <KaiL> booting rescue system, chroot, 'update-grub' and 'grub-install /dev/hda' fixes it - so either the conf brokes or something with the MBR
[02:01] <mjg59> wasabi: Isn't the version numbering for backports supposed to prevent that?
[02:01] <Riddell> keescook: oh, well
[02:02] <wasabi> Does it?
[02:02] <keescook> Riddell: ah! you're still here.  :)
[02:02] <mjg59> Oh, no, not in that case
[02:02] <Riddell> I'll wait a bit then
[02:03] <mjg59> wasabi: No, wait, I don't get that. If bar depends on foo, it should now be foo (>= 1-1ubuntu2), right?
[02:03] <wasabi> Yes.
[02:03] <wasabi> foo (2) satisfies that.
[02:03] <cjwatson> KaiL: shame that you tried both update-grub and grub-install in the same rescue run, since that means we can't tell which fixed it
[02:03] <mjg59> Why does foo (2) satisfy that?
[02:03] <wasabi> (a backport of foo was installed, new upstream version)
[02:03] <mjg59> Oh
[02:03] <wasabi> because 2 > 1?
[02:03] <KaiL> cjwatson, that's what I thought after rebooting too ;)
[02:03] <mjg59> Because it's a new numbering
[02:04] <keescook> KaiL: I had this happen a few weeks ago.  when was the last time you updated?  (I thought my problem was related to other things I was doing at the time, but I could never prove it)
[02:04] <KaiL> but as there's no new grub, but a new kernel-image, I guess, it's the conf
[02:04] <mjg59> Hm. Yes. Trying to describe a branch with a set of numbering like this is less than ideal
[02:04] <wasabi> Yeah.
[02:04] <KaiL> keescook, yesterday
[02:04] <cjwatson> wasabi: backports are always of official versions, and if both 1-1ubuntu2 and 2 are official I don't expect features to go missing in general
[02:04] <mjg59> wasabi: I suspect that the backport versions need to be glued into the release version
[02:04] <keescook> KaiL: okay, so mine was probably not the same cause.
[02:04] <mjg59> Oh. Yes, also what Colin says
[02:05] <wasabi> cjwatson: Well, it's more about new features being added.
[02:05] <cjwatson> wasabi: we did vaguely spec out an idea for feature dependencies rather than versioned dependencies eons ago (hoary or so), but it's a Hard Problem
[02:05] <wasabi> Yes. It's very hard. I don't really think it's worth solving either. The backport for foo should have been renamed.
[02:05] <cjwatson> wasabi: but you're talking about a new feature in 1-1ubuntu2 which isn't in 2. I claim that this is rare and should normally be considered a bug
[02:05] <wasabi> And conflicted or become parallel installable with the official foo.
[02:06] <wasabi> cjwatson: Oh? I'd suspect it happens all the time.
[02:06] <cjwatson> wasabi: bugs happen all the time, yes
[02:06] <wasabi> Heh.
[02:06] <wasabi> How is that a bug?
[02:06] <cjwatson> wasabi: but how is this different from the same thing happening within (say) gutsy?
[02:06] <wasabi> We add features all the time. :)
[02:06] <Riddell> keescook: accepted
[02:06] <wasabi> cjwatson: Because it can't, as far as I can tell.
[02:06] <cjwatson> you're talking about a feature being removed within a versioned line
[02:06] <keescook> Riddell: \o/  thanks for pinging me about it :)
[02:06] <cjwatson> wasabi: completely and utterly false, I'm afraid
[02:06] <KaiL> keescook, I guess something with the new kernel-images...
[02:07] <Riddell> thanks for the fast fix
[02:07] <wasabi> No, I'm talking about a feature being ADDED
[02:07] <cjwatson> wasabi: in an *earlier* version
[02:07] <cjwatson> and not added in a later version
[02:07] <cjwatson> that's equivalent to the feature being removed in the later version
[02:07] <wasabi> Yes, an ubuntu local feature. We have tons of those.
[02:07] <wasabi> Alternatives come and go. The names of things change.
[02:07] <cjwatson> yes, and any official (i.e. from Ubuntu) version should preserve those features
[02:07] <wasabi> update-scripts change calling convention.
[02:07] <wasabi> Wait let me wrap my head around that.
[02:08] <cjwatson> that's why we have a merge process rather than blindly sucking in new upstreams and throwing away all our patches
[02:08] <wasabi> We should preserve features that do not yet exist?
[02:08] <cjwatson> I give up
[02:08] <wasabi> =(
[02:08] <mjg59> wasabi: Ubuntu backports are based on Ubuntu packages.
[02:08] <cjwatson> I need a whiteboard to explain this adequates
[02:08] <cjwatson> adequately
[02:09] <mjg59> wasabi: Therefore, before you can get foo (2) as a backport, it must already be in a later version of the distribution
[02:09] <mjg59> wasabi: All the functionality that any packages depend upon should be forward ported from the version 1 package to the version 2 package
[02:09] <wasabi> I see. So the person releasing foo (2) as a backport must know to release bar (2) also?
[02:09] <mjg59> What? No.
[02:09] <wasabi> No, wait I get you.
[02:09] <wasabi> Don't worry about it. It clicked.
[02:10] <mjg59> If foo (2) satisfies the dependencies of bar (1) but it doesn't work, foo (2) is broken
[02:10] <cjwatson> right, if it actually has a reason to break bar (1), then it should use Breaks: to declare that
[02:10] <cjwatson> or maybe Conflicts:, depending on the exact situation
[02:10] <cjwatson> but it's not allowed to just break it without declaring that
[02:11] <Nafallo> mjg59: this laptop is great :-)
[02:11] <wasabi> Okay, I see what you're saying then.
[02:11] <wasabi> The problem obviously still exists for external repositories. Which is why getdebs sucks.
[02:12] <Nafallo> mjg59: you dont happen to know if the fingerprint reader is easy to make do something? ;-)
[02:13] <cjwatson> so far, this unionfs is being a good boy
[02:13] <evand> it looks like there's only one way to reproduce the unionfs bug here -- wubi
[02:13] <mjg59> Nafallo: Thinkfinger
[02:14] <evand> haven't tested that theory yet
[02:14] <cjwatson> evand: you might need to regen the CD based on that .ko
[02:14] <Nafallo> mjg59: kewl. thanks.
[02:14] <evand> cjwatson: can you elaborate?  Do you mean run a CD build with the new unionfs (whenever it gets uploaded), or remaster a CD with the ko?
[02:14] <cjwatson> evand: I meant the latter
[02:15] <cjwatson> I think giving this a decent test is a prereq for uploading it
[02:15] <evand> that would make sense, I suppose
[03:02] <nemik> is anyone running compiz willing to try a quick thing for me please?
[03:03] <nemik> run terminal from Applications -> Accessories -> Terminal. then maximise it with the little top-right box icon
[03:03] <nemik> is it totally maximised or are sides and top kinda cut off?
[03:03] <mneptok> "With the 'My Trojans And Malware' subscription service, Vista users can be assured that the malicious software they use has been provided by authentic Russian identity thieves and Afghani opium cartels."
[03:05] <Fujitsu> mneptok: Haven't they ever heard of cross-platform compatibility? I'm feeling left out :(
[03:06] <mneptok> Fujitsu: SuSE and Ximian will be implementing it

[03:07] <Fujitsu> Heheh
[03:09] <zul> mneptok, how?
[03:09] <mneptok> zul: don't worry about it. finish eating your Dana and you can have ice cream.
[03:12] <zul> nice..
[03:13] <nemik> anyone running compiz?
[03:14] <zul> not here
[03:21] <pipegeek> Howdy, all.
[03:21] <pipegeek> Just tried to do an online ext2-resize on feisty, and was told that online resizing for ext2 wasn't enabled in the kernel.  I'll go ahead and enable/recompile when I have time..... but why should this be?  And wasn't it enabled as recently as this Summer?
[03:22] <pipegeek> this is IA32, btw
[03:24] <cjwatson> pipegeek: it's an ext3 feature, I believe
[03:24] <pipegeek> What is?
[03:25] <pipegeek> resizing?
[03:25] <cjwatson> online resizing
[03:25] <pipegeek> That's odd.  OK, let me try something then
[03:25] <cjwatson> the feature definition in the kernel is called EXT3_FEATURE_COMPAT_RESIZE_INODE
[03:26] <pipegeek> I feel like a big fat doofus.
[03:26] <pipegeek> Thank you, cjwatson.
[03:26] <cjwatson> no worries
[03:26] <nemik> is anyone running compiz?
[03:27] <bddebian> nemik: No one that's sane :-)
[03:29] <nemik> lol, makes a lot of sense
[03:30] <nemik> it's frustrating as all hell
[03:30] <nemik> making it default is gonna be lols
[03:36] <mneptok> if you use the word "lols" in seriousness, Conpiz is not ready for you. ;)
[03:36] <mneptok> *Compiz
[03:36] <mneptok> i wonder if we can have a "You must be this tall to ride this ride," dialog for the Desktop Effects syspref
[03:36] <StevenK> lamont: It looks like kohnen and primero hate the world.
[03:42] <bddebian> heh
[03:45] <nemik> haha, nice
[03:59] <mneptok> nemik: sorry, couldn't resist. and yes, i'm already aware i'm an ass, TYVM. ;)
[04:05] <nemik> mneptok: nah, it's cool. i just use it casually
[04:10] <mneptok> nemik: doesn't negate the fact i'm an idiot :)
[04:36] <Fujitsu> Has anybody seen complete screen corruption early in alternate installation on i915?
[04:36] <Fujitsu> (tried yesterday's nightly, worked OK with Feisty and earlier)
[04:39] <fen> nemik, i run compiz for two reasons alone, 1 im a very visual person and the desktop cube gives my the ability to visually map out my workspace, 2 proper translucency(sp?) in terminals, when you run as many terminals and use them as much as i do black and white becomes an eye strain.
[04:42] <fen> that and theres nothing wrong with eye candly as long as it doesn't get in the way.
[04:42] <_MMA_> Fujitsu:
[04:42] <_MMA_> I have
[04:42] <Fujitsu> Bah, running compiz was a mistake, it seems... My  maximised terminal is now all bouncy :(
[04:43] <Fujitsu> _MMA_: Is there a bug on it, or should I file one?
[04:43] <fen> Fujitsu: bouncy?
[04:43] <Fujitsu> fen: Yeah, there's a small gap on either side of the window, so it's trying to snap to both edges, but can't.
[04:43] <_MMA_> I saw it with the Ubuntu Studio dailies. Colin knows about it.
[04:43] <Fujitsu> _MMA_: Great. Thanks.
[04:44] <fen> Fujitsu: using compiz from the gutsy repo?
[04:44] <Fujitsu> fen: Yes.
[04:44] <mneptok> Fujitsu: not using the new "intel" driver?
[04:44] <Fujitsu> gnome-terminal has a resizing limitation, so doesn't quite fit.
[04:44] <Fujitsu> mneptok: I am.
[04:44] <mneptok> k
[04:44] <cjwatson> _MMA_: (but it's not something I can do anything about myself)
[04:45] <fen> Fujitsu: open ccsm and disable inverted snap in the wobbly plugin.
[04:45] <cjwatson> _MMA_: Fujitsu said "early" though, so it may not be the same thing. Yours is most of the way through installation.
[04:45] <mneptok> cjwatson: are you not at home ATM?
[04:45] <Fujitsu> cjwatson: Well, soon after the base installation finishes.
[04:45] <cjwatson> mneptok: I am
[04:45] <cjwatson> Fujitsu: ah, yeah, same thing then
[04:45] <mneptok> cjwatson: if you are, you arce hereby commanded to bed.
[04:45] <mneptok> *are
[04:45] <_MMA_> cjwatson: Hmm... Yeah. Mine happens when xorg gets setup.
[04:45] <Fujitsu> I have photos, if it helps.
[04:46] <_MMA_> cjwatson: Man. Not getting much sleep are ya? :)
[04:46] <cjwatson> mneptok: I wish. I'm not up for fun
[04:47] <Fujitsu> fen: Ah, thanks, turning that off fixed it.
[04:47] <fen> np.
[04:47] <mneptok> cjwatson: anything i can do from a slightly less late tz?
[04:48] <fen> setting up xgl & fglrx for dual screen compositing was an utter bitch.
[04:49] <fen> on the brightside i now know a good deal of fglrx driver options and the fundamentals of mesa
[04:51] <cjwatson> mneptok: not a lot unfortunately, I'm trying to beat wubi into shape
[04:51] <cjwatson> but thanks for the offer
[04:54] <_MMA_> cjwatson: Should I look at installer bugs to make sure the Intel issue I have has been reported?
[04:57] <cjwatson> _MMA_: it's been reported a zillion times on xresprobe / xorg / xorg-server / blah
[04:57] <cjwatson> it isn't an installer bug
[04:58] <nemik> fen, Fujitsu: gvim has the same problem
[04:58] <Fujitsu> nemik: Not surprising.
[04:59] <nemik> but firefox, calculator, etc are fine
[04:59] <_MMA_> cjwatson: Ok. I figured but wasnt sure. :) Please try to get some rest.
[04:59] <nemik> Fujitsu: inverted snap is disabled already for me...
[05:01] <nemik> Fujitsu: does negative plugin work for you? the Super+N ? I get black windows
[05:01] <Fujitsu> nemik: Negative works for me.
[05:01] <nemik> gutsy repo compiz? what driver/card?
[05:02] <Fujitsu> Latest gutsy compiz, intel on i915.
[05:03] <cjwatson> _MMA_: I appreciate your concern, but I would find it easier if everyone stopped nagging me to go to sleep. :)
[05:03] <nemik> ah. i got a i965, this thing is all messed up. xv doesn't work either. or negative. no wonder it was blacklisted i guess
[05:05] <_MMA_> cjwatson: Yeah. I did think that after I posted. :)
[06:46] <stdin> hmm, isn't there some old archive repo for horay somewhere?
[06:47] <StevenK> old-releases.ubuntu.com
[06:54] <stdin> ahh, thanks
[07:45] <pitti> Good morning
[07:47] <evand> morning pitti
[07:47] <StevenK> Morning pitti
[07:48] <StevenK> pitti: libgbf-1-0 and libgdamm-3.0-7 can be NBS'd out when you're ready.
[07:48] <StevenK> pitti: And openoffice.org-l10n-common (blink) is on the list.
[07:48] <pitti> StevenK: yeah, both oo.o and oo.o-l10n FTBFSed
[07:49] <pitti> calc: still here?
[07:49] <StevenK> Neat.
[08:23] <stgraber> pitti: Morning, yesterday you added a 20070924.1 ubuntu desktop ISO set that didn't exist on cdimage, I renamed it to 20070924.3 which is I think what you wanted to add
[08:23] <pitti> stgraber: hm, weird; I did start a new live build .1, but evand started another one
[08:25] <evand> cjwatson ended up doing it, but I think the resulting image was 20070925.
[08:26] <stgraber> pitti: there was .1 for alternate but .3 for desktop (built at ~21:00 UTC)
[08:27] <pitti> stgraber: ah, I see; weird
[08:30] <stgraber> oh, OOo build failed
[08:30] <stgraber> checking for curl-config... no
[08:30] <stgraber> configure: error: install curl to run this script
[08:30] <stgraber> make[1] : *** [stamp/build]  Error 1
[08:30] <pitti> stgraber: known
[08:30] <pitti> stgraber: fixed version is in the queue, but too late to take chances now
[08:31] <StevenK> pitti: Missing Build-Depends?
[08:31] <stgraber> indeed, 12hours to build a new OOo is uhm, long :)
[08:32] <dholbach> good morning
[08:32] <stgraber> hi dholbach
[08:34] <dholbach> hey stgraber
[08:35] <ajmitch> hi dholbach
[08:35] <dholbach> hey ajmitch
[08:35] <stgraber> pitti: are we going to have a new build in the next two hours or can I test the current one (20070925) ?
[08:36] <pitti> stgraber: currently building new ubuntu-meta, so we should have final candidate images in ~ 4 hours
[08:37] <stgraber> ok
[08:38] <pitti> stgraber: testing the current ones would be helpful for verifying the new wpasupplicant
[08:39] <stgraber> ok, I'm running the new wpa_supplicant on my laptop and it seems to work correctly (but I should test its behaviour on suspend/resume a bit more)
[08:47] <ScottK> pitti: Are we back to asking you archive admins to process syncs or am I authorized to use the magic script?
[08:49] <pitti> ScottK: I'd prefer using sync-source for packages where it works with, but in general I don't have much of a problem with the script
[08:50] <ScottK> pitti: If the orig.tar.gz is newer than we have and someone uploaded it to a PPA is a case where sync-source won't work, right?
[08:50] <ScottK> Or did that get fixed?
[08:50] <pitti> right
[08:50] <ScottK> OK.  I'll do that one with by hand then.
[08:56] <kagou> good morning
[09:01] <stgraber> pitti: default wallpaper is missing on 20070925
[09:01] <pitti> stgraber: known, dholbach is on it
[09:01] <pitti> stgraber: once this is in, I'll start two publishers for ubuntu-meta and wallpapers and build new CDs
[09:02] <stgraber> ok
[09:02] <rohan> the wallpaper remains that dark brown one ?
[09:04] <dholbach> pitti, stgraber: doing a test build and then will upload
[09:06] <dholbach> pitti, stgraber: uploaded
[09:07] <kagou> it's beautiful :)
[09:08] <pitti> dholbach: why version .17?
[09:08] <dholbach> pitti: I did not want to mangle the changelog - do you want me to change it?
[09:09] <pitti> dholbach: it's a bit strange, but *shrug*, debdiff looks good enough
[09:09] <dholbach> ok great
[09:09] <pitti> dholbach: so, your desktop wallpaper is back on upgrade?
[09:10] <dholbach> pitti: yes
[09:12] <stgraber> pitti: should I have fixed unionfs on 20070925 ?
[09:13] <pitti> stgraber: not sure, please check the version of linux-ubuntu-modules
[09:14] <stgraber> only 12.31 so I don't think so
[09:15] <stgraber> ok, I'll wait till next ISO as this one is getting stuck while scanning disks (and looking at dmesg it seems to be an unionfs bug)
[09:15] <pitti> stgraber: just try booting it again? that helped for me yesterday
[09:16] <\sh> hmmm...xrandr dual head mode is completly broken..or vmware doesn't honor new xorg features...
[09:17] <\sh> setting up dualhead works on my desktop here...starting vmware, switching to fullscreen and switching back but brings the monitors back to clone mode
[09:17] <rohan> any kernel packager around here ?
[09:19] <stgraber> pitti: indeed, second try worked :)
[09:19] <rohan> just wanted to draw attention to https://bugs.launchpad.net/bugs/automute
[09:27] <kagou> dholbach, "dropped Elephant pic, no space for that" -> lol
[09:28] <dholbach> kagou: it's a very nice pic, it's a shame to drop it
[09:28] <pitti> but, but, this is gutsy gibbon, not electric elephant...
[09:28] <dholbach> check it out at http://daniel.holba.ch/temp
[09:31] <rohan> dholbach: elephant-skin.jpg going to be the default gutsy wallpaper ?
[09:31] <rohan> it'd be beautiful
[09:31] <dholbach> rohan: unfortunately not; you'll need to talk to kwwii about that
[09:32] <rohan> awww ok
[09:32] <rohan> so the default wallpaper remains the dark one ? that's nice too, just a bit too dark ;)
[09:34] <pitti> minghua: almost the entire side, it looks like
[09:34] <dholbach> maybe we should save it for 'eclectic elephant'
[09:36] <minghua> pitti: To be honest, I can't really tell that's an elephant.  I would believe if someone say it's from a hippo, too. :-)
[10:19] <kagou> is pm-utils planed to be included in default configuration ?
[10:19] <kagou> it's very usefull for notebook.
[10:21] <kagou> after trying to put my notebook on sleep, an applet invit me to visit http://people.freedesktop.org/~hughsient/quirk/ here i find an script http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-debug.html that ask me to put a line on /etc/pm/config.d/unload_modules and now all is working
[10:25] <seb128> kagou: that looks like a debug feature for unstable cycle
[10:25] <seb128> kagou: shouldn't those quirk updates rather pushed in gutsy if required?
[10:28] <kagou> don't know
[10:34] <DamienCassou> hi
[10:37] <DamienCassou> Can someone tell me what is the status of https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/144207
[10:37] <ubotu> Launchpad bug 144207 in debian-installer "gusty installation failed with "Hash Sum mismatch"" [Undecided,New] 
[10:41] <DamienCassou> is there anybody out there?
[10:43] <pitti> hm, no idea about that, it doesn't seem to happen generally
[10:44] <pitti> Sep 23 12:37:29 in-target: Failed to fetch cdrom:[Kubuntu 7.10 _Gutsy Gibbon_ - Alpha i386 (20070923)] /pool/main/a/acpi/acpi_0.09-3ubuntu1_i386.deb Hash Sum mismatch
[10:44] <pitti> mvo: ^ any idea?
[10:44] <DamienCassou> someone told me yesterday (on #ubuntu+1) that a discussion about that problem happened here yesterday
[10:44] <mvo> pitti: uh, bad burn? but let me read the bugreport first
[10:44] <DamienCassou> it was gnomefreak if I remember correctly. He told me two people here discussed about that
[10:45] <DamienCassou> ok
[10:48] <DamienCassou> mvo: has you can see, it can't be a burning problem
[10:50] <mvo> DamienCassou, pitti: I think I overheard some squashfs issue on the livecd yesterday, maybe its releated?
[10:50] <DamienCassou> I used only alternate
[10:51] <pitti> it's alternate/
[10:51] <pitti> ?
[10:51] <pitti> right
[10:51] <mvo> og
[10:51] <mvo> ok
[10:51] <DamienCassou> and differerent versions (not from yesterday)
[10:52] <mvo> DamienCassou: but only kubuntu? I will sync a image then
[10:53] <DamienCassou> no, not only
[10:53] <DamienCassou> in the bug report, I say it also happens on Ubuntu daily from 2007-09-23
[10:58] <pitti> FYI: Rebuilding all CD images (the final beta ones, hopefully)
[10:59] <DamienCassou> pitti: tell me when I can test something
[10:59] <DamienCassou> pitti: thank you
[10:59] <pitti> DamienCassou: nothing on that image has a particular bug fix in that direction, though
[11:00] <pitti> DamienCassou: new Ubuntu alternates ETA: 15 minutes
[11:00] <liw> pitti, you're building images that are going to appear on cdimage.ubuntu.com?
[11:01] <pitti> liw: right
[11:01] <DamienCassou> I was trying to burn a mini image, but today I can't get access to my cdburner. I always have a message saying it's busy. lsof /dev/cdrw returns nothing
[11:01] <liw> pitti, so I shouldn't waste my time spending the current ones, I guess, if new ones are about to appear
[11:01] <pitti> liw: is your 'work boostrapping' far enough to help with CD testing? did you already talk to heno about that?
[11:02] <pitti> liw: right; alternates are quick to build, we shuold start with those
[11:03] <liw> pitti, I did talk and I've done some initial testing yesterday (gutsy-desktop-i386 from "current" as of about 20 hours ago), and will try to do some actual testing and reporting today
[11:03] <pitti> liw: great, thanks; you have your iso-testing account etc.?
[11:04] <liw> pitti, er, um, maybe?
[11:04] <pitti> liw: on https://iso.qa.stgraber.org, I mean
[11:04] <liw> pitti, ah, I made one yesterday
[11:04] <pitti> for reporting results
[11:04] <pitti> good
[11:05] <liw> I even cliced "ok" on "cd check"
[11:05] <liw> but I think I need to figure out a clever way of making sure I am testing the version in the tracker
[11:06] <pitti> liw: if you mount it, then you can look into .disk/info
[11:06] <pitti> liw: or you md5sum the image and compare it to the md5 file on cdimage
[11:07] <liw> pitti, thanks, that'll do for now; with "clever" I meant "automated so that I never, ever need to do any manual work every again, like, not once more" :)
[11:07] <pitti> liw: add the loop-mounting, cat, and umount to your scripts which jigdo/rsync CD images? :)
[11:08] <Riddell> sladen: how did that usplash change go?
[11:08] <liw> but I'll figure something out for if and when I'll automate the whole testing process
[11:08] <pitti> crud, amd64 alternate is within limits now, but i386 is still oversized
[11:08] <Mithrandir> or use isoinfo to extract the .disk/info file
[11:08] <Mithrandir> and make that tie into iso.qa.stgraber.org
[11:09] <pitti> ah, the i386 one still has ooo-base
[11:09] <norsetto> who is taking care of mirrors, for issues like those in bug 144511? mirrors@ubuntu.com?
[11:09] <ubotu> Launchpad bug 144511 in ubuntu "default korean mirror has been dead for one month" [Undecided,New]  https://launchpad.net/bugs/144511
[11:09] <Mirv> could people with non-english gutsy check bug 139370, I think it's really important if it's not just me
[11:09] <ubotu> Launchpad bug 139370 in nautilus "[gutsy]  "Home Folder" not translated, even though translation exists" [Low,Confirmed]  https://launchpad.net/bugs/139370
[11:09] <sladen> Riddell: nobody has complained and none of the people with broken systems have jumped up in praise of the lord either with cries of it being sorted for them
[11:09] <Mirv> too bad most developers seem to use English, while majority of ordinary users not :(
[11:09] <sladen> Riddell: I'm going to try with a vmware/qemu when I get back to real bandwidth
[11:10] <pitti> so, 20070925 alternate will not be the final image, but shuold be good to test
[11:10] <Mithrandir> Mirv: it's confirmed, yes.
[11:11] <Mirv> Mithrandir: yep, seb128 just now asked there if anyone else is still seeing it
[11:11] <Mirv> and I don't think it's low if it affects every non-English user, that's why more testing would be nice
[11:12] <seb128> Mirv: I'm using french and it's correctly translated
[11:13] <Mirv> seb128: hmm, that's weird then. the translation is there also for Finnish, in nautilus, and it was confirmed by a Spanish user
[11:13] <seb128> Mirv: do you mean that you still get the bug?
[11:14] <Mirv> seb128: yes, my gutsy is up to date, both a clean installation from two weeks and this feisty I upgraded last Thursday
[11:15] <seb128> Mirv: maybe you can try to debug it? I don't get the issue here
[11:16] <Mirv> seb128: ok, I'll try. can you say if the string is anyway coming from Nautilus, and from Nautilus's strings?
[11:17] <seb128> Mirv: it's coming from rosetta's language pack
[11:17] <Mirv> seb128: yeah, but if the string is represented by nautilus (the program) and translated from nautilus mo files
[11:18] <Mirv> or some other package
[11:19] <seb128> Mirv: are you speaking about the icon on the desktop or in the places menu?
[11:19] <Mirv> since the same string is translated eg. in Nautilus file browser's "Go" menu
[11:19] <Mirv> Places
[11:20] <seb128> places is gnome-panel
[11:20] <seb128> that's not the same translation file than nautilus
[11:21] <seb128> strings are not shared between component, that doesn't work this way
[11:21] <Mirv> ah, yes that's what I meant, thanks
[11:24] <DamienCassou> pitti: can you tell me when the image is ready please?
[11:24] <pitti> DamienCassou: they are
[11:24] <DamienCassou> pitti: where can I download them please?
[11:26] <DamienCassou> pitti: I can't find them neither on cdimages* nor on iso.qa*
[11:26] <pitti> DamienCassou: cdimage.ubuntu.com, as usual
[11:27] <DamienCassou> pitti: ok. I download http://cdimage.ubuntu.com/daily/20070925/gutsy-alternate-i386.iso
[11:29] <pitti> DamienCassou: NB that it's still too big, I'm fixing that
[11:30] <sladen> Riddell: what's the exact name of the other kubuntu/xubuntu/foobuntu packages that need revving for usplash artwork;  the naming isn't consistent
[11:31] <DamienCassou> pitti: I'm currently trying the mini image. Will update the bug report when this is done. After that, I will try your new image
[11:36] <TheMuso> sladen: There is one for ubuntustudio, but we have other fixes coming for that, so if you would mind just telling me what needs changing, I'll encorporate it into the upload.
[11:37] <gnomefreak> DamienCassou: i told hobbsee not you ;)
[11:37] <Riddell> sladen: kubuntu-artwork-usplash gobuntu-artwork-usplash edubuntu-artwork-usplash xubuntu-artwork-usplash
[11:37] <Riddell> looks consistent to me :)
[11:37] <DamienCassou> gnomefreak: I don't understand
[11:38] <TheMuso> Riddell: Except for usplash-theme-ubuntu and usplash-theme-debian and usplash-theme-ubuntustudio :p
[11:38] <Riddell> seems the -artwork packages win on numbers
[11:38] <TheMuso> oh well.
[11:38] <Riddell> sladen: going by kubuntu they need the .c file copied to the appropriate place, then all the colours changed throughout the file
[11:38] <gnomefreak> DamienCassou: i told hobsee that they were talking about it. i only told you that i saw the conversation because she asked me about it
[11:38] <Riddell> that really should be fixed to be easier to change, it would be trivial
[11:39] <DamienCassou> gnomefreak: does that change anything?
[11:39] <TheMuso> Riddell: I've done it for ubuntustudio, so the art folks can do it themselves. Just a matter of breaking them out into a header, and commenting/documenting appropriately.
[11:40] <Riddell> yep
[11:49] <TheMuso> sladen: nm, I see the only thing you changef ro usplash-theme-ubuntu was the x pos of the progress bar, which will need to be different for the ubuntustudio theme anyway.
[11:53] <sladen> TheMuso: that was the only value I found that didn't satisfy two times A plus B equals C.  Has the misalignment even been reported on studio?
[11:59] <TheMuso> sladen: No, but I thought it was a change somewhere else in the code. The ubuntustudio usplash screen is somewhat different to ubuntu's, but I'll keep that change you made in mind should we need it, thanks.
[11:59] <tepsipakki> pitti: I'll update the new ati & nv to the queue so they are ready for post-beta
[11:59] <pitti> tepsipakki: please
[12:00] <tepsipakki> done
[12:02] <sladen> TheMuso: I suspect it's the symptom of blinding copying and pasting hard-coded values.  One fat-fingered mistake gets spread everywhere
[12:02] <sladen> TheMuso: ironically, you might be the only person that didn't "blindly" copy that across ;-)
[12:05] <TheMuso> sladen: As I said earlier, I've broken out the settings for progressbar etc into a separate header, and thats now in the hands of the art guys to position it where they want it.
[12:24] <dholbach> Tonio_: thanks for uploading that patch
[12:25] <ogra> pitti, hmm, seems i didnt get any fresh livefs the last three days
[12:26] <pitti> ogra: oh? can you please check edubuntu livefs logs?
[12:26] <ogra> the isos are nearly the same, but there should be a lot gone from -desktop actually
[12:27] <pitti> ogra: nothing on http://people.ubuntu.com/~ubuntu-archive/testing/gutsy_probs.html
[12:27] <pitti> ogra: so it might be an uninstallability due to seed blacklists, or so?
[12:27] <ogra> when did the publisher run last ?
[12:28] <ogra> dia-gnome and scribus should be off the cd since yesterday
[12:28] <ogra> they show up in manifest
[12:34] <pitti> ogra: it's running all the time
[12:34] <pitti> ogra: dia-gnome> Task: edubuntu-desktop-kde, edubuntu-ship-addon
[12:35] <pitti> ogra: likewise for scribus
[12:35] <pitti> hmm
[12:35] <mvo> DamienCassou: I'm just trying to reproduce #144207 here and so far I'm not lucky I assume you did not do anything special to trigger the bug?
[12:36] <DamienCassou> nothing
[12:36] <ogra> pitti, yeah, but neither -live nor -desktop
[12:36] <DamienCassou> I'm trying to reproduce it with the daily alternate ubuntu currently
[12:36] <ogra> it shouldnt get picked up
[12:36] <DamienCassou> DamienCassou: I'm trying to reproduce it with the daily alternate ubuntu currently
[12:37] <DamienCassou> mvo: I'm trying to reproduce it with the daily alternate ubuntu currently :-)
[12:37] <DamienCassou> mvo: will tell you when I have a result
[12:37] <pitti> ogra: your latest livefs was built successfully?
[12:37] <ogra> i thought so
[12:38] <pitti> seems like it
[12:39] <ogra> http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/gutsy/edubuntu/latest/livecd-20070924-i386.out looks fine to me
[12:40] <ogra> Get:740 http://ftpmaster.internal gutsy/main edubuntu-desktop 1.44 [16.4kB] 
[12:40] <ogra> aha+
[12:40] <ogra> that should be 1.45
[12:40] <pitti> too old?
[12:40] <ogra> yeah
[12:40] <pitti> hm, that's in the archive
[12:40] <ogra> weird
[12:41] <pitti> ogra: was it current at the live fs build time yesterday?
[12:41] <ogra> livecd-20070924-i386.out                           24-Sep-2007 01:17  8.5M
[12:41] <ogra> is that UTC ?
[12:42] <ogra> if that 1am it wasnt there indeed :)
[12:45] <DamienCassou> pitti: mvo: the bug appeared again with the current daily iso
[12:45] <ogra> pitti, sorry, i was to blind to notice the time difference ... can you trigger another live for me ?
[12:45] <mvo> DamienCassou: strange, I can not reproduce it here, let me try again on a different machine
[12:45] <DamienCassou> pitti: mvo: I didn't rebooted my computer so that you can ask me to try things
[12:46] <mvo> DamienCassou: sha256 of /cdrom/pool/main/a/acpi/acpi_0.09-3ubuntu1_i386.deb
[12:46] <mvo> sha256sum that is
[12:46] <pitti> ogra: of course
[12:47] <ogra> thanks :)
[12:47] <pitti> ogra: but I just triggered new builds about 1.5 hours ago, they should be good for you
[12:47] <DamienCassou> mvo: sha256sum not found
[12:47] <ogra> ah, great
[12:47] <pitti> ogra: it's building xubuntu now, your images shuold be ready
[12:47] <ogra> what happened to alternate ? it grew by 1M for me
[12:47] <pitti> http://cdimage.ubuntu.com/edubuntu/daily-live/20070925/
[12:47] <pitti> \o/ well within the limits
[12:47] <ogra> gutsy-desktop-i386.iso          25-Sep-2007 11:41  695M
[12:48] <mvo> DamienCassou: right, minimal environment. hm, does "python -c 'import apt_pkg' " work?
[12:48] <pitti> ogra: so now we just need to fix your alternate/i386, then we are good
[12:48] <DamienCassou> python not found
[12:49] <DamienCassou> maybe I need to chroot?
[12:49] <ogra> pitti, what changed in ubuntu ? i didnt do any changes yesterday and it was 700M (still 200k oversized or so)
[12:49] <ogra> now iots 701
[12:49] <pitti> ogra: unsure
[12:49] <DamienCassou> mvo: python not found. Do I need to chroot?
[12:50] <ogra> pitti, i was counting that i inherit some of the 4M you have to kill from your alternate and was hoping it would be enough to get my i386 ready
[12:50] <mvo> DamienCassou: its worth a try, also if it failed in acpi unpack, then there is going to be little in the chroot
[12:50] <pitti> ogra: OO.o failed to build
[12:50] <mvo> DamienCassou: but checking is certanly a good idea
[12:50] <ogra> s/counting/counting on the fact/
[12:50] <pitti> ogra: so what I did now was to remove openoffice.org-base from ubuntu-desktop
[12:50] <ogra> argh
[12:50] <DamienCassou> mvo: chroot /target
[12:51] <ogra> so you will have a majorly oversized CD sooon ?
[12:51] <pitti> http://codebrowse.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.gutsy/revision/1092
[12:51] <pitti> ogra: I'll put it back in after beta, when we'll get the slightly downsized OOo
[12:51] <ogra> yup
[12:51] <ogra> should i do the same ?
[12:52] <pitti> ogra: not sure, your call
[12:52] <ogra> i mean 1M isnt the world ...
[12:52] <pitti> ogra: depends on whether you have anything else to kick off ship
[12:52] <ogra> i can get that by pngcrushing some more images soemwhere i bet :)
[12:52] <DamienCassou> mvo: sha256sum /cdrom/pool/main/a/acpi/acpi_0.09-3ubuntu1_i386.deb
[12:52] <ogra> btw did someone look into gnome-users-guide if we can do anything there ?
[12:53] <DamienCassou> mvo: 7d38f61b51...
[12:53] <pitti> ogra: if you need to rebuild e-meta, it'll take 2 hours, so fiddling -ship might be better
[12:53] <pitti> ogra: not yet
[12:53] <ogra> 14M feels a bit big, there are not *that* many screenshots
[12:53] <DamienCassou> mvo: what do you think?
[12:53] <mvo> DamienCassou: could you please put the full checksum to paste.ubuntu.com?
[12:53] <ogra> pitti, well, there are some uncertainities in my installer part that might need a meta rebuild anyway
[12:53] <DamienCassou> let me try
[12:54] <ogra> so i'm not to worried about that one :)
[12:54] <pitti> ogra: well, it has per-language screenshots, that's it
[12:54] <ogra> argh
[12:55] <ogra> sounds like a good candidate for a langpack-screenshots-<$lang> package
[12:56] <mvo> DamienCassou: lets move this to a private chat, I will have more questions for you and I don't want to spam the channel too much :)
[12:57] <DamienCassou> mvo: http://paste.ubuntu.com/430/
[01:07] <cirkit> is it possible to remove my ban from #ubuntu and #ubuntu+1? those niggers banned me for no reason
[01:07] <twinoatl> mvo, it's me
[01:07] <mvo> hello twinoatl
[01:09] <DamienCassou> mvo, I'm now trying to install ubuntu on the other computer
[01:10] <Chipzz> cirkit: "those niggers" probably did not ban you for no reason. The fact that you call them "those niggers" rather proves that they most likely HAD a reason. And this is not the place to come whine about your ban there, kthxbye
[01:10] <mvo> thanks DamienCassou
[01:11] <cirkit> Chipzz, I demand an apology letter immediately. I am Mark Shuttleworth's uncle and do not appreciate this kind of service.
[01:11] <Chipzz> omg, this is hilarious :)
[01:11] <ogra> heh
[01:12] <DamienCassou> mvo, what about the part of the bug report which deals with apd.html ?
[01:12] <cirkit> well then, I will just go ahead and format my Ubuntu install and use Gentoo instead ... Ubuntu has lost another user ;)
[01:13] <mvo> DamienCassou: I wonder if its bad hardware in some form, but the fact that it always fails on the same file is puzzling
[01:13] <Chipzz> mark shuttleworths uncle using gentoo... rrrrrrright :)
[01:13] <mvo> any ops in here?
[01:13] <Pici> cirkit: If you wish to contest your ban, you can join #ubuntu-ops and wait for an operator.
[01:14] <DamienCassou> mvo, during install, the problematic file is acpi*.deb. But during the CD check, it is apd.html
[01:14] <DamienCassou> mvo, and always these files. Whatever the ISO I burn
[01:19] <DamienCassou> mvo, I think the installation of acpi happened and it worked. I'm continuing to be sure
[01:21] <mvo> DamienCassou: ok, so it looks like there is something special about this particular machine
[01:21] <DamienCassou> mvo, I think so. What can I do?
[01:22] <pitti> ogra: any plan yet?
[01:24] <ogra> pitti, nope, looking into ship
[01:28] <ogra> hm, there is not much in ship-live
[01:28] <pitti> ogra: live is good
[01:28] <ogra> build-essential would probably work
[01:28] <pitti> ogra: you need to downsize ship, right/
[01:28] <pitti> ?
[01:28] <TeTeT> iwj: I tested the slmodemd on my T40p yesterday, no change - still reports NO CONNECT
[01:28] <ogra> oh, right
[01:28] <ogra> sorry, confused atm
[01:29] <pitti> heno, stgraber: FYI, xubuntu and kubuntu builds should be good now, tracker updated
[01:29] <mvo> DamienCassou: not sure, let me think about it over lunch
[01:29] <ogra> hah !
[01:29] <Riddell> pitti: alternate and desktop?
[01:29] <pitti> heno: will you coordinate testing or shall I pingsomewhere else?
[01:29] <pitti> Riddell: yep, both
[01:29] <Riddell> thanks
[01:29] <pitti> Riddell: at least from my side (size-wise, etc.)
[01:30] <Riddell> kubuntu never was overweight :)
[01:30] <ogra> meh
[01:30] <pitti> ogra: ah, php
[01:30] <pitti> ogra: but only .5 MB
[01:30] <DamienCassou> mvo, ok, thank you
[01:30] <ogra> 400k only :/
[01:30] <ogra> well, thats half of what i need :)
[01:31] <ogra> hmm, can i drop postfix ... ?
[01:31] <pitti> ogra: if nothing else helps, drop bzr?
[01:31] <DamienCassou> mvo, do you know if I can install ubuntu using the manual approach for acpi as we did previously?
[01:32] <ogra> well, i'd prefer dropping postfix, but i'm not sure thats a good idea
[01:32] <mvo> DamienCassou: out of curiosty, does the same (or a similar) error happen on the desktop cd install? it uses a different method for instlaling
[01:32] <DamienCassou> mvo, I never tried desktop installation
[01:33] <mvo> ok
[01:33] <DamienCassou> mvo, do you want me to try?
[01:33] <DamienCassou> mvo, ok, see you
[01:33] <mvo> yes :)
[01:34] <stgraber> pitti: ok, cool
[01:34] <pitti> http://cdimage.ubuntu.com/daily/20070925.1/
[01:34] <pitti> 700 MB i386
[01:35] <pitti> stgraber, heno: ^ good for testing
[01:36] <liw> pitti, so I should test that, too?
[01:36] <pitti> liw: if you can, sure; I'm testing amd64 alternate+desktop
[01:37] <liw> I have an amd64 (= also i386) machine that is not being used for anything right now, so I'm happy to test whatever works on it
[01:37] <pitti> liw: i386 would be good
[01:37] <pitti> liw: if you have time afterwards to test some more amd64, so much the better :)
[01:42] <pitti> mvo: do you have time to do new upgrade tests? the previous one had a serious bug, which should now be fixed
[01:43] <pitti> ogra: please tell me when you finished mangling seeds, since this requires some publisher mangling
[01:43] <ogra> 10 mins
[01:43] <ogra> i'm on it
[01:43] <pitti> ogra: right, I'm not hurrying; just coordinating
[01:44] <ogra> yeah, already pushing
[01:44] <ogra> i'D like to have edubuntu ready asap for various raisins :)
[01:45] <pitti> ogra: oh, don't talk as if we had a release in two days or so
[01:45] <ogra> (and currants :) )
[01:45] <ogra> nah, i wouldnt dare :)
[01:45] <ogra> push done
[01:50] <pitti> ogra: publisher started
[01:50] <\sh> well, anyone in here who needs a good sysadmin with debian packaging knowledge, rpm packaging knowledge, etc.?
[01:50] <pitti> ogra: so what did you remove?
[01:50] <ogra> postfix and the second apache
[01:50] <pitti> ogra: I'd like to check the Task: headers after the first and second publisher run before building CDs
[01:50] <pitti> ah
[01:51] <ogra> if we get at leats 1M from oo.o i'll add it back
[01:51] <sladen> ogra / pitti: bzr is all python text-files, bz2'ing it saves about a 1/4. (0.3MB)
[01:51] <heno> pitti: thanks I will coordinate
[01:51] <sladen> if it gets that close
[01:51] <pitti> ogra: should drop by some 4.5 MB
[01:51] <ogra> and i highly hope for that one M :)
[01:51] <pitti> ogra: erm, not Task: of course (it's only ship)
[01:51] <heno> pitti: though poking people from different directions doesn't hurt :)
[01:51] <ogra> well, that should suffice for even another small language :)
[01:52] <pitti> ogra: so your edubuntu lives are good for testing, right?
[01:52] <ogra> yep
[01:52] <ogra> and server should be fine with the next build
[01:53] <ogra> i should have learned now that we'll manage somehow, but i still think we'll never get them down to the right size ... every release again :P
[01:54] <mvo> pitti: yes, after lunch
[01:55] <pitti> mvo: supi, danke
[01:56] <pitti> heno, stgraber: just for the records, tracker is up to date with CD versions and disabled selections now
[01:56] <heno> pitti: great, thanks!
[02:08] <pitti> http://cdimage.ubuntu.com/daily-live/20070925.2/ - the One True Ubuntu Gutsy Desktop images; get them while they're hot
[02:08] <pitti> heno, stgraber, liw: ^ (tracker updated as well)
[02:08] <liw> pitti, ack, I'll get to that after testing gutsy-alternate-i386
[02:19] <iwj> TeTeT: Yes, that's expected.
[02:19] <geser> doko: Hi, are the ddebs useful when one want to get a backtrace for a crash inside a python extension
[02:20] <pitti> geser: wasn't that what python-*-dbg was supposed to be for?
[02:20] <geser> will try that
[02:20] <geser> as my test with the -dbsym packages wasn't successful
[02:21] <doko> geser, pitti: the python-*-dbg packages usually contain two things: the debug symbols for the normal extension, the unstripped extension for the python-dbg interpreter. -dbgsym packages should not be needed
[02:21] <pitti> doko: thanks
[02:22] <geser> doko: thanks
[02:25] <Kopfgeldjaeger> hi
[02:38] <TeTeT> iwj: any chance of fixing the modems before release?
[02:39] <iwj> TeTeT: I don't know.  I'm trying various tests to try to pin down the problem.
[02:39] <iwj> TeTeT: while I've got you here, can you try   /etc/init.d/sl-modem-daemon stop  and then a few moments later   start   and see if that helps ?
[02:42] <TeTeT> iwj: no change
[02:42] <iwj> Harmf.
[02:43] <iwj> Do you still have the 2.6.22-10 kernel installed ?  Can you try booting that ?
[02:43] <soren> iwj: Did you want the debug output from slmodemd ?
[02:43] <TeTeT> iwj: nope, I only have -12 on the system
[02:43] <geser> doko: when I try to import gtkspell in python-dbg I get: ImportError: /var/lib/python-support/python2.5/gtk-2.0/gtkspell_d.so: undefined symbol: Py_InitModule4_64
[02:44] <soren> iwj: I have -10. I'll test it.
[02:44] <iwj> soren: Err, yes, please.  Email it to me, or attach it to some suitable bug ?
[02:44] <iwj> soren: Thanks.
[02:44] <AnAnt> Hello, I'm creating a package which includes a python module, this module is for use with apache, where should this module be installed ?
[02:44] <doko> geser: then gtkspell probably is not correctly built
[02:44] <doko> ask the packager ...
[02:44] <soren> iwj: If that works, I'll grab the logs from that too for comparison.
[02:45] <soren> iwj: I've actually got -6, -7, -8, -10, -11, and -12. It's -10 you want?
[02:46] <iwj> Err, I think -10.  From tribe 5.
[02:46] <soren> alright.
[02:49] <seb128> geser: it's likely the dbg build not using python-dbg
[02:50] <soren> iwj: -10 is the same here.
[02:50] <soren> iwj: I've got to run now. I'll test with the older ones when I get back.
[02:57] <heno> FYI: ISO testing subscriptions can be seen here: https://iso.qa.stgraber.org/qatracker/subscriptions
[02:59] <Hobbsee> heno: sky fallen in yet?
[03:00] <heno> Hobbsee: no I'm just running around warning that it's imminent
[03:00] <Hobbsee> heno: ah, good, good.
[03:03] <lamont> given an extant bug in bugs.debian.org, what's the easiest way to get that imported into launchpad?
[03:07] <ogra> pitti, do you build the edubuntu-server isos or should i ?
[03:07] <Hobbsee> lamont: perhaps ask on #launchpad ?
[03:07] <pitti> ogra: publisher is on germinate
[03:07] <pitti> ogra: I can do it
[03:08] <lamont> Hobbsee: doh.  thanks
[03:08] <ogra> pitti, thanks :)
[03:08] <pitti> ogra: I build them right after publisher is finished
[03:08] <ogra> oki
[03:08] <ogra> just noticed they are not there yet ... didnt want to appear pushy :)
[03:12] <pitti> ogra: running
[03:12] <ogra> thanks
[03:12] <ogra> my last rsync is just done :)
[03:14] <pitti> heno: Ubuntu DVDs built, and added to iso-tracker; Kubuntu DVDs coming
[03:15] <heno> pitti: oh, you've managed to shrink them?
[03:15] <pitti> heno: thank Colin
[03:15] <pitti> heno: he dropped *-dbg
[03:17] <pitti> heno: hm, do you think I could rebuild the Ubuntu desktop CDs once more? when I rebuilt them last, the germinate overrides weren't up to date
[03:17] <pitti> heno: it just affects a couple of langpacks, but so far there aren't any tests reported except mine
[03:19] <pitti> heno: oh, nevermind, that just affects amd64, so it's not that important
[03:22] <pitti> sladen: hm, usplash progress bar on live CD boot is still misaligned
[03:24] <sladen> pitti: joy.
[03:24] <Riddell> mvo: another fix needed for dist upgrader I'm afraid
[03:25] <Riddell> mvo: is there anything fancy I need to do for upload except change the version in DistUpgrade/DistUpgradeVersion.py
[03:26] <sladen> pitti: livecd under vmware, or real hardware?  Widescreen/not widescreen?
[03:27] <pitti> sladen: vmware, will try real iron soon (but I think it happens there, too); standard 4 by 3 screen (not wide)
[03:27] <StevenK> ... Ubuntu runs on your iron?
[03:27] <sladen> StevenK: Ubuntu Is Hot
[03:28] <StevenK> sladen: Boo, hiss. :-P
[03:28] <jdong> Ubuntu will get rusty soon though ;-)
[03:28] <jdong> boo hiss yea yeah
[03:30] <mvo> Riddell: not really, I usually use "debian/rules arch-build" to make it build
[03:30] <mvo> Riddell: but that is probably overkill
[03:30] <mvo> Riddell:  bzr-buildpackage should be fine
[03:31] <mvo> Riddell: arch-build runs embedded tests etc
[03:33] <sladen> pitti: can you screenshot the vmware box so I can measure pixels off
[03:36] <pitti> sladen: http://people.ubuntu.com/~pitti/tmp/livecd-progress.png
[03:37] <iwj> soren: 2.6.22-10 wfm so you must have some different problem, or something else is going on.
[03:38] <pitti> ogra: http://cdimage.ubuntu.com/edubuntu/daily/20070925.1/ :(
[03:38] <ogra> lol
[03:38] <ogra> that can only be some bytes
[03:41] <sladen> pitti: okay, at least I under stand /why/ now.  On the low-resolution it's still using a 320px wide image (rather than 216px)
[03:43] <ogra> pitti, i think i'll drop the whole "Development" section from ship o be on the safe side it can come back after beta
[03:43] <pitti> ogra: or just drop bzr
[03:44] <ogra> pushing
[03:46] <ogra> pushed .... should be up
[03:46] <pitti> ogra: then let's hope that publishing an universe package is enough for publisher/germinate to make that active
[03:46] <ogra> i'll likely have changes to the ltsp udeb still so its not that bad yet
[03:47] <ogra> for testing 701M are fine atm
[03:47] <pitti> ogra: ok, publisher is running; I'll rebuild alternates after that?
[03:47] <Luke> asac: is there a -dbg package for nm in gutsy or are they in -dev?
[03:47] <ogra> pitti, yup
[03:48] <asac> Luke: there are dbgsym packages available
[03:48] <asac> pitti: where can I find those ^^ now?
[03:49] <pitti> heno, Riddell: up-to-date Kubuntu DVDs available and added to tracker
[03:49] <pitti> asac: deb http://people.ubuntu.com/~ubuntu-archive/ddebs gutsy main
[03:49] <liw> is "tribe" ubuntu-speak for "alpha" or "beta" version?
[03:49] <pitti> liw: 'alpha'
[03:49] <pitti> liw: and we recently agreed to not use the per-release codenames any more, but go with 'alpha'
[03:49] <Luke> asac: what is that package called?
[03:49] <cjwatson> pitti: for the next release
[03:49] <pitti> liw: so far we used the noun for a group of the animal of the current release
[03:49] <cjwatson> we should stick with what we have for gutsy
[03:50] <pitti> oh, absolutely
[03:50] <Luke> asac: pkg-create-dbgsym?
[03:50] <liw> pitti, er, the release after gutsy is only going to be named by its version number?
[03:50] <pitti> Luke: <original package name>-dbgsym
[03:50] <pitti> Luke: i. e. network-manager-dbgsym
[03:51] <cjwatson> liw: no, it'll still be called Hardy, but the alpha CD releases will just be called "Alpha"
[03:51] <cjwatson> as opposed to whatever the collective noun for herons is
[03:51] <pitti> liw: no, but it will be "alpha 1" instead of "<group of herons> 1"
[03:51] <cjwatson> (siege)
[03:51] <ogra> sad move ...
[03:51] <ogra> even though i understand the need
[03:51] <Luke> pitti: that package doesn't exist
[03:52] <pitti> ah, I finally looked in a dictionary what "hardy" and "heron" mean :)
[03:52] <pitti> Luke: do you have above apt source?
[03:52] <StevenK> Heh
[03:52] <StevenK> Personally, I'd prefer the collective noun
[03:52] <Luke> pitti: oh no. wasn't aware of that
[03:52] <pitti> but it causes too much confusion for outsiders
[03:53] <Luke> pitti: I was just looking in packages.ubuntu.com
[03:53] <sladen> also helps when you got numpties furiously testing the Nth alpha of the previous version...
[03:53] <pitti> Luke: Soyuz does not support debug symbol packages yet, so they have to live on people for the time being
[03:54] <Luke> pitti: is it the repo you sent to asac?
[03:54] <pitti> Luke: right
[03:54] <Luke> alrighty - thanks
[03:55] <Luke> I have to download the package from mac os x and then move it over to linux because... well it's a network problem
[03:55] <Luke> so how do I get the package via http or something?
[03:55] <pitti> Luke: sure, just browse the URL
[03:55] <Luke> ah
[03:55] <Luke> ty
[03:56] <ogra> hmm, that virtualbx install seems stuck :/
[03:56] <pitti> http://people.ubuntu.com/~ubuntu-archive/ddebs/pool/main/n/network-manager/
[03:56] <pitti> ogra: where?
[03:56] <Chipzz> Luke: apt-get has a --print-uris option
[03:56] <ogra> pitti, still frist stage of DI in the HW detection, i blame Vbox for now
[03:56] <pitti> Chipzz: doesn't help you without apt-get update...
[03:56] <pitti> oh
[03:56] <Chipzz> pitti: then do apt-get --print-uris update first? :)
[03:56] <ogra> might be my vbox install i didnt use it for a while
[03:56] <pitti> ogra: it gets stuck at 86% progress for me when it doesn't have internet connection, but your's is something else then
[03:57] <Chipzz> pitti: and you can at least deduce the directory where to get them from ;)
[03:57] <ogra> yeah, its stuck at 2% already
[03:57] <pitti> Chipzz: he said he had a network problem
[03:58] <Chipzz> pitti: you can dl the packages files and drop those in /var/lib/apt/lists if you'ld want to
[03:58] <pitti> rigt
[03:58] <pitti> +h
[04:00] <DamienCassou> mvo, still there?
[04:00] <mvo> DamienCassou: yes
[04:01] <DamienCassou> mvo, after installation from the Desktop CD, the application disappears and nothing happens
[04:01] <mvo> DamienCassou: could you please run a memtester? it sounds like there is something fishy with the hardware
[04:01] <DamienCassou> mvo, there were no problem with acpi
[04:02] <DamienCassou> mvo, from where do I launch memtester?
[04:02] <mvo> DamienCassou: its in the boot menu
[04:03] <ogra> oh, whee, i already have a gdm screen on the -desktop cd ....
[04:03] <DamienCassou> mvo, started
[04:03] <mvo> good luck
[04:04] <DamienCassou> mvo, see you in some hours
[04:04] <DamienCassou> mvo, when can I stop?
[04:05] <ogra> pitti, edubuntu-desktop i386 looks really good on a first glance in VirtualBox
[04:06] <ogra> gobby works ... ;)
[04:09] <Riddell> mvo: I think I messed up the update-manager upload, would you mind doing it (will need to be 0.78)
[04:09] <sladen> pitti: in some places the width of the pixmap is used;  in others the requested width from the theme.  Do you value the bar being centred more, or value the bar being less than the width of the logo more?
[04:09] <pitti> sladen: 'visually appealing' :)
[04:10] <pitti> sladen: so, centered is important I think; the particular size less so
[04:12] <sladen> fg
[04:12] <ogra> pitti, can you check on ubuntu if you have sudpend/hibernate in your logout menu ?
[04:12] <ogra> i see it on edubuntu :/
[04:12] <pitti> yes, it's there on my desktop
[04:12] <ogra> (we have an initramfs caseper-bottom script that cares for disabling it
[04:12] <ogra> gah
[04:13] <pitti> ogra: oh, you mena in the live system?
[04:13] <ogra> that needs to be fixed for final
[04:13] <pitti> ogra: not sure, I'll check in a minute
[04:13] <ogra> oki
[04:13] <ogra> the script unsets the gconf keys for suspend/hibernate
[04:15] <ogra> scripts/casper-bottom/32disable_hibernation ...
[04:17] <seb128> bah
[04:17] <seb128> the screen resolution is wrong on my laptop (intel card)
[04:17] <ogra> which driver does Xorg use ?
[04:17] <seb128> gnome-power-manager estimates an unknow time for the battery discharge
[04:17] <ogra> intel or i810
[04:17] <ogra> thats hals fault
[04:17] <jdong> seb128: is it Intel?
[04:18] <jdong> oh lol you said it
[04:18] <jdong> I can confirm on my macbook too; res 1024x768 is probed rather than 1280x800
[04:19] <cjwatson> I have an ATI that refuses to go above 800x600 at the moment, haven't figured it out yet
[04:19] <seb128> ogra: "intel"
[04:20] <seb128> ogra: and do you know why gpm can't estimate the battery discharge?
[04:20] <ogra> not really, no, but t gets the info from hal
[04:20] <jdong> the Intels go beyind 1024x768 fine; displayconfig-gtk can set the right res
[04:20] <jdong> but somehow the default probed res is 1024
[04:21] <jdong> is that an xresprobe bug?
[04:21] <ogra> oh crap ! can_hibernate and can_suspend were dropped from gpm gconf keys
[04:21] <seb128> the informations dialog has the correct information
[04:21] <ogra> ah, only moved
[04:21] <seb128> ogra: only the systray icon has "unknown"
[04:21] <mjg59> jdong: Yes
[04:21] <seb128> looks like a gpm bug
[04:22] <ogra> hmm
[04:22] <jdong> yay bugs :)
[04:22] <seb128> ogra: they changed location rather, that's /apps/gnome-power-manager/general/can_hibernate now
[04:22] <sladen> pitti: http://www.paul.sladen.org/ubuntu/upload/usplash-theme-ubuntu_0.16sladen1.debdiff  but the whole thing is broken by design
[04:22] <Hobbsee> mmm...bugs...
[04:26] <pitti> slangasek: ah, sweet
[04:27] <ogra> seb128, bug #144790 filed ...
[04:27] <ubotu> Launchpad bug 144790 in casper "hibernate and suspend are not disabled on gutsy liveCD" [Undecided,New]  https://launchpad.net/bugs/144790
[04:27] <seb128> ogra: thanks
[04:27] <ogra> hmm, there is no gutsy-final in the milestone list ?
[04:28] <pitti> ogra: 'nominate for release' -> 'gutsy'
[04:28] <ogra> ah
[04:29] <ogra> hidden in the obvious place on the left :)
[04:29] <Hobbsee> pitti: it seems there is no final milestone, though
[04:29] <pitti> Hobbsee: it's not supposed to be
[04:29] <Hobbsee> pitti: oh.  yet there are for previous releases.
[04:29] <cjwatson> I had been meaning to add that actually
[04:29] <pitti> we were asked not to do that any more
[04:29] <cjwatson> I must have misunderstood ...
[04:29] <cjwatson> are you sure?
[04:29] <Hobbsee> cjwatson: i think i misunderstood that too
[04:30] <Hobbsee> pitti: was that from the original phonecall?
[04:30] <pitti> cjwatson: I thought we were supposed to use gutsy tasks for that?
[04:30] <cjwatson> sigh
[04:30] <cjwatson> I give up, I always get confused by this
[04:30] <Hobbsee> pitti: the gutsy tasks means "this needs fixing in gutsy"
[04:30] <cjwatson> ask Keybuk, he generally understands Mark's mind :)
[04:30] <pitti> well, not that I would claim complete understanding of the LP designer's brains
[04:30] <Hobbsee> pitti: the milestones are for "it needs to be fixed by this point"
[04:30] <ogra> seb128, what does your gpm tooltip say exactly ?
[04:30] <pitti> Hobbsee: right
[04:30] <Hobbsee> cjwatson: no, this one does make logical sense - at least, i understood it.
[04:30] <evand> while we're on the subject, is there a finer granularity than "later"?  That is, can we milestone things for Hardy?
[04:31] <Hobbsee> pitti: does that make more sense?
[04:31] <pitti> Hobbsee: but we use tasks rather than milestones for SRUs, etc., so it's sort of consistent
[04:31] <cjwatson> how about we just add a release candidate milestone?
[04:31] <cjwatson> that doesn't seem too wrong
[04:31] <ogra> my battery is full so indeed it says "charge time: unknown)
[04:31] <cjwatson> ubuntu-7.10-rc
[04:31] <seb128> ogra: it's working now, it took it some time to get the estimation
[04:31] <cjwatson> that gives us somewhere to move deferred -beta milestones
[04:31] <cjwatson> evand: not at the moment
[04:31] <Hobbsee> pitti: the SRU's were done before the plan change, i thought.  whichever.
[04:31] <ogra> seb128, phew :)
[04:31] <seb128> ogra: unplug, it should update for the discharge
[04:31] <evand> ok
[04:31] <Hobbsee> cjwatson: either - it'd be purely cosmetic, really.
[04:31] <cjwatson> evand: we can't do that until the hardy distrorelease is created, basically - that's why we had the "later" hack
[04:32] <cjwatson> pitti: is an ubuntu-7.10-rc milestone OK with you?
[04:32] <ogra> seb128, well, i wouldnt have even expected to see a battery :) its a VirtualBox system ... even though it runs on my lappie it shouldnt have a batt
[04:32] <pitti> cjwatson: oh, absolutely; I'm not picky about it at all :)
[04:32] <cjwatson> done
[04:32] <evand> ah, that's understandable then
[04:32] <seb128> what are we supposed to use?
[04:33] <seb128> milestones or gutsy tasks?
[04:33] <cjwatson> for deferring things from beta, move to the ubuntu-7.10-rc milestone
[04:33] <seb128> cool
[04:33] <DamienCassou> mvo, no memory problem
[04:33] <Hobbsee> seb128: i think hte plan is "both".  but in practice, i'm not sure taht's sane.
[04:33] <seb128> I was missing a milestone to defer some bugs, thanks for adding it
[04:33] <DamienCassou> mvo, all test passed
[04:34] <Hobbsee> seb128: i'm presuming the use case is where it affects feisty and gutsy, which is done by nominations, and needs to be fixed by gutsy beta (the milestone).
[04:34] <Hobbsee> at least, that's how i understand it
[04:37] <ogra> sladen, i always wondered why its not possible for it to find the center of the screen itself buy checking the size and just compute the values
[04:44] <ogra> hmm, yelp doesnt seem happy on the liveCD
[04:50] <soren> iwj: eh? You have hardware for testing this yourself?
[04:51] <iwj> soren: Yes.
[04:51] <iwj> soren: Although my symptoms don't agree exactly with yours.
[04:51] <soren> iwj: Oh?
[04:52] <iwj> So I don't need you for primary testing, so to speak, but as additional data.
[04:52] <iwj> Well, in tribe 5 + new kernel, sl-modem-daemon doesn't work when started at boot time but if I restart it it works.
[04:52] <iwj> strace is unilluminating so far.
[04:53] <soren> slmodemd provides a lot of debug info with "-d 5" added to its options.
[04:53] <iwj> soren: Yes.
[04:53] <iwj> I take it the error you see is
[04:53] <iwj> err: modem:1: modem start = -1: cannot start device.
[04:54] <soren> iwj: Sounds right, yes.
[05:02] <dholbach> "The software source for the package  nvidia-glx-new  is not enabled."
[05:02] <dholbach> couldn't that fire up the software-properties-gtk thing?
[05:03] <dholbach> hum
[05:03] <dholbach> main/restricted/universe/multiverse are enabled
[05:03] <ogra> didnt we drop nvidia from ship anyway ?
[05:04] <DamienCassou> mvo, still there?
[05:04] <dholbach> ah, I had to refresh the apt cache
[05:04] <dholbach> now, I can install it
[05:04] <mvo> DamienCassou: yes, but I ran out of ideas
[05:05] <mvo> dholbach: that sounds like the bug that it only works after the first apt-get update
[05:05] <dholbach> mvo: right-o
[05:05] <mvo> dholbach: is that alternate or desktop?
[05:05] <dholbach> mvo: desktop
[05:05] <davmor2> mvo: Have you remember that bug from yestsrday :)
[05:05] <mvo> dholbach: I want to debug it, please
[05:06] <mvo> davmor2: indeed, I'm still puzzled about it
[05:06] <dholbach> mvo: fresh install from amd64 desktop cd
[05:06] <mvo> dholbach: ok, please do nothing
[05:07] <davmor2> mvo: I can do a fresh set of lists as I retesting the tests I did twice already ;)
[05:15] <DamienCassou> mvo, can I continue the installation after having installed acpi manually (though apt-get) ?
[05:28] <DamienCassou> mvo, ?
[05:30] <mvo> DamienCassou: sorry, I'm not familar enough with the debian-installer to give you a good answer here. but I think its very difficult :/
[05:31] <mvo> DamienCassou: what you could do is to copy the content of the CD into /target/var/cache/apt/archives before the install starts, that *might* work
[05:32] <DamienCassou> mvo, ok
[05:34] <Riddell> doko: I need to revert the change you did in bug 84689, it has broken packages which use libpythonize
[05:34] <ubotu> Launchpad bug 84689 in pykdeextensions "libpythonize0-0.4.0-3ubuntu1 depends on python2.5-dev" [Undecided,Fix released]  https://launchpad.net/bugs/84689
[05:38] <doko> Riddell: what exactly do you need to revert?
[05:38] <Riddell> doko: I need to add back the dependency of libpythonize0 on python2.5-dev
[05:39] <Riddell> it needs to load libpython2.5.so
[05:39] <doko> IMO a library package depending on a -dev package is just so wrong ...
[05:39] <doko> Riddell: fix it
[05:39] <Riddell> sure, it's wrong
[05:39] <Riddell> but my elite python/C skills do have limits
[05:40] <doko> so you think I should look at it ...
[05:41] <Riddell> doko: I think I should make a quick and hacky fix and add back the python2.5-dev dependency
[05:42] <seb128> Riddell: make it dlopen libpython2.5.so.1
[05:43] <doko> Riddell: please no:
[05:43] <doko> $ fgrep -r libpython src
[05:43] <doko> src/kdedistutils.py:#define LIB_PYTHON "libpython%(python_version)s.so"
[05:43] <doko> src/kdedistutils.py:    // Reload libpython, but this time tell the runtime linker to make the
[05:43] <doko> Riddell: improve your grep skills ;-p
[05:47] <Riddell> hmm, adding .1 to that doesn't seem to help
[05:48] <elmo> cjwatson, tfheen, whoever: could we please look at cleaning up cdimage.u.c?  it's up to 435Gb again
[05:51] <pitti> ogra: ugh, sorry, forgot your CDs; did you already trigger them, or shall I now?
[05:52] <ogra> feel free, i'm watching ubiquity while ubiquiting in the vbox :)
[05:52] <pitti> ogra: apparently not, cranking
[05:57] <DamienCassou> mvo, thank you for your help
[05:58] <DamienCassou> mvo, I will try your suggestions
[05:58] <DamienCassou> mvo, bye
[05:59] <mvo> good luck DamienCassou
[06:10] <asac> Luke: did you manage to get a backtrace?
[06:11] <pitti> ogra: 20070925.2 server there, looking good, added to trackre
[06:11] <ogra> yeap
[06:12] <ogra> monitored it since 2min :)
[06:12] <ogra> ah, there we go
[06:22] <iwj> OK, freaky.  The sl-modem-daemon problem is due to _malloc failing_.
[06:23] <iwj> (with EAGAIN)
[06:25] <mjg59> iwj: How much space is it trying to malloc?
[06:25] <iwj> 5479  mmap2(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 EAGAIN (Resource temporarily unavailable)
[06:26] <iwj> As a result of calling  malloc(16384)
[06:26] <mjg59> That's... very odd.
[06:26] <iwj> Strangely, it does a successful brk right beforehand.
[06:26] <slangasek> that's not in a unionfs context, is it?
[06:26] <iwj> slangasek: Err, no.  Userland.
[06:27] <iwj> And from an install, not a livecd.
[06:27] <iwj> With plenty of swap.
[06:27] <mjg59> iwj: Hm. The only terribly plausible thing from the manpage is that it's hit a resource limit?
[06:27] <slangasek> okie
[06:28] <pitti> evand, dholbach: ah, we are racing with amd64 tests :) I'm currently doing OEM/desktop and manual partitioning/alternate/CLI
[06:29] <iwj> mjg59: I can check that.  Bear with me - it only does it when the daemon is started at bootup and my own shell has a sane ulimit setup.
[06:31] <evand> pitti: I saw that but I figured it's probably a good thing in the event I miss something serious while testing.
[06:31] <pitti> right
[06:31] <pitti> evand: more tests -> always good :)
[06:32] <evand> ah, indeed :)
[06:34] <dholbach> calc: bug 5462?
[06:34] <ubotu> Launchpad bug 5462 in mc "Dutch translation: wrong shortcut" [Medium,Confirmed]  https://launchpad.net/bugs/5462
[06:34] <ogra> wohoo
[06:34] <dholbach> everybody else, please check out  http://daniel.holba.ch/sponsoring/  too
[06:34] <ogra> pitti, edubuntu-desktop-i386 seems food
[06:34] <ogra> err
[06:34] <ogra> good
[06:34] <pitti> lol :)
[06:34] <ogra> :)
[06:34] <dholbach> please just at least comment on those bugs
[06:34] <pitti> ogra: can you please put your results into the tracker?
[06:35] <ogra> indeed
[06:35] <ogra> hmm, should usplash use the screensize i selected in the isolinux menu ?
[06:36] <ogra> it uses 1024x768 instead of the 800x600 i picked
[06:36] <iwj> 5448  mlockall(MCL_CURRENT|MCL_FUTURE)  = 0
[06:36] <iwj> mjg59: ^   thanks!
[06:37] <mjg59> Ha
[06:37] <iwj> And, of course:   locked memory(kbytes) 32
[06:38] <mathiaz> dendrobates: can you update the link to the testcase in the tracker ?
[06:38] <mathiaz> dendrobates: all the links are no longer valid since heno updated the wiki pages.
[06:39] <dendrobates> mathiaz: I don't know.  I'll get back with you.
[06:39] <pitti> did anyone experience unionfs crashes with today's images? I didn't (kudos!)
[06:39] <ogra> me neither
[06:39] <ogra> and ltsp works fine as well since the weekend
[06:39] <heno> mathiaz: sorry :)
[06:39] <ogra> (we use unionfs there ae well)
[06:40] <ogra> pitti, its quite noisy in the logs i noticed, but thats all, no oopses anymore
[06:40] <pitti> yeah, lots of debugging output
[06:40] <heno> mathiaz: I moved your content here https://wiki.ubuntu.com/Testing/Cases/ServerInstall
[06:40] <pitti> wow, I already prepared for release-noting that :)
[06:40] <mathiaz> heno: yop. I noticed and updated the wiki page with anchors for each test.
[06:40] <pitti> so now I'm running out of options what to write into "Caveats"
[06:41] <ogra> lets add some ?
[06:41] <mathiaz> heno: now we just need to update the links in the tracker.
[06:42] <iwj> soren: Are you up for a test ?
[06:42] <pitti> ogra: don't worry, there are some red bugs in the tracker already :)
[06:42] <ogra> ah, good, so we dont run out of work :P
[06:43] <iwj> TeTeT: Fancy testing what I think may be a fix ?
[06:43] <evand> indeed, I haven't run into a single unionfs issue since the new version was released.
[06:44] <iwj> ogra: Did you want to chat about ltsp-client and autopkgtest ?
[06:44] <iwj> IIRC you were going to explain to me why it should be blacklisted.
[06:44] <ogra> well, by design it needs a a chroot thats build with ltsp-build-client
[06:44] <ogra> which autopkgtest wont do i guess :)
[06:45] <iwj> Err, so it won't just work if you install it ?  Normally packages are supposed to work if you install them.  Why won't it make the chroot ?
[06:45] <ogra> it has an explicit debconf error set if /etc/ltsp_chroot doesnt exist (ltsp-build-client touches that before installing ltsp-client/-core)
[06:46] <iwj> OIC
[06:46] <ogra> so one option is to blacklist it, the other is to create that file
[06:46] <iwj> So they're weird packages which shouldn't be installed on normal systems at all ?
[06:46] <ogra> right
[06:46] <ogra> thats what the description says as well :)
[06:46] <iwj> My autopkgtest can't understand descriptions :-).
[06:47] <ogra> teach it ;)
[06:47] <iwj> I'm trying to think if there could be a way for you to tell autopkgtest not to bother.
[06:47] <ogra> wwell, just touch /etc/ltsp_chroot ?
[06:47] <ogra> by default for all your chroots ?
[06:47] <ogra> it wont do any harm to other stuff
[06:47] <iwj> Surely that would be dangerous and anyway I don't think I want to add weirdo hacks like that.
[06:48] <ogra> well, then ignore ltsp-client
[06:48] <iwj> Obviously I can maintain a blacklist but if this kind of thing is going to happen a lot IWBNI it didn't have to go through me manually.
[06:48] <pitti> evand: \o/ full test coverage of amd64/desktop with no bugs reported :)
[06:48] <iwj> Would there be any point test-installing ltsp-client ?
[06:48] <ogra> i doubt thats happening a lot
[06:48] <ogra> not really
[06:48] <ogra> all it has are deps and two initscripts
[06:48] <ogra> you wont be able to test the initscripts without netbooting a client with them
[06:48] <iwj> -core, too, though, which has more stuff ?
[06:49] <evand> pitti: awesome!
[06:49] <mathiaz> heno: is it possible to update the links to testcases from the admin interface or does it still need a direct database query ?
[06:49] <ogra> yeah, we split ltsp-client into -core (initscripts and essential deps) and ltsp-client
[06:49] <ogra> ltsp-client has the distro specifics ...
[06:49] <ogra> -core is identical in ubuntu and debian
[06:49] <iwj> ogra: So really I mean, is there any point doing test-installs of -core.
[06:49] <ogra> no
[06:49] <ogra> and -client depends on -core
[06:50] <iwj> ogra: OK, so just those two binary packages.
[06:50] <ogra> so no there isnt any use for a test
[06:50] <iwj> Any others ?
[06:50] <ogra> ltspfsd
[06:50] <heno> mathiaz: do you just mean the link at the top of the main page?
[06:50] <ogra> it depends on ltsp-client-core so people can not accidentially install it
[06:50] <iwj> ogra: Surely that might reasonably be installed on a non-ltsp system ?
[06:50] <ogra> (in a non ltsp system)
[06:50] <iwj> ogra: OIC
[06:50] <iwj> Does it do something freaky that no-one else wants ?
[06:50] <heno> mathiaz: or links to individual cases?
[06:51] <ogra> it adds some udev rules that likely would break g-v-m on normal desktops
[06:51] <mathiaz> heno: links to individual test cases
[06:51] <iwj> OK, I think I should probably blacklist that too then.
[06:51] <iwj> Another question is:
[06:51] <ogra> but if you blacklist ltsp-client-core and your tool resolves deps that should suffice
[06:51] <iwj> Are these things that mean they shouldn't be tested best thought of as bugs (even wishlist bugs) or just as a peculiarity that means the test is inapplicable ?
[06:52] <iwj> ogra: I won't have the tool propagate blacklisting via deps.  That would mean it would fail to spot erroneous new dependencies for packages that ought to be tested.
[06:52] <ogra> well, in an ideal world we'd have an ltsp-build-client autobuilder or something like that to test explicitly
[06:52] <heno> mathiaz: looks like a DB change is needed. I don't see an admin option for changing anything about the test cases
[06:53] <iwj> ogra: Right, but that would be separate.
[06:53] <ogra> right
[06:53] <heno> I'll ask stgraber to to poke at it
[06:53] <ogra> since ltsp-clients are practically their own mini distro ... just using ubuntu packages
[06:53] <mathiaz> heno: ok.
[06:54] <iwj> ogra: So is the lack of usefulness of testing by just installing on a normal system a bug (or a thing we would like to change if we had time, or ...); or is it inherent and part of the package's definition IYSWIM.
[06:54] <mathiaz> heno: last time I sent the new links to stgraber
[06:54] <iwj> distro> Yes, I suppose I might argue you ought to count as your own derivative but I don't really want to go there.
[06:55] <ogra> we're in two fractions upstream about ltspfs at least :) debian would like to be able to install it on a normal system, the ubuntuids dont like that idea :)
[06:55] <keescook> pitti: is the x86 retracer dead?
[06:56] <ogra> i'm personally in the "its a special package for a special purpose in a special env" so why should we make it installable on systems that have no use for it ?
[06:56] <iwj> ogra: OK.  So we should let autopkgtest file its bug about ltspfs being uninstallable.
[06:56] <iwj> ogra: And then set it to wishlist or some such.
[06:56] <ogra> right
[06:56] <iwj> I mean, if Debian think that then they probably have a bug for it already anyway.
[06:56] <ogra> and leave it to debian to work out how to manage udev differentl P
[06:56] <ogra> :P
[06:56] <iwj> Right :-).
[06:56] <pitti> keescook: hm, it hung on a bug; restarted, thanks
[06:56] <TeTeT> iwj: absolutely
[06:56] <iwj> And for the others they're just inherently weird and I should blacklist them at my end ?
[06:56] <Mithrandir> as long as the description says "this might break your system in the following way", I think having it installable is fine
[06:56] <ogra> yeah
[06:57] <keescook> pitti: ah, okay.  thanks for checking.  :)
[06:57] <iwj> TeTeT: OK, edit /etc/init.d/sl-modem-daemon.  In the shell function start() near line 108, add just before the call to  start-stop-daemon --start  this line:
[06:57] <ogra> Mithrandir, i was tired of the broken systems and having to support them just because people dont read it :)
[06:57] <iwj>     ulimit -lH unlimited; ulimit -lS unlimited
[06:57] <iwj> TeTeT: And then restart the daemon or reboot or whatever you normally do.
[07:05] <keescook> pitti: I would like to request a beta freeze exception for apparmor.  it fixes 141128 and 140508, which currently stop the profile-building tools from working.  debdiff is: http://paste.ubuntu-nl.org/38562/
[07:05] <TeTeT> iwj: rock'n'roll, give me your number and my modem will call you know
[07:05] <ogra> phew
[07:05] <TeTeT> s/know/now
[07:05] <ogra> keescook, that means a ull rebuild of all isos, doesnt it ?
[07:05] <ogra> *full
[07:05] <keescook> ogra: icgk.
[07:06] <keescook> I was hoping they weren't final yet.
[07:06] <pitti> keescook: hm, at that point it has to wait, I'm afraid
[07:06] <keescook> I guess this can wait, then.
[07:06] <pitti> keescook: I consider the current images as pretty much final, barring disasters
[07:06] <keescook> pitti: okay, no problem.  they're understood bugs, we can live without it.
[07:06] <pitti> keescook: something for the release notes, maybe?
[07:06] <keescook> sure
[07:06] <pitti> keescook: please do get it uploaded, though, so that it'll be available as updates ASAP
[07:07] <iwj> TeTeT: You mean it's working ?  I usually test with http://www.freeukisp.co.uk/ (0844 711 0059, freeisp@internet, pw: internet).  I'm not affiliated with them and "free" ISPs are a bit flaky but they normally work.
[07:07] <keescook> pitti: having it sit in the queue won't get in your way?
[07:07] <TeTeT> iwj: I called my cellphone, it rang
[07:07] <ogra> keescook, nit final but all in a very good shape for teh first time  since weeks
[07:07] <iwj> TeTeT: Great.,
[07:07] <ogra> *not
[07:07] <iwj> TeTeT: I think I can call that a fix.
[07:07] <iwj> TeTeT: I'll just wait for Soren to get back to me.
[07:07] <pitti> keescook: no, there's plenty already
[07:08] <TeTeT> iwj: I'll update the TOshiba and see if this works as well
[07:08] <iwj> pitti: You don't want a new sl-modem-daemon at this point, do you ?  Looking at what you've just told Kees I take it the answer is no.
[07:08] <jdstrand> mdz: are you still seeing bug #99288? If not, what did you do to fix/workaround it?  (it's driving me nuts)
[07:08] <ubotu> Launchpad bug 99288 in xserver-xorg-video-ati "Screen corruption on Radeon Mobility M7 LW [Radeon Mobility 7500] " [Medium,Confirmed]  https://launchpad.net/bugs/99288
[07:10] <pitti> iwj: that's not in -desktop, so the case is a bit different
[07:10] <ogra> iwj, queuing is always fine :)
[07:10] <pitti> iwj: i. e. it doesn't matter if it is outdated on the CD (only in alternate ship, I think), unlike the apparmor fix
[07:10] <iwj> Oh, not in the squashfs then.
[07:11] <iwj> pitti: On the CD it's not installed by default but it's available for installation from the CD.
[07:11] <iwj> ogra: Yes, I'll do that of course but I wanted to offer it to the RMs.
[07:12] <iwj> And if can get it on the CD but only if I hurry I'll upload now rather than waiting for more "that fixes it" confirmations.
[07:12] <mdz> jdstrand: I'm pretty sure that was fixed for me ages ago
[07:13] <mdz> jdstrand: I think bryce knows what the issue was
[07:13] <pitti> iwj: I won't rebuild CDs just for that, but I don't think that hurts
[07:13] <pitti> iwj: unless, of course, someone needs sl-modem-daemon to actually get to the internet, but *shrug*
[07:13] <jdstrand> mdz: ok thanks.
[07:13] <mdz> jdstrand: it's possible that it regressed; I haven't been using that laptop since before the last -ati update
[07:13] <iwj> pitti: Well, that was kind of the point of having it on the CD but we can say "it's only the beta".
[07:13] <pitti> iwj: but having it in the archive is fine, just in case we do have to rebuild for another reason
[07:13] <jdstrand> mdz: it just popped up for me recently
[07:14] <jdstrand> mdz: there was a driver update, but I also tried compiz for the first time around the same time (since disabled it)
[07:14] <jdstrand> mdz: don't know what caused it for sure
[07:14] <mdz> jdstrand: you should follow up with bryce
[07:14] <jdstrand> mdz: was is only in a gnome-terminal where you saw the issue?
[07:15] <mdz> jdstrand: no, I saw it in gnome-panel most prominently
[07:15] <jdstrand> mdz: will follow up with bryce
[07:15] <jdstrand> mdz: thanks again
[07:15] <mdz> jdstrand: note in Screenshot-1 the corruption across the System menu and firefox launcher
[07:16] <jdstrand> mdz: I see that now
[07:16] <mdz> jdstrand: your corruption looks different to me though
[07:16] <mdz> jdstrand: do you ever get data from other windows, or only from redrawing within the window?
[07:17] <jdstrand> mdz: both
[07:17] <jdstrand> mdz: seems to mostly be the latter though
[07:20] <jdstrand> bryce: mdz indicated you are familiar with bug #99288.  I have added some comments to that report, and am seeing it with the lastest gutsy.  Do you know what might be causing this, or a possible workaround?
[07:20] <ubotu> Launchpad bug 99288 in xserver-xorg-video-ati "Screen corruption on Radeon Mobility M7 LW [Radeon Mobility 7500] " [Medium,Confirmed]  https://launchpad.net/bugs/99288
[07:35] <tepsipakki> jdstrand: try the latest driver from http://wiki.ubuntu.com/XorgOnTheEdge
[07:36] <ant30> are there problems with gnome-appearance-properties ?
[07:36] <ant30> It eat all cpu that he can
[07:37] <bryce_> hi jdstrand
[07:37] <gnomefreak> ant30: #ubuntu+1 for gutsy help (hint disable compiz)
[07:37] <jdstrand> bryce: hi
[07:37] <jdstrand> tepsipakki: I'll look at it
[07:38] <ant30> yes, without compiz , only metacity
[07:39] <ant30> well, I hava a Gtk-CRITICAL message with Blubuntu theme of repositories
[07:39] <gnomefreak> ant30: i had that same issue except mine locked up
[07:39] <jdstrand> tepsipakki: I am running latest gutsy
[07:40] <gnomefreak> ant30: uninstall blubuntu packages and restart should clear it up some (once again #ubuntu+1 for support)
[07:40] <ant30> If I try to close, it close, but run in background
[07:40] <ant30> yes, I am doing that on this moment
[07:40] <iwj> kylem: Sorry for imputing your flawless kernel.  You were right.  It was just coincidence that seemed to make it related to the kernel.
[07:40] <kylem> iwj, all good.
[07:40] <tepsipakki> jdstrand: but that version is not in gutsy, yet
[07:40] <kylem> it just didn't seem likely since it's an older chipset.
[07:40] <kylem> ich6 should be well debugged. :)
[07:41] <jdstrand> tepsipakki: ah I see
[07:45] <bryce_> jstrand, can you attach your xorg.conf and Xorg.0.log to that bug, just so we have it for comparison?
[07:53] <ScottK> I'd appreciate it if an archive admin would please push gramps 2.2.8-1ubuntu2 out the door.
[07:53] <pitti> ScottK: done three minutes ago
[07:53] <iwj> pitti: sl-modem now in the approval queue, FYI
[07:54] <ScottK> pitti: Thanks.
[07:54] <pitti> iwj: it'll get to kubuntu, at least (due to CD rebuilds)
[07:54] <LaserJock> pitti: do you know if new Edubuntu disks will be rebuilt before Beta?
[07:54] <pitti> LaserJock: ogra's call
[07:54] <pitti> LaserJock: nothing on my radar ATM
[07:55] <iwj> pitti: Right.  Thanks for your time.
[07:55] <LaserJock> pitti: k, thanks
[07:56] <lamont> Error: Package: and Architecture: do not alternate in debian/control
[07:56] <lamont> wth does that mean?
[07:56] <pitti> lamont: ah, that's from pkg-create-dbgsym
[07:57] <lamont> ok.  libast for motu.  neato
[07:57] <pitti> lamont: probably a Package: record has two Architecture: fields (or none at all)
[07:57] <jdstrand> bryce, tepsipakki: installed latest driver, will keep ou posted (sometimes it takes a while to show up)
[07:57] <lamont> is pklg-create-dbgsym ours, or debian?
[07:57] <pitti> lamont: mine
[07:58] <lamont> ah, ok
[07:58] <tepsipakki> jdstrand: does it show up when you change back from another desktop?
[07:58] <jdstrand> tepsipakki: you mean via the the panel's workspace switcher?
[07:59] <pitti> iwj: aah, so that's why it suddenly stopped working - new PAM with default ulimits
[07:59] <tepsipakki> jdstrand: since this bug actually looks a lot like bug 120858
[07:59] <ubotu> Launchpad bug 120858 in xserver-xorg-video-ati "Graphical corruption in gnome-terminal" [Undecided,New]  https://launchpad.net/bugs/120858
[07:59] <iwj> pitti: I'm not convinced that that's it.
[07:59] <iwj> pitti: Because I was able to make it fail in tribe 5.
[08:00] <iwj> But only some of the time.
[08:00] <tepsipakki> jdstrand: well, I'm seeing that on feisty with nvidia binary driver
[08:00] <pitti> iwj: hm, and we didn't have new pam at that time yet?
[08:00] <iwj> I don't think so but I haven't checked.
[08:00] <tepsipakki> jdstrand: and the window that suffers from that is runnig screen on another machine
[08:00] <iwj> I think there's just been too much confusion because if you run it from sudo it works fine.
[08:00] <iwj> So if you upgrade or restart it from a terminal, it starts working.
[08:01] <iwj> And I don't have notes which say exactly what shape my tests were.
[08:01] <pitti> iwj: right, 0.79-4ubuntu2 in tribe 5
[08:01] <tepsipakki> jdstrand: right, from the switcher or ctrl-alt-arrow
[08:01] <pitti> iwj: and the various MODEM_DBG patches are supposed to stay for a while, I take it
[08:02] <iwj> I think the best thing is really just to have this fix in as many places as possible and hope that it deals with "enough" of the bugs.
[08:02] <iwj> pitti: Uh ?
[08:02] <pitti> +MODEM_DBG("modem_start.. %d %d\n",__LINE__,ret);
[08:02] <pitti> stuff like that
[08:03] <iwj> Gads, I built it from the wrong tree.
[08:03] <iwj> Sorry.
[08:03] <iwj> They're harmless but I'll upload an ubuntu4 anyway.
[08:03] <pitti> there's also some other code changes
[08:03] <pitti> iwj: nevermind, reuse the version number and I reject this one
[08:03] <jdstrand> tepsipakki: that definitely looks like my bug
[08:04] <iwj> pitti: OK, thanks.
[08:04] <iwj> Sorry!
[08:04] <tepsipakki> jdstrand: cool
[08:04] <pitti> iwj: so the only change should be in the init script, not in modem_comp.c (it has functional changes ATM)?
[08:04] <jdstrand> tepsipakki: and not the one I originally posted to (as I only see it in gnome-terminal, and not the panel)
[08:04] <jdstrand> tepsipakki: that said, I can't reproduce it atm
[08:05] <iwj> pitti: No, there are no functional changes in modem_comp.c.  Just the init script.
[08:05] <iwj> I've made you a new one and debdiffed it myself this time.
[08:06] <geser> keescook: if you've time, can you sponsor bug #144883 (contains a fix for CVE-2007-5034)?. Thanks
[08:06] <ubotu> Launchpad bug 144883 in elinks "[Merge]  elinks 0.11.1-1.5ubuntu1" [Undecided,New]  https://launchpad.net/bugs/144883
[08:06] <ubotu> ELinks before 0.11.3, when sending a POST request for an https URL, appends the body and content headers of the POST request to the CONNECT request in cleartext, which allows remote attackers to sniff sensitive data that would have been protected by TLS.  NOTE: this issue only occurs when a proxy is defined for https. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5034)
[08:06] <tepsipakki> jdstrand: hmm, don't see the panel mentioned there
[08:09] <pitti> iwj: ah, much better, thanks; accepting
[08:10] <jdstrand> geser: this is already in the works
[08:10] <iwj> pitti: Thanks.
[08:10] <geser> jdstrand: ok
[08:10] <jdstrand> geser: I actually gave that patch to debian yesterday, and our update hasn't happened yet because of issues on jackass
[08:13] <pitti> liw: are you recording your tests in the iso tracker? there are very few for i386 so far
[08:15] <tepsipakki> bryce_: I'll mark bug 99288 as dupe of 120858, since that already had a dupe
[08:15] <ubotu> Launchpad bug 99288 in xserver-xorg-video-ati "Screen corruption on Radeon Mobility M7 LW [Radeon Mobility 7500] " [Medium,New]  https://launchpad.net/bugs/99288
[08:15] <bryce_> tepsipakki: yeah sounds good
[08:16] <tepsipakki> and it was already marked as a vte bug
[08:17] <jdstrand> tepsipakki, bryce: 99288 probably is not a duplicate as mdz's screenshots show corruption outside of gnome-terminal
[08:17] <tepsipakki> jdstrand: where?
[08:17] <jdstrand> tepsipakki: in gnome-panel.  See Screenshot-1 of his
[08:18] <tepsipakki> jdstrand: you should open the pic in full size :)
[08:18] <jdstrand> tepsipakki: I did.  'System' has a red line through it
[08:18] <tepsipakki> ah
[08:19] <tepsipakki> that could have been due to something else
[08:19] <jdstrand> tepsipakki: I did comment in 99288 that my problems were most likely 120858
[08:19] <jdstrand> tepsipakki: and set the status back to New, as I can't confirm it anymore
[08:23] <ubotu> Launchpad bug 144771 in fontconfig "package ttf-opensymbol 1:2.3.0~rc1-1ubuntu2 failed to install/upgrade: " [Undecided,New] 
[08:23] <pitti> mvo: didn't it crow in the morning? :)
[08:36] <liw> pitti, I got one image done and reported (gutsy-alternative-i386), that took all day, since I'm a newbie and every step requires learning three other things (and registering for five accounts :)
[08:36] <pitti> liw: heh, that's fine; scrutiny is appreciated
[08:36] <pitti> liw: did you see any catastrophes yet?
[08:37] <pitti> liw: I was lazy and tested them in parallel in vmware; a real-hw test is still outstanding, when I ever manage to be able to get offline for an hour
[08:37] <liw> pitti, on my test machine, NetworkManager doesn't always choose the right network card (out of two)
[08:37] <liw> pitti, https://bugs.launchpad.net/ubuntu/+bug/134496 that is
[08:37] <ubotu> Launchpad bug 134496 in network-manager "After initial reboot, wrong ethernet card is used" [Medium,Incomplete] 
[08:37] <pitti> liw: ah, that's well below the OMGbetaisdoomed bug threshold :)
[08:38] <liw> yep
[08:38] <Treenaks> liw: at least it doesn't die and bring down interfaces on upgrade 8)#
[08:39] <Treenaks> (but that might have been my own fault..)
[08:39] <pitti> liw: hm, you have two ethernets with DHCP? wow
[08:39] <liw> pitti, no, I have two cards in one machine, only one of which is hooked up
[08:39] <liw> (since the other crashes and burns on big transfers)
[08:39] <liw> (or did, last year, the driver might have improved)
[08:40] <pitti> liw: hm, I have two cards as well; seems I urgently need to do a real-hw installation
[08:40] <pitti> liw: one is internet, one a dangling cable which I commonly use to connect my laptop to
[08:41] <soren> Is anyone else experiencing trouble with multiple scsi disks in Gutsy in vmware server? It seems to only detect one disk :(
[08:43] <pitti> dendrobates: any idea who could test server/sparc?
[08:44] <pitti> dendrobates: and more generally, can the server team do the i386/amd64 server tests?
[08:44] <dendrobates> pitti: we will handle all the server tests, and are looking for someone to help with sparc.
[08:44] <pitti> dendrobates: not sure whether we can bribe fabbione again :/
[08:45] <dendrobates> pitti: I am going to try on my old sparc.
[08:45] <dendrobates> the kernel team is shipping me a newer sparc, but I don't expect it to arrive in time.
[08:45] <pitti> yay new toys :)
[08:46] <dendrobates> pitti: so fabbione and the kernel guys have the most appropriate equipment.
[08:46] <fabbione> also doko does
[08:46] <fabbione> he has a T2000 or T1000
[08:47] <fabbione> pitti: unlikely.. my sparc gear is in production now
[08:48] <pitti> fabbione: it was worth a try :)
[08:48] <pitti> I'm off for ~ 10 minutes for some live CD tests on my desktop, brb
[08:48] <desertc> Hello - I would like to offer this suggestion.  When applying kernel patches, there should be some clean-up of old patches.  I assigned 50 MB for my /boot partition, and this was filled up with the most current software update.  The upgrade did not fail gracefully, either.
[08:49] <desertc> Regardless of the /boot size, if the kernel upgrades do not clean up after themselves, then they grow without bounds and will fill up any sized space.
[08:52] <mvo> thanks desertc, we do cleanup of old kernels on system upgrades
[08:54] <desertc> I guess 50 MB was insufficient for that cleanup process.
[09:04] <desertc> I had three versions of the kernel in there.  Do you think that is the normal cleanup process?
[09:05] <desertc> Anyway, when it errored that it was out of space, there was not any way to re-apply the patch, nor did the update manager catch the problem.
[09:05] <desertc> Thanks for your efforts with Ubuntu, all.
[09:05] <gnomefreak> bryce_: i updated bug #139726 it looks like i may lose any more data due to testing beta desktop cd so let me know if that is enough info on there
[09:05] <ubotu> Launchpad bug 139726 in xorg "[Gutsy} GDM is missing menu items" [Undecided,New]  https://launchpad.net/bugs/139726
[09:08] <bdmurray> mvo: heno pointed me to a CompizFeedback wiki page and there is a 3d app test listed there.  Should a bug when running glxgears be filed about compiz?
[09:09] <soren> mdz, mjg59, sabdfl: tb meeting, anyone? :)
[09:09] <mvo> bdmurray: if that fails under compiz but works fine under metacity then yes
[09:11] <ogra> mjg59, while youre around, and we have bug 144790 around ... do you think it makes sense to enable suspend on the liveCD ? bdmurray suggested that
[09:11] <ubotu> Launchpad bug 144790 in casper "hibernate and suspend are not disabled on gutsy liveCD" [High,Confirmed]  https://launchpad.net/bugs/144790
[09:11] <mjg59> Suspend should be fine
[09:12] <mjg59> In most cases
[09:12] <mjg59> People with USB CD drives will lose, but, well
[09:12] <ogra> yeah indeed
[09:12] <ogra> ok, i'll only disable hibernate then ... my concern was that we didnt explicitly test that
[09:13] <bryce_> gnomefreak: yeah see if it occurs with the beta cd (I'm guessing it will, but who knows).  Sorry I can't give more useful troubleshooting directions; I don't have a good understanding of gdm internals so am not sure why it's selecting a different resolution from X
[09:13] <pitti> MacSlow, mvo: ah, I just noticed a small regression in the appearance applet: it defaults to 'normal' even when metacity is running (because the video driver does not support composite)
[09:13] <mjg59> bryce_: gdm does nothing to set the resolution, to the best of my knowledge
[09:13] <ogra> meh
[09:14] <ogra> vbox doesnt like alternate today :/
[09:14] <pitti> MacSlow, mvo: changing it to ZOMGmoreeffects doesn't do anything, and changing to 'off' and back looks weird
[09:14] <mjg59> bryce_: The session itself may have a resolution set
[09:14] <bryce_> mjg59: does gdm use the xorg.conf to get the resolution?  I've noticed it often ends up with different settings from what's in the xorg.conf
[09:14] <pitti> MacSlow, mvo: is this known and in the works already, or do you want a bug report?
[09:14] <mjg59> bryce_: I don't understand the question
[09:14] <mjg59> bryce_: gdm is just an X client
[09:14] <seb128> bryce_: gdm only starts a x server
[09:14] <gnomefreak> bryce_: ok ill try it, me and seb128 went over this trying older versions of gdm and it worked the same way thats what made me think X for most part. but i will test beta now and let you know when i get back on (or wait and see what is coming of this topic first
[09:14] <mvo> pitti: I'm not aware of this, so a bugreport is appreciated
[09:15] <bryce_> mjg59: what determines what driver and resolution it uses in that case?
[09:15] <mvo> pitti: please also milestone it
[09:15] <mjg59> Well, it's also something that starts X, but it doesn't pass any configuration to it
[09:15] <MacSlow> pitti, hm... better file a bug and assign it to me
[09:15] <mjg59> bryce_: xorg.conf
[09:15] <pitti> MacSlow: alright, doing
[09:15] <bryce_> gnomefreak: ok
[09:15] <MacSlow> mvo, we'll get back to the explicit plugin-list I bet :)
[09:15] <gnomefreak> xorg is default other than using restricted/manager to enable nvidia other than that the monitor buttons is what caused this
[09:16] <MacSlow> mvo, I'll look into that tomorrow
[09:16] <gnomefreak> anyway ill be back my xorg.conf is attached to bug report along with a bunch of other things. see you tonight
[09:16] <MacSlow> still working on the wnck-applet properties-dialog for the compiz-case
[09:17] <bryce_> gnomefreak: great, good luck
[09:17] <gnomefreak> back up first :)
[09:17] <mvo> MacSlow: what would be explicit plugin list have to do with that?
[09:19] <MacSlow> not that alone
[09:19] <pitti> MacSlow: done, bug 144913; thank you
[09:19] <ubotu> Launchpad bug 144913 in gnome-control-center "defaults to 'normal effects' even when the driver does not support compositing" [Medium,New]  https://launchpad.net/bugs/144913
[09:20] <pitti> iwj, Riddell: new sl-modem/pykdeext will be available in ~ 5 minutes; can you give this a quick test before I start building new KDE CDs?
[09:21] <bdmurray> mvo: I submitted a bug about what I saw when running glxgears
[09:21] <mvo> bdmurray: what bugnumber?
[09:21] <bdmurray> bug 144914
[09:21] <ubotu> Launchpad bug 144914 in compiz "putting glxgears below another window when running compiz looks funny" [Undecided,New]  https://launchpad.net/bugs/144914
[09:22] <mvo> bdmurray: right, that is a sort-of known issue, very hard to fix with the current drivers
[09:26] <pitti> Riddell, iwj: there now
[09:26] <pitti> Riddell: libpythonize0 looks good at least
[09:28] <pitti> ^ (Kubuntu only)
[09:29] <gnomefreak> bryce_: would not having hoz and vert. refresh rates in xorg.conf cause my issue when changing screen from monitor buttons? i noticed xorg doesnt put them there anymore (atleast i thought it did at one time)
[09:29] <bryce_> no it shouldn't matter
[09:29] <mjg59> bryce_: No
[09:29] <mjg59> Erm.
[09:29] <gnomefreak> k
[09:29] <mjg59> gnomefreak: No
[09:30] <gnomefreak> passing thought figured id ask
[09:30] <slangasek> pitti: ETA on those Kubuntu CDs then? (waiting to be able to file a proper test report)
[09:31] <bdmurray> mvo: what is the issue?
[09:32] <mvo> bdmurray: basicly its a driver issue
[09:32] <mvo> bdmurray: direct rending draws directly to the font buffer and compiz does not know about this
[09:38] <slangasek> jamiemcc, seb128: bug #130935 is milestoned and "in progress", but unassigned; are either of you working on this bug?
[09:38] <ubotu> Launchpad bug 130935 in tracker "Tracker takes very long time to index system, provides no obvious status information" [High,In progress]  https://launchpad.net/bugs/130935
[09:38] <jamiemcc> slangasek: I am
[09:38] <slangasek> jamiemcc: great, shall I assign it to you?
[09:38] <jamiemcc> yes pls
[09:39] <slangasek> thx
[09:43] <ogra> pitti, did you test an alternate install in vbox ? do you get a resolution question there ?
[09:44] <ogra> i get it reproducable here but would really prefer it to be a virtualbox issue :)
[10:02] <pitti> ogra: yes
[10:02] <ogra> phew
[10:02] <pitti> ogra: erm, not in vbox, in vmware
[10:02] <pitti> ogra: I also get that when I install on my real system
[10:02] <ogra> oh, thats bad
[10:02] <rohan> crimsun: ping, are you around ?
[10:02] <mathiaz> pedro_: are you testing the ubuntu-server i386 iso ?
[10:02] <pitti> ogra: X's package detection scripts don't detect my monitor resolution
[10:02] <ogra> that should be autodetected
[10:02] <pitti> ogra: X itself does, though
[10:03] <pitti> ogra: that has always been like this, though
[10:03] <pedro_> mathiaz: yep doing it right now
[10:03] <rohan> crimsun: i remember you had once given me instructions on how to compile snd_hda_intel using code from hg repo of alsa. can you please give me those instructions once again ?
[10:03] <pitti> ogra: not necessary to give an answer, btw, just leave it empty
[10:03] <mathiaz> pedro_: ok. I'm doing the lvm test case right now.
[10:03] <bryce_> pitti, is this the same bug seb128 is seeing?
[10:03] <mathiaz> pedro_: can you test amd64 ?
[10:03] <ogra> pitti, well, its a question ...
[10:03] <pitti> bryce_: not sure?
[10:03] <bryce_> pitti, we tracked his down to xserver 12ubuntu3
[10:03] <ogra> we should preseed it then
[10:03] <seb128> bryce_: 12ubuntu4 rather ;)
[10:04] <pitti> ogra: *shrug* only on alternate and only if the package scripts fail
[10:04] <bryce_> oops, right
[10:04] <rohan> jdong: ping, did you find any updates on that resolution bug ?
[10:04] <pedro_> mathiaz: no sorry, i don't have an amd64 machine :-(
[10:04] <mathiaz> pedro_: ok.
[10:04] <pitti> bryce_: what I see (if you want to call it 'bug') exists since hoary or so
[10:04] <rohan> jdong: where the latest cd was not able to detect 1280x800 and instead defaulted to 1024x768 ?
[10:04] <bryce_> pitti, if it's been mis-detecting since before tribe5, then it's a separate bug
[10:04] <mathiaz> pedro_: I'm gonna add some more test for the new tasks we've added.
[10:04] <jdong> rohan: I haven't had a chance to do much but confirm that bug
[10:04] <bryce_> pitti: ah
[10:04] <mathiaz> pedro_: could you test installing a print server ?
[10:05] <rohan> jdong: oh, it's been filed on launchpad ?
[10:05] <pedro_> mathiaz: sure, just give me the test case
[10:05] <pitti> bryce_: NB that X itself detects it fine, just the Debian scripts fail
[10:05] <jdong> rohan: I am unsure, but enough developers have heard us talk about it, and seb128 even experiences the bug
[10:05] <bryce_> pitti: ok
[10:05] <pitti> bryce_: (one day those should all disappear and be replaced with something small and sensible...) :)
[10:05] <rohan> jdong: ah ok, so no need to report it ;)
[10:05] <bryce_> pitti, plan is that those scripts are going to get gutted and replaced, probably by hardy
[10:06] <mathiaz> pedro_: https://wiki.ubuntu.com/Testing/Cases/ServerInstall#print-server
[10:06] <pedro_> mathiaz: already saw it in the wiki
[10:06] <pedro_> jeje yep
[10:06] <bryce_> pitti: I'd been planning on doing that myself, however tepsipakki says debian is also planning on similar, so probably instead I'll just lend a hand (or cheers) to debian
[10:06] <pitti> bryce_: yay; they were great in warty and hoary to get auto-X-config working in the first place, but I guess they are horribly obsolete with today's X
[10:06] <mathiaz> pedro_: yeah.. I've just added it.
[10:07] <mathiaz> pedro_: but it's not in the qa tracker yet.
[10:07] <bryce_> pitti: yeah there's a lot of logic in them which looks like it'd get dated quick.  lots of heuristics and hardware-specific guessing
[10:07] <jdong> rohan: woudl be nice to search on lp package xresprobe for the bug, if it isn't there (doubt it!) report it
[10:08] <bryce_> pitti, for Gutsy, the solution to focus on is being able to fix it post-install via Screens and Graphics
[10:08] <rohan> jdong: ok, i'll do that when possible
[10:08] <pitti> bryce_: right, and this should be kept in any case
[10:08] <pitti> calc: good morning
[10:09] <calc> pitti: hi, just rebooted my box hoping vmware would start working, still doesn't :\
[10:09] <pitti> calc: oh? works fine here
[10:09] <calc> its giving me an error that supposedly means libXrender isn't installed... but it is :\
[10:09] <calc> http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=1979&sliceId=2&docTypeID=DT_KB_1_1&dialogID=23132511&stateId=0%200%2023130478
[10:10] <calc> i went ahead and even installed all the ubuntu versions of any library it used that it was using a private copy of which still didn't help :\
[10:11] <pitti> calc: hm, wait -- do you use compiz?
[10:11] <pitti> calc: maybe it's missing in ia32-libs?
[10:11] <pitti> hm, weird
[10:12] <calc> not that i know of
[10:13] <pitti> ogra: how do things look so far?
[10:13] <calc> yea compiz appears to be disabled
[10:13] <calc> it is set to "no effects"
[10:13] <ogra> my vbox crashed several times with the server install
[10:14] <ogra> this one seems to get throught though, i'm at 82% in pkgsel
[10:14] <ogra> (the worst part (ltsp) still to come though)
[10:24] <stgraber> `23meg: ping
[10:26] <`23meg> pong
[10:26] <`23meg> stgraber, pong
[10:26] <stgraber> You tried to register to the Ubuntu QA Tracker with an invalid mail
[10:26] <stgraber> can you give me one so I forward the activation mail
[10:27] <`23meg> hmm, I registered with my ubuntu.com address
 host mx.canonical.com[91.189.94.145]  said: 550 <muratgunes@ubuntu.com>: Recipient address rejected: User unknown in virtual alias table (in reply to RCPT TO command)
[10:27] <`23meg> ah, sorry; mgunes@ubuntu.com please
[10:29] <`23meg> stgraber, are accounts from the old tracker no longer active?
[10:34] <stgraber> `23meg: the ones from isotesting.stgraber.org are, the ones from www.stgraber.org/ubuntu aren't
[10:34] <`23meg> I see; mine was on the latter
[10:35] <smallfoot-> What is Ubuntu doing to prevent the problem of license profileration?
[10:39] <sistpoty> smallfoot-: what do you meant with license profileration?
[10:40] <smallfoot-> http://en.wikipedia.org/wiki/License_proliferation
[10:40] <smallfoot-> oh, i meant proliferation not profileration
[10:41] <smallfoot-> it makes it harder to re-use source code, harder to integrate software, harder to borrow source code, etc
[10:42] <smallfoot-> Mark Shuttleworth has also spoken about the problem of license proliferation on this blog -- http://www.markshuttleworth.com/archives/67
[10:43] <pedro_> mathiaz: just tested (print server case) it works fine
[10:44] <mathiaz> pedro_: great ! thanks.
[10:44] <pedro_> mathiaz: i'll go for the LVM now
[10:44] <mathiaz> pedro_: I'm currently adding new test cases for the tasks we've added to the ubuntu-server cd.
[10:45] <mathiaz> pedro_: are you using vmware ?
[10:45] <pedro_> mathiaz: nop, a spare machine i have
[10:46] <mathiaz> pedro_: hum... When it comes to LVM, there is a small bug that the installer won't wipe the LVM physical extent.
[10:47] <mathiaz> pedro_: so the second time you try to install an LVM partition, the installer will complain that it already has LVM PE.
[10:47] <pedro_> mathiaz: ok will remember that
[10:47] <sistpoty> smallfoot-: ubuntu doesn't in the first place, though when packaging new software we always try to convince upstream to change the license statement in order to not suffer from proliferation
[10:48] <smallfoot-> sistpoty, oh thanks... thats awesome, great work guys, i wish the other distros would do the same
[10:49] <sistpoty> smallfoot-: I guess many are (e.g. debian and its debian free software guidelines)
[10:51] <slangasek> sistpoty: I rather doubt that's accurate on the whole, I expect that most Ubuntu packagers only look at whether the license is ok for universe rather than whether it's a common license?
[10:52] <sistpoty> slangasek: that may be true, but I try my best to encourage aforementioned behaviour
[10:53] <ScottK> My favorite license I've hit recently is "If you think you need a license for anything you might think of this as beeing unter a "BSD Style License"
[10:53] <smallfoot-> unfortunately, we have Apache, Perl, Berkeley DB, LaTeX, GNAT, Vim, zlib, xinetd, OpenLDAP, OpenSSL, PHP, Python, Ruby, libwww, Zope who all have custom licenses :(
[10:53] <ScottK> That's the "license" for python-ipy.
[10:54] <sistpoty> smallfoot-: well, I guess that won't go away too soon, and (considering ion3, or rather more majors putting stuff under their own OSS licenses) that won't go away too soon
[10:55] <sistpoty> yay, bad sentence... and this might get worse I wanted to add
[10:57] <smallfoot-> :(
[10:57] <smallfoot-> hope it dont get worse
[11:00] <sistpoty> smallfoot-: /me neither... even worse is if you know some piece of SW got relicensed later as LGPL, but you're bound to some non-commercial license because you forked earlier. /me is still trying to figure whom to contact, since most email addresses from our version aren't valid any longer
[11:02] <smallfoot-> oh
[11:03] <smallfoot-> maybe should refuse to ship Ubuntu with software that has custom licenses
[11:03] <smallfoot-> or have a delay before new releases of software is put into the repository as punishment
[11:03] <sistpoty> (our as in university project, nothing directly to do with ubuntu -- yet)
[11:04] <ScottK> smallfoot-: Who does that really punish?
[11:05] <smallfoot-> ScottK, it makes software with custom license become second-tier, worth less, less prioritized
[11:05] <smallfoot-> lol
[11:05] <smallfoot-> well, true kinda
[11:06] <ScottK> To which the standard response is, "Go ahead, make my day."
[11:06] <smallfoot-> hehe
[11:19] <pochu> seb128: tracker 0.6.3 is out, which fixes a ton of bugs (some of them critical and tagged for gutsy-beta). Is it ok if I do package it, providing you haven't done it yet?
[11:20] <seb128> pochu: I didn't do the update yet, you are welcome to work on it
[11:21] <pochu> seb128: cool :) will you be able to review/sponsor it?
[11:22] <seb128> pochu: yes
[11:22] <seb128> pochu: tomorrow likely, the archive is frozen for beta anyway
[11:22] <pochu> great!
[11:22] <pochu> seb128: yeah I know
[11:23] <seb128> pochu: don't enable the thunderbird experimental indexer
[11:23] <seb128> just in case you wanted to do the change ;)
[11:23] <pochu> I'd love to, but I guess it's not ready :(
[11:26] <seb128> pochu: right
[11:26] <jamiemcc> pochuL it aint called experimental for nothing :)
[11:26] <pochu> jamiemcc: hehe, true that
[11:48] <gnomefreak> bryce: looks like X detected everything correct so i dont need to use monitor buttons nor change resolution i guess this bug is fixed ty :)
[11:49] <bryce_> awesome
[11:49] <gnomefreak> cjwatson: was i supposed to see cryptset(or whatever it is that D-I uses to encrypt for install (sorry im drawing a blank)
[11:50] <bryce_> gnomefreak: if you can mention that you're no longer seeing the issue on bug 139726, I'll go ahead and close it
[11:50] <ubotu> Launchpad bug 139726 in xorg "[Gutsy} GDM is missing menu items" [Undecided,New]  https://launchpad.net/bugs/139726
[11:50] <gnomefreak> i am atm
[11:53] <gnomefreak> bryce_: i closed both tasks with explaintions
[11:54] <bryce_> excellent, thanks
[11:55] <gnomefreak> np thanks for your help on it
[11:58] <mjg59> MacSlow: I enabled desktop effects, they failed to enable because I'm on 965, but my workspace configuration has changed anyway
[12:00] <cjwatson> gnomefreak: it was taken back out again for beta, too many problems
[12:00] <gnomefreak> cjwatson: ah ok
[12:02] <gnomefreak> cjwatson: only other question is why are all repos enabled except the canonical ones? the cdrom repo is enabled along with the ubuntu.com repos (was this always this way and i forgot)
[12:04] <cjwatson> gnomefreak: because something went wrong in your installation such as the network not being enabled
[12:04] <cjwatson> or not being able to talk to the archive
[12:05] <gnomefreak> ah ok
[12:05] <cjwatson> you can safely uncomment them
[12:06] <gnomefreak> cjwatson: i commented out the cdrom, the canonical repos are not working atm
[12:07] <cjwatson> it's not switched on yet, should be for gutsy
[12:07] <cjwatson> (expected)
[12:08] <gnomefreak> cjwatson: yeah thats what ive been telling users complaining that it doesnt work i tell them wait till release
[12:08] <cjwatson> seems a rather odd thing to complain about
[12:08] <ogra> cjwatson, i uploaded a new edubuntu-meta, could you let that throuhg please ?
[12:08] <cjwatson> ogra: slangasek/pitti's call
[12:09] <gnomefreak> cjwatson: they want all those extras that we cant legally ship i guess
[12:09] <ogra> slangasek, ping ^^^ ?
[12:09] <cjwatson> gnomefreak: the partner repository is not a repository for illegal distribution
[12:09] <cjwatson> so please pick a better word than "legally" there
[12:09] <ogra> cjwatson, i didnt know steve drives the publisher already
[12:09] <gnomefreak> what is it? i thought it was the non-free stuff like opera
[12:09] <cjwatson> ogra: he doesn't, but it's his decision, I'd just need to implement it
[12:10] <ogra> ah
[12:10] <cjwatson> gnomefreak: if opera is in the commercial (now renamed to partner) repository (I don't remember whether it is or not), it would be because Canonical had a commercial relationship with Opera in which they asked us to ship it
[12:10] <cjwatson> gnomefreak: so it would in no way be illegal
[12:10] <gnomefreak> ah ok
[12:11] <gnomefreak> yeah iirc it was in the commercial repo
[12:11] <cjwatson> gnomefreak: it probably wouldn't conform to Ubuntu's licensing policies, which is why it's in the canonical.com namespace not ubuntu.com, but that's very different
[12:11] <gnomefreak> ok yeah my wording was very wrong on that
[12:14] <slangasek> ogra: this is a change to try to get the CD size down?
[12:15] <ogra> slangasek, nope, moving moodle out of the default install into ship ... it's still missing d-i integration (mainly presseding but proably even more) it was a laet addition and i discovered its not ready for default
[12:15] <ogra> *late
[12:16] <slangasek> ok
[12:16] <ogra> thanks :)
[12:16] <slangasek> but it still requires an edubuntu CD rebuild for it to be reflected in the beta, yes?
[12:17] <ogra> yep
[12:17] <ogra> i'll do that tomorrow morning
[12:17] <slangasek> ok
[12:18] <slangasek> accepted, I think
[12:18] <ogra> cjwatson, would you flip the switch please ?
[12:18] <slangasek> I think I just did that
[12:18] <ogra> oh
[12:19] <ogra> great :)
[12:19] <ogra> thanks :)
[12:19] <slangasek> cjwatson: website-based accept seems to have worked this time
[12:19] <cjwatson> so it did
[12:19] <cjwatson> ok, let's hope it was just transient badness yesterday
[12:21] <pwnguin> Is there a written ubuntu udev policy I can look at?
[12:22] <pwnguin> because it seems different than debian's
[12:22] <cjwatson> pwnguin: /etc/udev/rules.d/README is the closest I'm aware of
[12:22] <pwnguin> heh
[12:22] <pwnguin> thats... insufficient
[12:22] <pwnguin> reading that, you might think you can ship udev rules in a package
[12:22] <cjwatson> and yet it describes the main differences from Debian
[12:22] <cjwatson> of course you can and many do
[12:23] <ogra> according to Keybuk we use the upstream policy (at least thats waht he always says)
[12:23] <cjwatson> $ dpkg -L pcmciautils | grep udev/rules.d/
[12:23] <cjwatson> /etc/udev/rules.d/85-pcmcia.rules
[12:23] <cjwatson> for example
[12:23] <RAOF> Upstream policy appears to be "udev rules are in the udev package, unless they're just RUN rules"
[12:27] <pwnguin> and even then, I'd appreciate guidance on security implications
[12:28] <ogra> mode 0660 and group kvm should be safe enough, no ?
[12:29] <RAOF> Yes.
[12:29] <ogra> i think thats whats mentioned in the bug
[12:29] <RAOF> That's right, and that's what the previous behaviour was.
[12:29] <ogra> right
[12:30] <ogra> the change likely came in with a debian merge
[12:30] <ogra> simple oversight