[00:00] <cjwatson> or modify the .iso and remove the 'gfxboot' line from isolinux.cfg
[00:00] <kirkland> cjwatson: shift didn't get it, will try to sed 'gfxboot' out
[00:07] <cjwatson> kirkland: qemu-kvm is no help; kvm still exhibits the same symptoms. qemu does work though.
[00:08] <kirkland> cjwatson: okay, thanks, i'll dig into it;  could you open a bug?
[00:08] <kirkland> cjwatson: 3min left for iso download
[00:08] <cjwatson> ok, will do once I downgrade so I can use ubuntu-bug
[00:08] <cjwatson> no rush, bed soon
[00:08] <kirkland> cjwatson: sure thing, thanks.
[00:08] <kirkland> cjwatson: thanks for trying the daily
[00:09] <kirkland> cjwatson: i'm hoping those become useful
[00:14] <kirkland> cjwatson: installing both [jaunty & karmic]-server-i386 now
[00:15] <YokoZar1> did Gnometris disappear off the default games?
[00:16] <directhex> YokoZar, patents!!!
[00:16] <YokoZar> what
[00:20] <directhex> Results of Search in US Patent Collection db for:
[00:20] <directhex> tetris: 63 patents.
[00:20] <directhex> or, being less useless, it seems there's no binary for it in gnome-games in karmic
[00:20] <directhex> the manpage is there
[00:21] <directhex>   * debian/rules:
[00:21] <directhex>     - Disabled gnometris as it requires clutter to build
[00:21] <directhex> there you go.
[00:22] <RAOF> That might be enabled again later; IIUC clutter is aiming for promotion to main for Empathy + geoloc?
[00:34] <TheMuso> dtchen: I think you said the otehr day you have been working on rtkit. Do you have anything up anywhere that I could use as a starting point to get pulse 0.9.16 into my PPA for karmic?
[00:37] <kirkland> cjwatson: okay, i have successfully installed and booted karmic-server-i386 and jaunty-server-i386, both of which I expect are PAE kernels
[00:38] <kirkland> cjwatson: my host is an x86_64 jaunty system (running karmic's virt packages)
[00:39] <Caesar> slangasek: so it sounds like in both cases it's a manual process to notice changes?
[00:39] <slangasek> Caesar: prior to DebianImportFreeze, changes to the /package/ are automatically imported.
[00:39] <slangasek> changes to /bugs/ aren't going to be noticed automatically
[00:39] <Caesar> slangasek: I mean for the lifetime of the release that contains that package, particularly LTS releases
[00:40] <slangasek> that's certainly true, yes
[00:40] <Caesar> So it seems to me that there's some free work to be capitalised on if it could be automatically noticed
[00:40] <Caesar> and free improvements
[00:41] <Caesar> Again, using this libxcb thing as an example
[00:41] <slangasek> SRUs are entirely driven by user demand (where "user" may be "uploader"); I don't think we should automatically take bugs that are marked as RC in Debian and nominate them as SRU candidates
[00:42] <slangasek> the libxcb one seems to be an example of us not even keeping up with the demand for SRUs for bugs that users *have* said they care about, let alone auto-importing from debian
[00:43] <Caesar> Perhaps not automatically nominate them, but auto-import them as applicable?
[00:43] <ajmitch> auto-import the bugs or the package?
[00:43] <slangasek> I think that's broadly inconsistent with how we do bug management for released versions of Ubuntu today
[00:43] <Caesar> The bugs against the package
[00:43] <Caesar> slangasek: of course it is
[00:43] <Caesar> I wouldn't be having this conversation with you if it wasn't
[00:44] <ajmitch> there have been tools to track RC bugs filed against debian that could be fixed in ubuntu, which ought to be fixed to work better for multiple ubuntu releases
[00:44] <cjwatson> kirkland: I guess it must be i386-host-specific
[00:44] <ajmitch> but it's not an easy thing, there are many false positives
[00:44] <slangasek> Caesar: I mean that there are lots of other bugs that are in LP that we do know about already, and know they're applicable to released versions, but we don't mark them as applying to those releases unless we intend to SRU them
[00:44] <slangasek> so I don't think Debian bugs should be treated differently
[00:45] <Caesar> Not even fixed bugs?
[00:45] <slangasek> but perhaps this is a discussion better had on ubuntu-devel to get wider perspectives, yeah
[00:45] <Caesar> I will write something up and email ubuntu-devel
[00:46] <slangasek> Caesar: opening tasks for bugs that are already fixed in the old release, just to close them?  sounds like busywork to me
[00:47] <Caesar> Huh?
[00:47] <Caesar> It's still applicable to that release
[00:47] <Caesar> So you're not going to close it
[00:48] <slangasek> Caesar: fwiw, I /personally/ strongly prefer the debbugs 'version tracking' workflow, but that's not the workflow Ubuntu uses in LP
[00:48] <Caesar> I realise that
[00:48] <Caesar> So your best option is to target to a specific release
[00:48] <slangasek> and not for lack of considering the debbugs model
[00:48] <slangasek> Caesar: ok, you meant bugs that are fixed in the latest release but still apply to previous releases - yep, tasks only get opened against the other releases if there's an expectation that they're SRU candidates
[00:48] <Caesar> So I guess I'm proposing that if Debian fixes a bug in a version of a package that ended up in an Ubuntu release, that bug gets imported into LP (possibly along with the fix) for consideration
[00:49] <slangasek> otherwise, it's implicitly "wontfix", so why open it
[00:49] <Caesar> slangasek: yes, I'm not talking about the current development release
[00:49] <slangasek> right, I just misunderstood what you meant by "fixed bugs"
[00:49] <Caesar> slangasek: you should know by now that I'm usually talking about released LTSes :-)
[00:50] <ajmitch> Caesar: as a rough start on something we've used for this for universe, see http://qa.ubuntuwire.com/bugs/rcbugs/
[00:51] <ajmitch> though it only shows info for the development release rather than fixes post-release
[00:51] <Caesar> ajmitch: that looks cool
[00:51] <Caesar> Looks like a good starting point
[01:48] <TheMuso> Yay. Either there is policykit or consolekit breakage that stops audio from working, permissions wise.
[01:49] <james_w> slangasek: we are in DebianImportFreeze aren't we?
[01:50] <maxb> Don't forget devicekit breakage too :-)
[01:51] <slangasek> james_w: ahhh, the things that sprint travel does to one's hold on reality
[01:51] <slangasek> james_w: yes, we're meant to be, but apparently I gave everybody an extension by running another round of autosyncs today ;)
[01:52] <james_w> score!
[01:52] <ebroder> "They're more of just guidelines anyway"
[01:53] <slangasek> siretart: why have you subscribed ubuntu-archive to bug #223212?  I don't see anything there that's a request for action
[01:53] <slangasek> siretart: (unsubscribing
[01:53] <slangasek> )
[01:56] <slangasek> superm1: you seem to have subscribed ubuntu-archive instead of ubuntu-mir for bug #390973; adjusted
[02:36] <superm1> slangasek, thanks, sorry my mistake
[02:36] <superm1> pitti, sure
[02:36] <billybigrigger> why does apt-cache policy nvidia-glx-180 show....nvidia-glx-180:
[02:36] <billybigrigger>   Installed: 185.18.14-0ubuntu1
[02:36] <billybigrigger> while nvidia-x-server settings shows 180.60
[02:38] <cody-somerville> billybigrigger, because they're different?
[02:38] <cody-somerville> billybigrigger, see #ubuntu for support please
[02:39] <superm1> nvidia-glx-180 has a -185 series driver though?
[02:39] <superm1> that doesn't seem right.
[02:39] <ajmitch> superm1: that's somewhat intended though
[02:39] <superm1> ajmitch, how so?
[02:40] <ajmitch> at least bryce had a reason for doing so when I asked about the package in his PPA
[02:40] <billybigrigger> well im just confused, as hardware drivers show's the 180 series installed
[02:40] <billybigrigger> so which driver am i using? 180 or 185?
[02:41] <superm1> billybigrigger, that's the 185 series driver, just the package is named 180 series
[02:42] <billybigrigger> seems a bit confusing to me
[02:42] <billybigrigger> wouldn't it make sense to label a 185 driver as 185, not 180?
[02:43] <superm1> billybigrigger, that's what i was saying too.
[02:43] <superm1> bryce, what's the reasoning for that?
[02:44] <ion> The Gtk 2.17.2 package is called libgtk2.0-0 for the same reason. It’s ABI-compatible, so other packages don’t need to constantly keep changing their dependencies for no reason.
[03:10] <StevenK> ScottK: Sorry for the delay, I'll be uploading livecd-rootfs presently
[03:47] <ScottK> StevenK: Thanks.
[04:00] <bryce> superm1, if the package gets renamed every time there is just a version number change, it makes bug management a PITA
[04:01] <bryce> honestly, I'd sort of rather the source package be named either xserver-xorg-video-nvidia, or nvidia-installer, for consistency with other drivers
[04:23] <superm1> bryce, ah
[04:24] <bryce> superm1, probably we should discuss the naming more
[04:25] <tedg> If ubiquity is core dumping (bug filed) is there still an easy way to install with the desktop CD?
[04:25]  * tedg doesn't want to download another CD.
[04:25] <bryce> it'd be nice to have a "stable" name.  the -177 to -180 transition was awkward as far as bugs go
[04:26] <superm1> bryce, ah so maybe the stable name is always the same and if there needs to be a legacy drivers then add more source packages
[04:26] <bryce> that seems like a better scheme
[04:26] <persia> bryce, Any suggestions?  We dropped -legacy and -new because it confused people.  Having 4 nvidia-foo packages is somehow useful, and I suspect we'll only get more.
[04:27] <RAOF_> Heh.  nvidia-glx, nvidia-glx-legacy, nvidia-glx-legacy-legacy, nvidia-glx-really-get-another-gfx-card-damnit-legacy? :)
[04:27] <bryce> actually there's just 3 packages.  -177 went away once -180 was moved to
[04:27] <persia> I see -71, -96, -173, and -180 on i386.  What shouldn't be there?
[04:28] <bryce> oh yeah -71
[04:28] <billybigrigger> http://pastebin.ca/1479097
[04:28] <bryce> but I think that may not be updated to the jaunty kernel
[04:28] <billybigrigger> so im not the only one complaining about the naming of 180 or 185
[04:28] <billybigrigger> :P
[04:28] <persia> I was looking at karmic, but hrm.
[04:28] <billybigrigger> is this a normal error?
[04:28] <RAOF_> persia: I'd guess it's in the archive but actually unusable.
[04:29] <Kage_Jittai> Can I talk to someone about package development, my project is having a issue
[04:30] <persia> -71 was last uploaded to jaunty 29 January.  If it's not useful, I think it ought be removed from the archive.
[04:30] <persia> Kage_Jittai, What specific question do you have?
[04:30] <DoYouKnow> it took me a while to find out that bcmwl-kernel-sources was the right package to install for broadcom sta wireless driver
[04:31] <RAOF_> It'd be useful if it works; there are some gpus only supported by -71.  I'm just checking whether or not it actually builds.
[04:31] <DoYouKnow> finally got it though
[04:31] <Kage_Jittai> persia: I work on a project called The Mana World
[04:31] <Kage_Jittai> persia: its a MMORPG
[04:31] <DoYouKnow> someone told me but I was in kind of a jumpy mood so I was confused
[04:31] <Kage_Jittai> persia: Our issue is with LTS distros
[04:31] <DoYouKnow> finally figured it out after a good search on installing ubuntu on the dell mini 9
[04:31] <Kage_Jittai> persia: as a MMO, we are always coming out with new features
[04:31] <DoYouKnow> (in karmic)
[04:32] <Kage_Jittai> persia: many of these features are unsupported
[04:32] <Kage_Jittai> persia: since people connect to a server, and to play with others
[04:32] <superm1> DoYouKnow, jockey now supports offering that as of today or so
[04:32] <Kage_Jittai> persia: unsupported versions being used cause issues
[04:32] <DoYouKnow> ok
[04:32] <DoYouKnow> that must be the taskbar on the lower right
[04:33] <Kage_Jittai> persia: http://pastebin.com/d608d5889
[04:33] <DoYouKnow> err
[04:33] <DoYouKnow> or not
[04:33] <DoYouKnow> I'll look it up
[04:33] <Kage_Jittai> persia: that is a pastebin of yesterday's version information
[04:33] <Kage_Jittai> persia: as you see .24.1 is being used quite a bit
[04:34] <persia> Kage_Jittai, Hrm.  I think you have an issue with the philosophy of how we support releases.
[04:34] <Kage_Jittai> persia: how ever, we dropped support for .24.1 almost a year ago
[04:34] <persia> My recommendation would be to do one of the following:
[04:34] <Kage_Jittai> persia: well, as being the only real GPL MMORPG with a central server, our needs are special
[04:35] <persia> Hrm,
[04:35] <persia> With a central server, one of my options is out :(
[04:35] <ion> How about a backport to foo-backports?
[04:36] <RAOF_> persia, bryce: Yeah, in what shouldn't be a terrible surprise, nvidia-71 fails to build against 2.6.30-10-generic.  I guess someone should ask nvidia if they plan to support it, and remove the packages if not.
[04:36] <persia> Yeah, backports is probably the least bad option.
[04:36] <Kage_Jittai> we do offer backports, even package them our self
[04:36] <Kage_Jittai> but they never seems to get accepted into LTS distros
[04:36] <ebroder> Kage_Jittai: If you need everybody to be running the latest software, it seems like you really want to be running your own repository so you can control that
[04:36] <ion> And have the server tell people to enable -backports if they seem to be connecting with the old Ubuntu client
[04:36] <Kage_Jittai> ebroder: we don't need the latest software
[04:36] <persia> Kage_Jittai, We don't change packages on backporting, just recompile against backports.  Are you familar with the Ubuntu Backporting team?
[04:37] <Kage_Jittai> ebroder: we support .26 .27 .28 .28.1 .29 .29.1
[04:37] <Kage_Jittai> persia: no, that is most likely part of the issue
[04:37] <DoYouKnow> oh, jockey == restricted driver manager
[04:37] <persia> !backports
[04:37] <persia> Kage_Jittai, basically, you file a bug, get a few people to test following a specific procedure, and wait a week or two (usually).
[04:38] <persia> Then you can just tell your users to use backports (which gets distro authenticated and everything), to use a newer version.
[04:39] <Kage_Jittai> persia: can we somehow tell the backport team about our special needs?
[04:39] <bryce> wouldn't a PPA be better suited for this?
[04:39] <Kage_Jittai> we have .28.1 on ppa
[04:39] <Kage_Jittai> we even link to it
[04:40] <Kage_Jittai> but most people seem to still use the repo
[04:40] <persia> Kage_Jittai, I'm not sure I understand how your needs are special in the context of backports.  backports is often just the newest software, recompiled against the older stack.
[04:40] <persia> bryce, Also PPAs have architecture limitations, etc.
[04:41] <Kage_Jittai> I think part of the problem with our backports is we use guichan
[04:41] <Kage_Jittai> guichan seems poorly supported in older distros
[04:41] <bryce> persia, "architecture limitations"?  You mean, like no PPC?
[04:41] <persia> bryce, Yes.
[04:57] <Kage_Jittai> persia: well thanks for trying
[04:58] <persia> Kage_Jittai, Hrm?  Did something not work, or is there some special concern?
[04:58] <Kage_Jittai> persia: we have requested backports
[04:58] <Kage_Jittai> which go unanswered
[04:58] <persia> have you organised some testers?
[04:58] <Kage_Jittai> ^_-
[04:58] <Kage_Jittai> no, not really
[04:58] <persia> My memory is that there need to be several positive test reports for a backport to be approved.\
[05:00] <persia> And I seem to remember the backports team several times claiming that the lack of testers was the primary obstacle to getting backports done.
[05:00] <persia> So, I'd advise organising some testers, and having them report on the backports bugs.
[05:01] <Kage_Jittai> persia: we need more ubuntu geeks
[05:01] <Kage_Jittai> on our team
[05:01] <Kage_Jittai> any voluteers?
[05:01] <Kage_Jittai> :P
[05:02] <persia> Most people here are busy developing the next release.  You might try asking in #ubuntu, and sometimes in #ubuntu+1 (people testing the new release)
[05:02] <persia> #ubuntu-backports is theoretically the right place, but I almost never see anyone there when I join.
[05:02] <geofft> You could always get some of your users to test it, no?
[05:03] <geofft> Put a note on your PPA page saying "please test our backport so you don't have to use the PPA any more"
[05:03] <Kage_Jittai> we use a public ppa
[05:06] <Kage_Jittai> !backports
[05:07] <Kage_Jittai> Hardy really needs to be updated
[05:40] <Kage_Jittai> persia: ok I registered for launchpad
[05:40] <Kage_Jittai> how would I request the backport
[05:41] <persia> Kage_Jittai, I've only done it once, and years ago, so I'm probably not the best person to ask.  Does that wiki page not explain the process?  I think it's just filing a bug.
[05:41] <Kage_Jittai> it says to file the report, but doesn't say what type of details to give
[05:43] <persia> Oh, the package name, the version (in karmic) to backport, and the rationale for the backport should do it.
[05:44] <persia> That's where you'd explain that TMW is a MMORPG, and that you don't support .24 anymore, so need the backport so users can upgrade.
[05:44] <ScottK> What testing has been done is also important.  The testing standard for a backport is that it builds, installs, and runs.
[05:45] <persia> ScottK, Does that go in the initial request, or in tester comments (or both)?
[05:45] <ScottK> persia: It can all be done at once if the initial requestor is also the tester.
[05:46] <persia> ScottK, That makes sense, and probably makes for a better report.
[05:49] <Kage_Jittai> persia: this will work https://bugs.launchpad.net/ubuntu/+source/tmw/+bug/393724 ?
[05:51] <persia> You want "Please Backport"
[05:52] <Kage_Jittai> updated
[05:53] <persia> Kage_Jittai, Other than that, you just need the test reports, I think.
[05:54] <Kage_Jittai> *sigh*
[05:55] <Kage_Jittai> now the hardpart
[05:55] <persia> heh.
[05:56] <Kage_Jittai> persia: wanna volunteer?
[05:56] <persia> Kage_Jittai, Um, no.  I have a big stack of stuff I've already promised to do.
[05:58] <Kage_Jittai> I am infact on hardy, even though I use git version, how could I post test data?
[06:00] <ScottK> You need to backport the actual version and packaging that's in Karmic, and build and test that.
[06:00] <persia> Kage_Jittai, Well, take the karmic version, follow the instructions for backporting to produce a hady backport, and test that version.
[06:05] <Kage_Jittai> persia: these instructions are where?
[06:05] <persia> Kage_Jittai, On the backports wiki page, I thought.
[06:07] <persia> Kage_Jittai, Under "Backport Process", most of the way down the page.
[06:09]  * Kage_Jittai gives puppy dog eyes to persia
[06:10] <StevenK> Kage_Jittai: They don't work on him, which is a pity.
[06:10] <persia> About what?
[06:11] <Kage_Jittai> persia: doing the backport ^l^
[06:12] <persia> I can't do it: I'm not a member of the backports team.  And for testing, I honestly believe that if I put it in my queue, it would get done by others before I got to it.
[06:12] <Kage_Jittai> anyone that is part of the backport team?
[06:14] <persia> Kage_Jittai, You don't want a backport team person to look at the bug until it's tested.
[06:15] <persia> You need to get the testers first.  Once the testing is complete, then you want the backpoters.
[06:15] <ScottK> Because such a person would just mark it incomplete and then tell you to get it tested.
[06:15]  * ScottK really goes to bed this time.
[06:15] <ScottK> Good night.
[06:16] <Kage_Jittai> Grrr!
[07:02] <pitti> Good morning
[07:02] <ajmitch> morning pitti
[07:14] <siretart> slangasek: it seems to me that the package is in clear violation with http://www.ubuntu.com/community/ubuntustory/licensing and I thought the archive administrators might want to have a look and comment on that issue.
[07:16] <siretart> slangasek: in other words: this is clearly non-free software in 'main'. Doesn't really anyone care?
[07:20] <dholbach> good morning
[07:20] <persia> siretart, is it clearly non-free?  I read it as completely undocumented, leaving significant uncertainty as to the freeness.
[07:22] <siretart> persia: it comes without source, without any copyright notice and is in main. According to my reading of http://www.ubuntu.com/community/ubuntustory/licensing this is in violation of what we require for packages in 'main'
[07:23] <siretart> or at least I don't know how to understand the first point here in any other way: "Must include source code. The main component has a strict and non-negotiable requirement that application software included in it must come with full source code."
[07:24] <persia> OK.  That makes sense.  I seem to remember there being some debate about linux-firmware in the past (leading it to be a separate package).
[07:25] <persia> While I don't remember anything about missing licenses for specific items, I do believe that it was granted a special exception to be in main because otherwise the entire stack broke.
[07:25] <StevenK> So this firmware thing keeps coming up in Debian? Can we just not repeat here? Please?
[07:25] <persia> That said, if there exists some part of it that's not only without source, but actually non-free, it doesn't belong there.
[07:26] <siretart> persia: well, without any copyright statement, we have no basis to believe that we are allowed to redistribute it
[07:26] <siretart> and moreover, "special exception to be in main because otherwise the entire stack broke" is in clear contrast to "non-negotiable requirement that application software included in it must come with full source code."
[07:26] <persia> siretart, I'd argue we also have no basis to believe we cannot ship it, but yes.  Still, the solution is to investigate, rather than remove.  The cost is high.
[07:27] <persia> Hrm.  That's also true.   Either my memory or that wiki page is in error.
[07:27] <siretart> I'm sorry, how can we possibly believe to retain any credibility here if we simply look away here?
[07:27] <persia> Um, I think you perceive my input as something other than it is.
[07:28] <siretart> possibly
[07:28] <persia> If you want to file a removal bug, go ahead.  I don't read that as a removal bug.
[07:28] <siretart> there is already a bug, and I subscribed the archive admins to comment on it
[07:28] <siretart> slangasek just unsubscribed from there
[07:28] <persia> You're talking about bug #223212?
[07:28] <siretart> I really hope there is some misunderstanding here
[07:29] <siretart> yes
[07:29] <persia> Right.  I don't see a request to remove the package in the log of that bug.
[07:29] <siretart> because that's pointless, we do have a place for that in ubuntu. it's called 'restricted'
[07:30] <StevenK> siretart: Right, so you subscribe ubuntu-archive without even commenting in the bug that you'd like ubuntu-archive to comment on the package in question, and you're suprised when slangasek just unsubscribes ubuntu-archive?
[07:30] <persia> I think you need to make clear what action should be taken.
[07:30] <StevenK> Just because we're memebers of ubuntu-archive doesn't mean we can read minds.
[07:30] <persia> Putting it in restricted breaks ogre-model, but it quite likely possible with some wrangling.
[07:31] <siretart> StevenK: well, yes, I'm indeed a bit surprised here. when I did that, a fellow DD pointed me to the issue, but I was at work and a bit in a hurry
[07:31] <siretart> StevenK: in the end, you suggest me to comment on the bug and then re-subscribe ubuntu-archive?
[07:31] <StevenK> No, just saying.
[07:32] <StevenK> I hate how this issue keeps coming up over and over and over and over in Debian, and I don't want the same thing to happen here.
[07:32] <persia> siretart, I'd recommend you make a clear statement of what action should be taken prior to subscribing ubuntu-archive.  Moving it to restricted probably first requires some fiddling with the kernel dependencies, which would involve working with the kernel team.
[07:33] <siretart> StevenK: so do I. and I thought that we had settled that in ubuntu by other means than putting heads in the sand
[07:33]  * persia has had little success with soliciting ubuntu-archive comment when it comes to policy in the past
[07:33] <pitti> what would be bad with moving it to restricted?
[07:33] <persia> pitti, Dependencies, mostly.  Probably just needs some sorting.
[07:33] <pitti> persia: indeed, tech board is more authoritative in that regard
[07:34] <pitti> ubuntu-archive executes policy, we don't actually define it in that scope
[07:34] <StevenK> pitti: linux-image-generic Depends on linux-firmware
[07:34] <persia> pitti, Well, perhaps, although I find that generall a developer statement is sufficient for most things, if they don't break anything.
[07:34] <StevenK> pitti: linux-generic is in restricted, and linux-image-generic is in main
[07:34] <pitti> this should be solved by TB and checked for feasibility with kernel team IMHO
[07:35] <siretart> I'm surprised that we have a different understanding of policy here. up to now I thought http://www.ubuntu.com/community/ubuntustory/licensing was pretty clear
[07:35] <persia> siretart, I don't think anyone is arguing about policy.  It's just the mechanics involved.
[07:35] <pitti> indeed, so then we could theoretically shuffle the metapackages
[07:35] <StevenK> siretart: So, we should just purge it from the archive and break the world?
[07:35] <siretart> but half of the archive team thinks this should go via TB, well, then so be it
[07:35] <pitti> e. g. linux-generic could pull in the firmware, and linux-image* stop depending on it
[07:35] <persia> Um, no it's that the TB makes policy.
[07:35] <pitti> siretart: TB -> change of policy
[07:36] <persia> This doesn't need a policy statement: there is clear policy.
[07:36] <siretart> I think policy is just fine here. the implementation isn't.
[07:36] <pitti> if we just have a bug (wrong component), and you don't want to change the policy, TB isn't actually needed
[07:36] <StevenK> pitti: I recall rtg had a reason why he didn't do that, but I don't recall what it is.
[07:36] <persia> It's just that the mess of linux and linux-meta and linux-firmware needs to be sorted to not break the world.
[07:36] <siretart> StevenK: well, at some point this has been accepted into main. I think this was an error.
[07:36] <pitti> StevenK: you can install Ubuntu with "free software only", but well, then you have to keep both pieces if it breaks for you
[07:36] <pitti> siretart: *nod*
[07:37] <pitti> the "linux" metapackage is in restricted for a similar reason
[07:37] <persia> siretart, I remember when it was accepted into main.  It was done because it introduced no new components.  The questionable bits came from upstream at some point nobody can identify in prehistory.
[07:38] <pitti> so, AFAICS, if we move linux-firmware dependency from linux-image-generic to linux-image, and move linux-image and l-firmware to restricted, it should be all good
[07:38] <siretart> persia: you are aware that your last statement can be read in a pretty malicious way, are you?
[07:38] <persia> Can we not just clean up the confusing set of metapackages?
[07:38] <persia> siretart, Erm, no.  Sorry.  It wasn't intended that way.
[07:38] <pitti> persia: you have another proposal?
[07:39] <persia> pitti, Well, we have linux, linux-generic, linux-image-generic, linux-image, etc.
[07:39] <persia> Do we really need that many?
[07:39] <siretart> persia: I know that you didn't mean it. I'm just saying that this argument will be perceived outside ubuntu completely different than you mean it here
[07:39] <pitti> persia: not on i386/amd64 right now, I think
[07:40] <persia> siretart, Ah.  I understand.  Right.
[07:40] <persia> pitti, Do you know why not?  I remember this being discussed for the past 3-4 cycles, and it's always too late in the cycle to fix it, or there's some other reason.
[07:41] <persia> But just moving the dependency should be sensible, and allow migration to restricted.
[07:41] <slangasek> siretart: I unsubscribed the archive admins because all you did was subscribe us, without saying what you wanted.  And if you want it /removed/, then that would appear to be an inter-developer dispute, which I don't intend to mediate with my archive admin hat, to be sure
[07:41] <siretart> that sounds quite right to me
[07:41] <pitti> persia: well, re-thinking about it, we still have several flavours (-i386, -generic, -server, -rt, etc.), so we probably still need them all
[07:41] <slangasek> for my part, I'm not convinced moving it to restricted is the correct course of action
[07:42] <siretart> slangasek: okay, sorry for that, I was under the wrong impression that the bug was already clear. now I see that it is not
[07:42] <persia> pitti, I guess the one I don't understand the most is the distinction between "linux" and "linux-image".  They seem to differ by a single transposed word.
[07:42] <siretart> slangasek: can you please elaborate? How can we keep it in main without violating http://www.ubuntu.com/community/ubuntustory/licensing?
[07:43] <persia> slangasek, Or were you saying that removal may be the more appropriate action?
[07:43] <superm1> persia, before karmic, having linux and linux-image made sense because linux pulled in LRM as well as linux-image
[07:43] <superm1> now for karmic since there is no more LRM, the linux meta package itself makes less sense
[07:43] <slangasek> siretart: note that this page says "application software", which firmware are not
[07:44] <persia> superm1, No, l-r-m was always pulled by linux-image-flavour, because l-r-m can be flavour-specific.
[07:44] <persia> (or maybe it was linux-flavour)
[07:44] <pitti> persia: AFAIUI, "linux-image" -> the actual kernel, like bzimage and modules; "linux" -> everything around it, such as restricted-modules, firmware, etc.
[07:44] <slangasek> we do allow non-applications in main that don't permit free modification; e.g., RFCs
[07:44] <superm1> persia, i'm looking at apt-cache depends linux on jaunty right now. the only two depends are linux-image and linux-restricted-modules
[07:45] <superm1> where linux-restricted-modules is another metapackage
[07:45] <persia> superm1, Hrm.  Maybe I'm confused.  I filed a bug about this a long time ago, was told it couldn't be fixed easily, and forgot some of the detals.
[07:46] <superm1> persia, well now it really should be much more easily fixable with LRM gone, so i would recommend reviving said bug
[07:46] <slangasek> pitti: the split between linux-image and linux is "depends on restricted" and "doesn't depend on restricted"
[07:46] <slangasek> linux-image at various points in its history depends on linux-ubuntu-modules, too
[07:47] <siretart> maybe I'm too much from the embedded world, but for me "application software" does not necessarily imply to be software on the same processor the linux kernel runs on. anyway. the next point is that we require permission to redistribute and modify it. are you positive that we have that permission? the bug is about these missing copyright statements
[07:47] <persia> superm1, Perhaps.  Someone needs to sit down and untangle the mess.  It might be me, and it might be someone else.
[07:47] <YokoZar> hey guys, apt-get install branding-ubuntu and then open solitaire, tell me what you think
[07:47] <slangasek> siretart: no, I'm not positive; I agree that it's a bug, I just don't see that it's a bug that the archive admins can resolve, since our only available option is "pull it and make it uninstallable"
[07:48] <persia> siretart, There are two issues being conflated.  1) Should linux-firmware be in main and 2) does the current licensing of linux-firmware meet the requirements (even for firmware as documented at http://www.ubuntu.com/community/ubuntustory/licensing)
[07:48] <siretart> persia: perhaps you're right and these two issues should be discussed seperately
[07:49] <persia> siretart, There's a separate section for firmware further down on the page.  I'm not sure that the bug raised doesn't even break that guideline, although it needs investigation.
[07:49] <pitti> right, so 1) is the easy part here; (2), figuring out their licenses, is the real work here
[07:50] <persia> Well, 1) is really making a call as to whether we consider the contents of the package "firmware" or "application software".  In the first case, main is fine (as I read the page).  In the second case, it belongs in restricted.  Probably easier to put it in restricted to avoid the argument, but needs confirmation from the kernel team.
[07:51] <persia> In terms of undocumented licenses, I think we ought follow the practices we've followed in the past: when we encounter something where licensing is unclear (take a look at the copyright files for a bunch of stuff in Priority:required sometime), we try to fix them or work around any discovered issues.
[07:53] <slangasek> moving linux-firmware to restricted also breaks the ogre model in that it builds two udebs that are embedded in the d-i initramfs
[07:53] <slangasek> (nic-firmware, scsi-firmware)
[07:53] <persia> Aha.  That's the part that breaks.  Thanks for the clarification.
[07:54] <pitti> superm1: I answered to the jockey-text merge request, BTW
[07:55] <siretart> ah, okay, this makes things more clear. but I need to leave now, will be back later. cu
[09:26] <cjwatson> siretart: that page is absolutely explicit about whether firmware is application software; it says that it is not.
[09:27] <cjwatson> "Ubuntu contains licensed and copyrighted works that are not application software. For example, the default Ubuntu installation includes documentation, images, sounds, video clips and firmware."
[09:27] <cjwatson> (I've followed up to the bug separately)
[09:28] <cjwatson> pgraner: bug 223212 needs attention from your team, I think
[10:02] <dholbach> seb128: can you please change the Maintainer from pidgin to ubuntu-devel-discuss instead of ubuntu-devel with one of the next uploads?
[10:03] <dholbach> tkamppeter: ^ same goes for some of the printer related packages
[10:03] <dholbach> update-maintainer of the ubuntu-dev-tools package will take care of it for you
[10:03] <dholbach> (mails get into the ubuntu-devel@ moderation queue because of it)
[10:05] <seb128> dholbach, why?
[10:05] <seb128> which mails?
[10:05] <dholbach> archive@ubuntu.com mails
[10:05] <seb128> an upload should not spam any mailing list
[10:06] <vise> if my software-0.0.2 is open source till date, can i now make it closed source at software-0.0.3 version?
[10:06] <vise> it has lgpl currently...
[10:08] <dholbach> seb128: they do get into the moderation queue though
[10:08] <seb128> dholbach, I'm a bit concerned that an upload spam a mailing list, would that mean that emails would land on ubuntu-devel-discuss when I upload pidgin?
[10:08] <cjwatson> they manifestly don't ...
[10:09] <dholbach> seb128: I'm not moderator of that list, so I don't know - maybe archive@ubuntu.com is explicitly blocked there
[10:09] <seb128> well, if they go in the moderation queue that's because they try to go there, if I change the email for an open list one what would block the email?
[10:09] <cjwatson> vise: I don't think you should really be expecting free software developers to give you advice on taking your program away from us
[10:09] <cjwatson> to be perfectly honest :)
[10:09] <seb128> dholbach, what do those emails say?
[10:10] <dholbach> seb128: it's the usual archive@ubuntu.com emails you get on every upload, plus the "rejected"ones
[10:10] <dholbach> seb128: I just noticed pidgin and a few printing related packages
[10:10] <vise> cjwatson: I dont want to either.. But please.. :)
[10:10] <dholbach> also I'd like to get the merge proposal mails for ~ubuntu-core-dev from that list
[10:10] <dholbach> but I don't know what to do there
[10:11] <Hobbsee> dholbach: er, what?
[10:11] <cjwatson> vise: it's my understanding that you can't withdraw the licence already given for software-0.0.2, so people can continue to modify and distribute that; furthermore, if you've incorporated code from anyone else under the LGPL then you don't have the right to make that closed-source. For anything else, I suggest asking your lawwyer
[10:11] <cjwatson> lawyer
[10:12] <dholbach> Hobbsee: what what? :)
[10:12] <seb128> dholbach, I'm not sure to understand what is going on but I will change the email address anyway, still seems weird that the lists are mailed on upload
[10:12] <Hobbsee> seb128: they really aren't.
[10:12] <dholbach> Hobbsee: aren't what?
[10:12] <vise> cjwatson: tyvm
[10:12] <cjwatson> dholbach: I suspect we probably ought to add an ubuntu-reviews mailing list
[10:13] <Hobbsee> dholbach: the lists (u-d, u-d-d) aren't mailed on upload
[10:13] <dholbach> cjwatson: that sounds sensible, we could route the sponsoring there too
[10:13] <Hobbsee> dholbach: did you want the merge proposals on u-d, or not?  I'm unclear with what you're saying thee
[10:13] <dholbach> Hobbsee: let me do a pidgin upload that is going to be rejected - just a sec
[10:13] <dholbach> Hobbsee: I'd prefer not having them
[10:13] <dholbach> on ubuntu-devel@
[10:14] <Hobbsee> right
[10:14] <cjwatson> they were only ever temporarily on ubuntu-devel@, until they got past the point when they were manageable there
[10:15] <dholbach> ok pidgin right now has Maintainer: Ubuntu Core Developers <ubuntu-devel@lists.ubuntu.com> - what the ubuntu-devel@ moderation queue in a few minutes
[10:15] <dholbach> now
[10:15] <Hobbsee> cjwatson: so we'e dopping the erge requests?  so far, iv'e just been skippign them
[10:16] <Hobbsee> ah, that did dop in the moderation queue
[10:16] <pitti> dholbach: (not sure whether it matters, but theh usual maintainer is u-devel-discuss@)
[10:16] <Hobbsee> as fo how changing the addess to u-d-d will help mattes at all, i don't know
[10:16] <cjwatson> Hobbsee: they're generally supposed to be let through for now, AIUI, but we probably ought to move them to a separate list soon
[10:16] <dholbach> pitti: yes, that's what I'm saying - a few packages have ubuntu-devel@ (which is a mistake)
[10:16]  * cjwatson screws Hobbsee's 'r' key back on
[10:17] <StevenK> Hehe
[10:17] <Hobbsee> cjwatson: right.  and thanks - but you'll need to do that fo a few othe keys too
[10:17] <Laney> why don't we see mails for all packages that get uploaded? or are they always rejected by u-d-d?
[10:17] <cjwatson> I *assume* that the u-d-d list configuration bins them
[10:17] <Hobbsee> (bing on my netbook!)
[10:17] <dholbach> I guess that in the configuration of u-d-d there's either a handler that drops them or the email address blocked completely somewhere else
[10:18] <cjwatson> would probably be easy enough to do that in the u-d configuration too, but in this case it's fortuitously letting us know of a mistake in Maintainer ;-)
[10:18] <dholbach> evand would be able to tell
[10:18] <dholbach> cjwatson: I'm happy to pester people :-)
[10:18]  * Hobbsee nicks StevenK's USB keyboard, and can type again.  woot!
[10:33] <tkamppeter> dholbach, which printing-related packages spam ubuntu-devel@? I did not find any?
[10:34] <dholbach> tkamppeter: I'll let you know with the next ones I encounter, nevermind for now :)
[10:58] <dholbach> tkamppeter: I take it back
[10:59] <dholbach> here's the list of packages that still have ubuntu-devel@lists.ubuntu.com:
[10:59] <dholbach>  alcovebook-sgml
[10:59] <dholbach>  ant
[10:59] <dholbach>  automake1.9-nonfree
[10:59] <dholbach>  intltool-debian
[10:59] <dholbach>  kernel-wedge
[10:59] <dholbach>  keymapper
[10:59] <dholbach>  kmplayer
[10:59] <dholbach>  libgnucrypto-java
[10:59] <dholbach>  libio-string-perl
[10:59] <dholbach>  libnet-ip-perl
[10:59] <dholbach>  libparse-debianchangelog-perl
[10:59] <dholbach>  libtext-format-perl
[10:59] <dholbach>  libxfontcache
[10:59] <dholbach>  libxml-namespacesupport-perl
[10:59] <dholbach>  libxvmc
[10:59] <dholbach>  pan
[10:59] <dholbach>  pidgin
[10:59] <dholbach>  pwlib
[10:59] <pitti> pastebin FTW!
[10:59] <dholbach>  pythondialog
[10:59] <dholbach>  python-unit
[10:59] <dholbach>  sockstat
[10:59] <dholbach>  ttf-bitstream-vera
[10:59] <dholbach>  ttf-bpg-georgian-fonts
[10:59] <dholbach>  witalian
[10:59] <dholbach>  x11proto-print
[10:59] <dholbach>  xcursor-themes
[10:59] <ogra> oh my
[11:00] <pitti> dholbach: i. e. pretty much the ones that nobody touched in years, and thus shouldn't cause mail spam
[11:00] <pitti> well, them, and pidgin
[11:35] <tseliot> cjwatson: I installed my script for hardware detection to /lib/debian-installer-startup.d/ (from a udeb which depends on dmidecode-udeb) and bootstrap.log shows that dmidecode was installed. Is there some other log I should read to investigate the failure of my script?
[11:35] <tseliot> cjwatson: my script: https://pastebin.canonical.com/19132/
[11:36] <cjwatson> bootstrap.log is entirely irrelevant - look at the installer syslog
[11:36] <cjwatson> if you've completed installation, it's in /var/log/installer/syslog
[11:37] <cjwatson> for something that short, though, maybe just run it by hand in the installer environment and see if it works :)
[11:38] <cjwatson> tseliot: oh, you'll need to actively halt or something rather than just exiting 1. debian-installer-startup ignores exit codes
[11:38] <tseliot> cjwatson: oh, how do I halt the installer then?
[11:38]  * ogra would also check for $RET != 0 and drop two lines :)
[11:39] <tseliot> ogra: yes, that would help debugging
[11:42] <cjwatson> tseliot: 'halt'
[11:42] <tseliot> cjwatson: there's no trace of dmidecode in /var/log/installer/syslog: https://pastebin.canonical.com/19133/
[11:42] <cjwatson> tseliot: then it probably didn't go wrong
[11:42] <tseliot> shouldn't it be pulled automatically as a dependency?
[11:42] <cjwatson> sure, but why would that be in the runtime log?
[11:43] <cjwatson> are you rebuilding d-i to include this?
[11:43] <cjwatson> debian-installer-startup.d is run before any runtime component installation happens
[11:43] <tseliot> we set up  a new project to do it
[11:43] <cjwatson> so you need to rebuild d-i to include any scripts there
[11:44] <cjwatson> if you want to investigate whether dependencies are pulled in, you should check the *build* log
[11:44] <cjwatson> also, you could do this in a much more lightweight way without dmidecode - just look in /sys/class/dmi/id/product_name
[11:44] <tseliot> ok, let me check
[11:47] <tseliot> cjwatson: yes, dmidecode was installed
[11:47] <tseliot> and thanks for the tip about /sys/class/dmi/id/product_name
[12:15] <A|i> is this the channel for ubuntu debian package maintainers?
[12:16] <ogra_> A|i, the /topic should say it all
[12:16] <A|i> ogra_, which channel is for package maintainers?
[12:16] <ogra_> i wuld go to -motu for a start
[12:17] <ogra_> *would
[12:17] <A|i> i dont want to pack, i want to report a problem
[12:17] <ogra_> for a specific package ?
[12:17] <cjwatson> you should file a bug, then
[12:17] <A|i> yes
[12:17] <ogra_> ubuntu-bug -p <packagename>
[12:18] <A|i> i know, but i was wondering if the package maintainers are around
[12:18] <ogra_> they are usually subscribed to all bugmail
[12:19] <A|i> ok thanks
[13:07] <pgraner> cjwatson: that bug is on my radar as part of the license clean up with legal.
[13:07] <cjwatson> thanks
[14:28] <Pistos> Hello, is anyone around who is even remotely connected with Ruby on Ubuntu?  I think I have found a bug in the Ubuntu build of Ruby 1.9, because it doesn't appear on Debian or Gentoo, or when Ruby 1.9 is built from source on Ubuntu.
[14:30] <cjwatson> ha!
[14:30]  * cjwatson nails bug 185878
[14:30]  * ogra applauds
[14:30] <cjwatson> pain, suffering, and more pain
[14:31] <StevenK> Duh, it involves GRUB
[14:31] <StevenK> Oh, even better, it looks to be a race condition.
[14:32] <cjwatson> I'm not actually 100% sure it's racy; it's a cache coherency bug
[14:32] <StevenK> Disk cache coherency?
[14:32] <cjwatson> writing to a partition device when you still have the disk device open does not guarantee that you will get new data back when you read from the disk device
[14:33] <cjwatson> ioctl(BLKFLSBUF) fixes
[14:36] <DoYouKnow> is that something that appeared today?
[14:37] <directhex> which file lists packages in main (with hopefully justification)?
[14:39] <StevenK> directhex: Packages in main have to be held there by being seeded or a build-dependancy or so
[14:39] <DoYouKnow> I thought I installed to ext4, although I'm not sure about the boot partition
[14:39] <DoYouKnow> and grub works fine
[14:42] <cjwatson> DoYouKnow: the bug description overstates the case a bit
[14:42] <cjwatson> DoYouKnow: see my last comment for a more accurate description of what's affected
[14:42] <directhex> StevenK, i'm trying to work out why mono-tools is in main. i suspect monodoc-browser is to blame
[14:43] <StevenK> directhex: The germinate output should tell you that.
[14:43]  * StevenK tries to remember where it lives.
[14:45] <cjwatson> http://people.ubuntu.com/~ubuntu-archive/germinate-output/
[14:47] <StevenK> Hmmm. unr.karmic isn't in that list.
[14:47] <cjwatson> feel free to edit ~ubuntu-archive/bin/update-germinate on rookery to add it
[14:47] <StevenK> cjwatson: I was going to ask for a hint, thanks. I'll fix it tomorrow.
[14:49] <directhex> hm
[14:50] <directhex> as far as i understand it... supported-development.seed lists monodoc-webkit-manual
[14:50] <directhex> meaning the documentation browser gets pulled in, meaning i need to merge mono-tools to disable the asp.net documentation browser
[14:54] <tseliot> cjwatson: what's your opinion on bug 172830?
[14:55] <cjwatson> tseliot: it's a bikeshed bug and not easily fixed in a way that will satisfy everyone; if you have a problem with the current value I suggest using preseeding facilities to change it
[14:56] <cjwatson> "reserved_for_root{ 1% }" or whatever in a recipe
[14:57] <mattn__> installing the package diff-ext on 9.04 leads to nautilus crashes when right clicking a file
[14:57] <mattn__> uninstalling it again solved the issue
[14:58] <cjwatson> tseliot: right now partman does not have a way to dynamically scale the percentage depending on the size of the disk, and I think there are still plenty of situations where you might be creating a relatively small filesystem
[15:00] <Chipzz> cjwatson: not wanting to start a flamewar, but what arguments would there be in favor of it for large partitions? or is it purely a technical issue like you said?
[15:00] <cjwatson> read the bug.
[15:00] <cjwatson> the arguments in favour of larger percentages are for *small* partitions, not large partitions.
[15:01] <cjwatson> hence a need for some kind of inverse scaling.
[15:01] <Chipzz> I did, but you said it was a bikeshed bug (implying that there are arguments both in favor and against of it)
[15:01] <tseliot> cjwatson: ok, I see your point
[15:01] <cjwatson> Chipzz: whatever
[15:01] <Chipzz> cjwatson: idd whatever, was just curious anyway :)
[15:01] <cjwatson> Chipzz: if implemented crudely (i.e. just changing the percentage), it's a bikeshed bug because I'd just get a different bug asking to put it back up again.
[15:01] <cjwatson> Chipzz: avoiding the bikeshed requires more sophisticated code
[15:02] <cjwatson> I'm sorry I didn't spell that out in detail, I was rushing to get ready for a meeting
[15:03] <Chipzz> get ready for your meeting :)
[15:03] <Chipzz> no need to get late to satisfy my curiousity ;)
[15:05] <cjwatson> (and sorry, I didn't mean to be terse)
[15:05] <cjwatson> grub has put me in a foul mood
[15:05] <Chipzz> cjwatson: no offense taken - now go get ready! :)
[15:07] <Chipzz> tseliot: I wonder in what context you were asking about this bug; wouldn't that bug only affect alternate and server installs?
[15:07] <Chipzz> or does it affect ubiquity too?
[15:07] <tseliot> Chipzz: OEM stuff
[15:07] <tseliot> and yes, alternate installs
[15:07] <tseliot> well, what we use for OEM
[15:08] <Chipzz> tseliot: I'ld say that OEMs should have enough clue to preseed an appropriate value?
[15:08] <tseliot> Chipzz: yep
[15:08] <Chipzz> (appropriate for the model on which it's installed)
[15:08] <Chipzz> so largely irrelevant IMO?
[15:08] <Chipzz> (well for your use case anyway)
[15:09] <cjwatson> for the record ubiquity uses partman-auto in more or less the same way that d-i does
[15:09] <cjwatson> certainly recipes are applied identically
[15:10] <tseliot> Chipzz: communication is always useful ;)
[15:12] <Chipzz> tseliot: anyway just my 2 cents :)
[15:20] <Pistos> Okay, FWIW, I filed a full report: https://bugs.launchpad.net/ubuntu/+source/ruby1.9/+bug/393888
[15:46] <andrew_sayers> Hi evand, I just replied to your message about the migration assistant.  We can talk in here if you prefer.
[15:49] <evand> andrew_sayers: email is probably best at the moment as it will give me a chance to mull over what you've sent.  I'll take a look at it shortly, just have a few things I need to sort first.
[15:49] <andrew_sayers> evand: sure.
[15:52] <pitti> TheMuso, dtchen: do you plan to package pulse 0.9.16test1? (https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-June/004256.html)
[15:54] <pitti> (lots of fixes, and de-hal-ification)
[15:55] <seb128> pitti, speaking about pulseaudio do you have sound on your laptop and karmic?
[15:56] <pitti> seb128: last tested yesterday, lemme check again
[15:57] <pitti> seb128: hm, indeed it's just silent
[15:57] <seb128> same here
[15:58] <pitti> that worked yesterday
[15:58] <pitti> and it's not just the mixer (which tends to be silent by default nowadays)
[15:58] <seb128> lucky you I don't have sound on my laptop for several days
[15:58] <seb128> I've tried to tweak all the mixer settings with no luck
[15:59] <pitti> killall pulse doesn't work either, though, so it seems to be an alsa issue
[15:59] <pitti> oh, hang on
[15:59] <pitti> -EPERM?
[15:59] <pitti> getfacl /dev/snd/pcmC0D0c -> FAIL
[16:01] <pitti> seb128: investigating, thanks for poking
[16:01] <seb128> where?
[16:01] <seb128> not here
[16:01] <seb128> but I didn't upgrade my laptop today
[16:01] <seb128> I was trying to stay away from the libudev issue
[16:01] <pitti> seb128: nothing to do with gudev
[16:01] <pitti> seb128: are you not in the "audio" group?
[16:01] <seb128> thanks for looking ;-)
[16:01] <pitti> killall pulseaudio; sudo aplay /usr/share/sounds/card_shuffle.wav
[16:02] <pitti> ^ please verify that this works
[16:02] <mdz> cjwatson: Keybuk: which of you chaired the last TB?
[16:02] <mdz> the other of you should chair the next one :-)
[16:02] <pitti> seb128: and that aplay /usr/share/sounds/card_shuffle.wav doesn't
[16:02] <seb128> pitti, I'm in the audio group (the gudev breakage is why I didn't dist-upgrade my laptop today)
[16:02] <seb128> pitti, why do I need to killall pulseaudio before trying?
[16:02] <ogra> mdz, colin did last
[16:02] <Keybuk> mdz: I think it's my turn next
[16:02] <seb128> pitti, aplay and paplay doesn't play any sound
[16:02] <pitti> seb128: eliminating potential breakage, and avoid running pulse as root
[16:02] <seb128> using sudo or not
[16:03] <pitti> seb128: sudo aplay doesn't work either? it works here
[16:03] <cjwatson> mdz: yes, I did
[16:03] <seb128> pitti, no but my sound is broken for a while not only since today so we probably have different isues
[16:03] <seb128> issues
[16:06] <pitti> seb128: getfacl /dev/snd/controlC0 for you?
[16:06] <seb128> yes
[16:10]  * directhex fluffles Keybuk, apologises for him needing to waste his time on position statements
[16:11] <ogra> directhex, dont be apologetic ...
[16:11] <ogra> its not your fault
[16:12] <seb128_> pitti, no error
[16:20] <pitti> seb128: ah, then you still have udev-extras
[16:20] <pitti> seb128: I just figured out what broke it
[16:20] <seb128> pitti, no I don't
[16:20] <seb128> that has been uninstalled yesterday
[16:21] <pitti> ah, then you don't get ACLs either
[16:21] <seb128> what do you mean?
[16:21] <seb128> acl doesn't return an error
[16:21] <seb128> group is audio and has rw-
[16:21] <pitti> right, but "seb128" certainly doesn't have an ACL
[16:22] <seb128> no, but the audio group should be enough no?
[16:22] <pitti> not for me
[16:22] <pitti> I'm not in audio
[16:22] <seb128> I'm in audio
[16:22] <pitti> ah, then this isn't what it breaks for you
[16:23] <seb128> no, as said I've no sound for a while there, not until since yesterday
[16:26] <dholbach> Can I interest somebody in giving a Packaging Training session at 02nd July, 06:00 UTC? https://wiki.ubuntu.com/Packaging/Training has lots of ideas for sessions
[16:36] <Pici> Is anyone aware what the plans for Firefox 3.5 in Jaunty are? I'd like to have an answer to give to the many people that are asking in the other support channels.
[16:37] <seb128> what plans?
[16:37] <seb128> it's in jaunty universe
[16:37] <Pici> oh, sorry, I thought it was in main. I misread.
[16:38]  * Pici pops over to -motu
[16:39] <seb128> you can ask your questions there but that is not a clear question, do you want to get a bug fixed there or something?
[16:40] <Pici> seb128: It appears that FF3.5 was released today, we're getting a lot of 'when is this update coming?' questions.  I know its a separate package, but its still the beta version in Jaunty.
[16:42] <seb128> asac, ^ is there any ppa or something with an updated firefox-3.5 for jaunty?
[16:44] <asac> seb128: yes. ~ubuntu-mozilla-daily has the RC (its not daily atm)
[16:44] <asac> seb128: once 3.5 final gets out we will update jaunty one
[16:44] <asac> Pici: ^
[16:44] <seb128> asac, somebody is claiming that 3.5 has been flagged stable today
[16:44] <asac> so yeah. release is today.
[16:45] <asac> seb128: yes. wasnt sure they woke up yet ;)
[16:45] <Pici> asac: Thanks, thats all I needed to know :)
[16:45] <asac> Pici: will take a day or two because we need to do some basic QA. if users asks tell them to enable ~ubuntu-mozilla-security
[16:45] <seb128> users are crack addicts, they ask for updates the second it's announced
[16:45] <asac> thats where this build will end up first
[16:45] <asac> Pici: and we always love to have more security staging testers ;)
[16:46] <Pici> seb128: believe me, I know. If I asked them whats so great about $newversion, most of the time they aren't able to answer.
[16:46] <seb128> "it's new!" ;-)
[16:46] <asac> Pici: so the crack addicts should use -daily ppa anyway ... the others should go for -security. thanks!
[16:57] <Pici> asac: sorry, just need a little clarification: Will the 3.5 packages be updated in Universe or will they only be in the PPA.
[16:57] <asac> Pici:  ~ubuntu-mozilla-security is the staging area for real archive ... it will first go there and then to universe
[16:58] <Pici> asac: Okay, thanks.
[16:59] <brettalton1> With SJR announcing that mono/C# is here to stay in the Ubuntu desktop, does this mean there will be discussion on Rhythmbox vs Banshee for Karmic? Or is that probably a LTS+1 thing? (aka 10.10)
[17:01] <dholbach> bryce, pitti: you know about the hal/xserver-xorg overwrite problem?
[17:01] <dholbach> /usr/lib/hal/debian-setup-keyboard
[17:01] <seb128> brettalton1, rhythmbox and banshee have already been discussed at uds
[17:01] <seb128> brettalton1, https://blueprints.launchpad.net/ubuntu/+spec/desktop-karmic-default-media-player-choice
[17:02] <brettalton1> seb128: exactly what I was looking for, thank you.
[17:02] <pitti> dholbach: I don't
[17:03] <seb128> dholbach, ask tjaalton since the did the upload maybe?
[17:03] <dholbach> http://paste.ubuntu.com/20038
[17:03] <dholbach> http://paste.ubuntu.com/207038
[17:03] <dholbach> sorry
[17:04] <pitti> tjaalton, bryce, dholbach: ah, I remember that Debian ships that file in xorg, while we ship it in hal
[17:04] <pitti> I don't mind removing it from hal, but we need the conflicts/replaces on xorg anyway
[17:04] <dholbach> sounds like a merge oversight?
[17:05] <tjaalton> oh yeah
[17:10] <tjaalton> pitti: will you drop it from hal? I'll add the C/R to xserver-xorg..
[17:10] <pitti> tjaalton: it's a little weird to have the .fdi in hal (which calls it) and the script in xorg
[17:10] <pitti> tjaalton: shouldn't the fdi be moved as well?
[17:11] <tjaalton> pitti: let me see where that is
[17:11] <pitti> /usr/share/hal/fdi/policy/10osvendor/10-x11-keymap.fdi I mean
[17:11] <tjaalton> it might be shipped by evdev in debian
[17:12] <tjaalton> no, it's in xorg
[17:13] <tjaalton> it's called debian-x11-keymap.fdi from now on :)
[17:13] <pitti> tjaalton: so I should drop that as well, to avoid having two
[17:14] <slytherin> cjwatson: Can you please point me to the powerpc chroot you had copied from buildd? I lost the link.
[17:14] <tjaalton> pitti: yes
[17:14] <cjwatson> slytherin: http://people.ubuntu.com/~cjwatson/tmp/karmic-powerpc.tar.bz2
[17:15] <tjaalton> pitti: sorry for the short notice, I had forgot about this completely
[17:15] <EvanCarroll> Pici: Dev's are crack addicts too, I want my firefox to not consume my whole PC, though I actually don't believe 3.5 will make a damn difference
[17:15] <slytherin> cjwatson: ahh, my mistake I overlooked it while checking files in tmp.
[17:16] <EvanCarroll> 3.5 seems like groundless chrome counter-hype
[17:16] <superm1> pitti, yeah I saw thanks.  i'll let you know as soon as I get a chance to make the recommended changes
[17:16] <EvanCarroll> 3.0 was supposed to be significantly faster than 2.5, and I didn't see a noticeable difference in that either.
[17:17] <EvanCarroll> and wtf is the firefox launchpage covered with dolphins?
[17:17] <EvanCarroll> mysql invasion?!?! surely it will be fastar!
[17:20] <pitti> tjaalton: ok, will be dropped from hal_0.5.12+git20090626-0ubuntu2_source.changes; testing and uploading
[17:21] <tjaalton> pitti: so I'll add C/R hal (<= 0.5.12+git20090626-0ubuntu1) to xserver-xorg
[17:21] <pitti> tjaalton: *nod*
[17:22] <tjaalton> oh man, mesa build makes my laptop boil
[17:24] <bryce> heya tjaalton and pitti; got the hal stuff sorted?
[17:24] <tjaalton> bryce: yeah, pushing right now
[17:24] <tjaalton> next to fix the mesa ftbfs
[17:30] <c_korn> why does the package text say that it is scilab-5.1-0ubuntu2 but it is scilab-5.1.1-6 (see the files at the right)? http://packages.ubuntu.com/karmic/scilab
[17:31] <pitti> tjaalton: uploaded
[17:33] <tjaalton> pitti: likewise :)
[17:33] <infinity> c_korn: Because the binaries are the old version, the source is the new version (it failed to build on all arches except sparc...)
[17:33] <infinity> c_korn: https://edge.launchpad.net/ubuntu/karmic/+source/scilab/5.1.1-6 might be a friendlier view of that situation.
[17:34] <cjwatson> or https://launchpad.net/ubuntu/+source/scilab for another level up; launchpad.net/ubuntu/+source/SOURCEPACKAGENAME is generally a good place to start in LP
[17:34] <infinity> cjwatson: Well, yes, but I was trying to point on the build failures. :)
[17:35] <c_korn> keytool error: java.security.NoSuchAlgorithmException: SHA384withECDSA Signature not available
[17:35] <c_korn>   error adding mozilla/COMODO_ECC_Certification_Authority.crt
[17:35] <cjwatson> right
[17:35] <c_korn> this is the error
[17:36] <c_korn> this is not an issue related to scilab
[17:37] <cjwatson> there's a sync request for that, which I'll process now
[17:37] <cjwatson> (bug 393830; bug 392104)
[17:37] <cjwatson> hmm, already processed
[17:38] <cjwatson> I'll retry scilab then
[17:41] <c_korn> cjwatson: ok, thanks
[17:41] <cjwatson> I'm not retrying ports architectures since openjdk seems to be uninstallable there
[17:44] <pitti> Keybuk: heh -- sed -i 's/srcdir/builddir/g' gtk-doc.make fixes it. completely. \o/
[17:45] <Keybuk> pitti: if we could get that upstream, that'd be awesome
[17:45] <Keybuk> (gtk-doc upstream, that is)
[17:45] <pitti> Keybuk: right, I'll file it to them
[17:47] <pitti> Keybuk: http://bazaar.launchpad.net/%7Eubuntu-core-dev/udev/ubuntu/revision/2480
[17:48] <pitti> Keybuk: so, it's "debcheckout", "debian/rules prep", and then dpkg-buildpackage just works
[17:48] <pgraner> bryce: ping
[17:49] <bryce> yep
[17:49] <cjwatson> kirkland: dunno if you noticed, by the way, but I fixed w3mman to handle formatting characters correctly. Is it easy to upgrade ubuntu-manpage-repository to karmic's w3mman, or would it be easier to work around it by setting the same environment variable in your code that calls w3mman?
[17:49] <pgraner> bryce: do you have any docs on setting up KMS with nouveau?
[17:50] <bryce> pgraner, not as such, but there's a ppa
[17:50] <bryce> https://edge.launchpad.net/~xorg-edgers/+archive/nouveau
[17:50] <bryce> some docs on that page
[17:51] <pgraner> brianchidester: yea I saw that, anything special after install ?
[17:51] <pgraner> bryce: ^^^^^^^^^^^
[17:51] <pitti> Keybuk: which stuff did you deliberately not install? I see the gudev gtk-doc (should go to libgudev-dev), ConsoleKit helper (absence breaks everything), udev.pc (should be in libudev-dev), README.keymap.txt (should be in udev)
[17:51] <bryce> pgraner, I've not actually been able to get it to successfully do kms on -nouveau, so don't know what more needs done, but something does
[17:52] <bryce> however I've not tried with raof's latest stuff
[17:52] <pgraner> bryce: ok, I'll try the ppa and see what I can get going. My desktop is a Nvidia and would like to see if I can get it working
[17:53] <bryce> pgraner, one thing I've noticed is that support varies widely from chip family to chip family
[17:53] <Keybuk> pitti: it may have gone now
[17:53] <bryce> G70 cards *should* work the best; earlier families maybe not so much
[17:54] <pitti> Keybuk: udev.pc by and large just has udevdir=/lib/udev and the version; do you think we should have that in udev itself? or ignore?
[17:54] <pgraner> bryce: I have a: nVidia Corporation GeForce 8600 GT
[17:55] <Keybuk> pitti: we should include it I guess
[17:55] <Keybuk> or maybe in libudev-dev
[17:57] <bryce> pgraner, yeah G80 cards like that should be really well supported (I've one as well)
[17:58] <pgraner> Keybuk: any idea of what this means when doing an upgrade in Karmic: E: /var/cache/apt/archives/xserver-xorg_1%3a7.4+3ubuntu1_amd64.deb: trying to overwrite `/usr/lib/hal/debian-setup-keyboard', which is also in package hal
[17:58] <cjwatson> means that somebody forgot the mandatory Replaces field when moving a file between packages
[17:58] <pgraner> cjwatson: what package should the bug go against?
[17:59] <seb128> it has been fixed but the update is not published yet
[17:59] <seb128> nowhere, it's fixed already
[17:59] <cjwatson> xserver-xorg but it was already discussed above
[17:59] <pgraner> seb128: ok, then I'll just wait
[18:01] <bryce> pgraner, in fact we just put in a fix for that hal/xorg conflict
[18:01] <pgraner> bryce: thanks...
[18:11] <pitti> Keybuk: ok, I think udev package is back in working order now, and building from tree is back to sanity
[18:15] <Keybuk> pitti: cool, please upload ;)
[18:15] <pitti> done
[18:15] <pitti> I want my sound and DRI acceleration back :)
[18:16] <Keybuk> :)
[18:16] <Keybuk> there's some bugs about that
[18:26] <djsiegel1> Keybuk: do you know the name of the package that lets me edit the wiki in my own out-of-browser editor?
[18:27] <cjwatson> editmoin
[18:27] <cjwatson> (I haven't used it in a while, don't know if it works at the moment)
[18:28] <elmo> it's all text (firefox extension) is also useful for that, FWIW
[18:28]  * cjwatson gives up on trying to make bughelper work (I assume it's been broken by some LP UI change again) and writes a 15-line launchpadlib script instead
[18:28] <cjwatson> is anyone working on a launchpadlib-ified version of bughelper?
[18:33] <Ampelbein> cjwatson: sort of. i rewrote bugnumbers to use lplib.
[18:34] <Ampelbein> cjwatson: i thought of rewriting bughelper, too.
[18:36] <cjwatson> as it happens I generally only use it for quick searches and it looks as if lplib is easy enough to use for that that I personally don't really need a fully-fledged tool, but others might
[18:38] <Ampelbein> cjwatson: I will see what I can do.
[18:39] <cjwatson> Ampelbein: cool :)
[18:42] <pitti> Keybuk: indeed, I closed bug 393591
[20:08] <cody-somerville> Is it safe to upgrade X now? Someone said earlier that it completely busts karmic up.
[20:09]  * ogra_ didnt have probs with yesterdays upgrade
[20:11]  * cody-somerville takes a deep breath and upgrades.
[20:11] <cody-somerville> odd
[20:11] <cody-somerville> update-manager refuses
[20:12] <cody-somerville> I click install updates and a popup window says reading state information while the main window greys out before disappearing and the main window ungreying.
[20:12] <ogra_> weird
[20:12] <cody-somerville> I'll assume its a sign not to upgrade
[20:21] <shaya> is there a reason that firefox-3.5 (yes, I know its rc2, not today's released) doesn't have HTML5 video support?
[20:25] <kirkland> hmm, /dev/null permed 600 in karmic makes many things very unhappy
[20:25] <slangasek> a /dev/null permed 600 anywhere makes things very unhappy
[20:28] <soren> kirkland: Is it at least still a device node?
[20:29] <Chipzz> /dev/null being a file instead of a device node makes things very unhappy :P
[20:29] <soren> kirkland: I once saw it replaced with a (very, very big) file, because someone accidentally removed it, and kept piping things to it as root.
[20:29] <Chipzz> soren: I had that happen once
[20:30] <Chipzz> soren: nfs server didn't come up after a reboot (the box was the file server for our web sites, and had been up for ages)
[20:30] <Chipzz> no idea what caused that
[20:30] <c_korn> hm ,http://pastebin.com/d78ca1ca9
[20:37] <kirkland> soren: was definitely a device file, might have been fixed in this last update
[20:41] <kirkland> slangasek: okay, i got my /dev/null back
[20:41] <kirkland> intel video is still hosed though
[20:41]  * kirkland reminds himself to never update while away from home
[20:48] <tormod> just as a word of warning, the last xorg (?) update might cause broken X
[21:05] <tormod> gdm 2.20.10-0ubuntu4 will fix X again
[21:13] <pitti> cjwatson: nice, upstream merged your unionfs-fuse patch
[21:15] <cjwatson> good
[21:15] <pitti> cjwatson: I'm currently sponsoring a new version into Debian which should fix the hardlink bug 386728, so we should sync this
[21:15] <cjwatson> sounds fair to me
[21:28] <pitti> what's wrong with the buildds?
[21:28] <pitti> they are all "private build" and disabled
[21:28] <pitti> infinity: ^
[21:28] <pitti> asking because the current gdm upload is super-urgent
[21:36] <maxb> Is anyone using a non-US keyboard, and so in a position to confirm that the xkb callout seems to have broken (once you've fixed the gdm conffiles)
[21:37] <seb128_> maxb, what gdm conffiles?
[21:37] <maxb> the ones referencing /usr/X11R6, which are fixed in above-mentioned super-urgent upload
[21:39] <seb128_> maxb, ah, that's not a conffile issue, that's a configuration issue
[21:40] <maxb> conffile/configuration whatever
[21:40] <maxb> Anyway, my point is that the callout seems broken to me, once I've fought past the already-reported breakage
[21:40] <infinity> pitti: They really are building private builds.
[21:40] <infinity> pitti: (security builds)
[21:40] <infinity> pitti: So, it's a bit of a "sucks to be you" for now. :/
[21:40] <pitti> ok, thanks
[21:40] <pitti> well, *shrug*, it's karmic :)
[21:40] <seb128_> infinity, suck to be users running karmic rather ;-)
[21:41] <maxb> Users running karmic should be entirely capable of self-deducing the proper fix :-)
[21:44] <maxb> pitti: Once the gdm stuff is out of the way, I think we have a re-regression of the "callout not being added" bug you debugged for me earlier in karmic
[21:44]  * maxb reads irc logs of that time
[21:45] <pitti> maxb: callout?
[21:46] <pitti> ugh, and the ppa buildds are asac'ed
[21:46] <seb128> pitti, great the gdm update doesn't build
[21:46] <pitti> *sigh*, no builds for me
[21:46] <seb128> Can't start Hardware abstraction layer - sysfs not mounted on /sys
[21:46] <seb128> Setting up xserver-xorg (1:7.4+3ubuntu2) ...
[21:46] <seb128> invoke-rc.d: initscript hal, action "restart" failed.
[21:47] <pitti> hal??
[21:47] <pitti> nothing should b-dep on hal
[21:47] <seb128> gdm build-depends on xorg-server which depends on hal
[21:47] <pitti> eww
[21:47] <pitti> tjaalton: can we please stop xorg-server from depending on hal?
[21:47] <maxb> LP 375618
[21:47] <pitti> -evdev should/could, but nothing else surely?
[21:47] <pitti> maxb: I thought I re-fixed that some days ago
[21:48] <seb128> pitti, is that required for the fdi which moved there?
[21:48] <maxb> It seems to have re-broken just now in today's xorg/hal update
[21:48] <pitti> seb128: not really
[21:48] <pitti> xorg just needs to ship these two files
[21:49] <pitti> nothing else
[21:49] <seb128> right, the fdi will be used if hal is there and do nothing otherwise
[21:49] <seb128> tjaalton, ^ that blocks the fixed gdm build
[21:49] <seb128> brb
[21:50] <pitti> seb128, tjaalton: want me to upload a new xorg?
[21:51] <pitti> hm, hang on, xserver-xorg has always depended on hal
[21:51] <pitti> at least in jaunty
[21:52] <pitti> so it's just because it's now a build dep?
[21:52] <pitti> anyway, moving to recommends should be fine
[21:53] <cjwatson> xserver-xorg is a bit of an exotic build-dep isn't it?
[21:53] <cjwatson> why is that needed?
[21:53] <pitti> seb128:
[21:53] <pitti> pitti| hm, hang on, xserver-xorg has always depended on hal
[21:53] <pitti> pitti| at least in jaunty
[21:53] <cjwatson> I can understand xvfb or something ...
[21:53] <pitti> pitti| so it's just because it's now a build dep?
[21:54] <pitti> seb128: can we not b-dep on xserver-xorg and just hardcode the new X path?
[21:54] <cjwatson> recommends> doesn't hal give xserver-xorg its ability to accept input?
[21:54] <pitti> xserver-xorg pulls in the entire xorg stack, which is weird
[21:54] <cjwatson> that seems like a bit more than recommends to me
[21:55] <pitti> cjwatson: it should just be -evdev, but let's not turn all of them upside down right now indeed
[21:55] <pitti> so, dropping the xserver-xorg b-dep from gdm seems least intrusive to me
[21:55] <seb128> yeah, I just copied what debian did to fix this issue
[21:56] <seb128> seemed to be the quicker way
[21:56] <seb128> I will have a look to change the configure logic rather now
[21:56] <maxb> Concerning the keyboard setup callout, it seems that the current xorg seems to have copied an old fdi file from before LP 375618 was fixed
[21:57] <pitti> maxb, tjaalton: so perhaps xorg should update the fdi and script to the versions from hal? (http://bazaar.launchpad.net/~ubuntu-core-dev/hal/ubuntu/revision/336)
[22:00] <maxb> I've just rebooted having taken the fdi that was shipped in yesterday's hal, and the bug is fixed again
[22:01] <Sarvatt> sounds like thats what needs to be done
[22:04] <pitti> ok, will upload then
[22:05] <pitti> maxb: ah, you already added an xorg task?
[22:08] <tjaalton> pitti: I'll fix it.. maintained in git etc
[22:08] <pitti> tjaalton: oh, ok
[22:08] <pitti> thanks
[22:09] <maxb> xorg task added, now added explanatory comment
[22:09] <pitti> tjaalton: reassigned to you
[22:09] <tjaalton> ok
[22:10] <tjaalton> oh, it needed all that.. perhaps debian wants that too
[22:10] <pitti> tjaalton: yes, it wouldn't hurt in debian either
[22:10] <pitti> to make it independent from the other fdis
[22:11] <tjaalton> right, I'll push it there too
[22:11] <tjaalton> guess I've seen a similar bug there
[22:11] <pitti> tjaalton: see http://bazaar.launchpad.net/%7Eubuntu-core-dev/hal/ubuntu/revision/326 for rationale (and the same bug)
[22:11] <tjaalton> yeah saw the diff from there
[22:26] <kirkland> bryce: x on my karmic thinkpad looks to be hosed again?
[22:26] <tjaalton> kirkland: just wait for the latest gdm to build
[22:26] <kirkland> tjaalton: awesome, thanks
[22:26] <tjaalton> or change the patchs to X in gdm.conf
[22:27] <tjaalton> paths, even
[22:37] <blistov1> what has happened to ctrl+c in server 9.04 and up?
[22:37] <blistov1> along with ... most of the other ctrl commands?
[22:38] <cjwatson> nothing?
[22:38] <cjwatson> at least not for most people :)
[22:38] <blistov1> sorry, 9.10
[22:38] <cjwatson> there is a known problem with console-setup that means the keymap is a bit busted; if 'sudo setupcon' fixes your problem, then that's what you're running into
[22:39] <infinity> pitti: Are you willing to pretend to be a hal expert for a second?
[22:39] <pitti> infinity: I was, two seconds ago :)
[22:39] <pitti> infinity: what's up?
[22:39] <blistov1> cjwatson: sudo setupcon does not fix it.
[22:39] <infinity> pitti: It's failing to stop "hald-addon-acpi" and purge from chroots.
[22:40] <blistov1> ctrl+c, d, z... none of them work.
[22:40] <blistov1> Every 9.10 install I have.
[22:40] <blistov1> Just noticed :)
[22:40] <infinity> pitti: And, more curiously, running my scan-for-processes script (the same one the buildds use at the end of a build) works fine.
[22:40] <pitti> infinity: it's a miracle that it started in the first place..
[22:40] <infinity> pitti: Does it auto-respawn or something insane when killed?
[22:40] <pitti> infinity: nope
[22:40] <pitti> it just gets started on startup, no d-bus activation for hal
[22:40] <seb128> btw about this hal doesn't start breaks xorg-server install thing
[22:40] <infinity> pitti: Miracles notwithstanding, it's being started on the lpia buildds. :/
[22:40] <pitti> (just yet, it will come in the near future)
[22:41] <seb128> is there really a reason to break xserver-xorg configuration if hal doesn't start?
[22:41] <cjwatson> blistov1: 'stty sane'?
[22:41] <pitti> infinity: what package pulls that in? it shouldn't be a build dep in the first place
[22:41] <blistov1> cjwatson: root@ebackup:~# stty
[22:41] <blistov1> speed 38400 baud; line = 0;
[22:41] <blistov1> -brkint -imaxbel
[22:41] <pitti> infinity: or is that just the 0ubuntu4 gdm?
[22:42] <infinity> pitti: I suspect it's a recommends somewhere.
[22:42] <infinity> pitti: xserver and gdm are both pulling it in as build-deps.
[22:42] <cjwatson> blistov1: I know it works for me (9.10 desktop upgraded from $ancient, but should be no difference) because my baby daughter managed to type ctrl-z on a console earlier tonight ;-)
[22:42] <blistov1> cjwatson: sane does nothing.
[22:42] <pitti> infinity: either way, I hope to mostly get rid of hal in karmic, so I guess we shouldn't waste too much work on little issues like that
[22:42] <infinity> pitti: (And the buildds still do recommends by default because... I haven't turned that off)
[22:42] <pitti> infinity: gdm was fixed in 0ubuntu5
[22:43] <pitti> infinity: oh, does Debian do that? I thought b-deps were depens only
[22:43] <infinity> pitti: Right, well, I don't care much about the underlying bug, I care about it killing the buildds outright when it happens. :)
[22:43] <cjwatson> blistov1: don't know, then, I'm afraid. File a bug and we'll look into it ...
[22:43] <infinity> pitti: build-deps are depends-only, but apt kinda grew the "recommends-by-default" thing, so I need to explicitely turn it off.
[22:43] <blistov1> cjwatson: grrr.
[22:43] <pitti> infinity: if some other package b-deps on hal or xserver-xorg, I'd rather fix just that
[22:43] <infinity> pitti: And, more annoyingly, only for the suites that support the option.
[22:44] <blistov1> cjwatson: well, i'll install a test box using today's daily build. see what happens.
[22:44] <blistov1> i noticed though that the default TERM  is not "linux" instead of "xterm"
[22:45] <blistov1> cjwatson: oh, and its only through ssh.  Logging in on a physical terminal seems to work fine with "linux" term set
[22:46] <tjaalton> seb128: are you suggesting the postinst fails if 'invoke-rc.d hal restart' fails?
[22:47] <seb128> tjaalton, yes
[22:47] <seb128> tjaalton, that what broke the gdm build
[22:48] <superm1> ls
[22:48] <superm1> oops :P
[22:48] <tjaalton> seb128: hrm..
[22:49] <cjwatson> blistov1: I'm not sure I understood your sentence about $TERM. Did you mean to type "now" rather than "not"?
[22:49] <infinity> pitti: Err, wait, you say there's a new gdm source that doesn't build-dep on xserver-xorg?
[22:49] <cjwatson> Ctrl-C works fine over ssh here
[22:49] <pitti> infinity: yes, 0ubuntu5; only 0ubuntu4 did, and it was an error
[22:49] <TheMuso> pitti: We need to package rtkit first.
[22:49] <pitti> TheMuso: OMG, another kit?
[22:49] <tjaalton> seb128: ok, it should be fixed then
[22:49] <seb128> pitti, not really an error but right ;-)
[22:49] <cjwatson> and TERM=screen, as it should be since I'm sshing from inside a screen session. TERM depends on what you're coming from not what you're going to
[22:50] <pitti> okay, s/error/bad move/ :)
[22:50] <cjwatson> having a mis-set TERM would certainly explain terminal features not working properly
[22:50] <seb128> TheMuso, hey, what information would be useful for an "there is no sound being played on karmic" issue?
[22:51] <TheMuso> pitti: Yes, and its a Lennart creation, and it needs kernel 2.6.31 or newer.
[22:51] <cjwatson> blistov1: could be a buggy .bashrc or similar startup script?
[22:51] <TheMuso> seb128: Whether volume is turned up in gnome-volume-control applet or alsamixer, whether there are any card# directories in /proc/asound, and whether there are any /dev/snd device nodes.
[22:52] <seb128> TheMuso, yes for all of those
[22:52] <TheMuso> seb128: Did sound work before? and are you able to run alsamixer in a terminal as an ordinary user?
[22:52] <pitti> seb128: does aplay just play silently, or fail with an error?
[22:53] <seb128> TheMuso, things do play sound in the sense they don't display any error and act as sound was being played but the is no actual sound
[22:53] <seb128> pitti, ^
[22:53] <pitti> TheMuso: FYI, there was a bug in udev which caused auto-ACLs not to apply; that's not seb128's problem, but it hit me, and anyone else who isn't in audio group
[22:53] <seb128> TheMuso, it worked in jaunty, not since I updated to karmic I think
[22:54] <seb128> TheMuso, and yes, I can run alsamixer, the gnome mixer or the new pulse mixer, use aplay and paplay, no error
[22:54] <TheMuso> pitti: Yeah that hit me as well.
[22:54] <seb128> they all act as they were doing their job
[22:54] <TheMuso> seb128: Ok, are either any of master, PCM, or front turned down or muted?
[22:55] <seb128> TheMuso, I've only master and pcm listed and they are not muted and have volume
[22:56] <TheMuso> Hrm. Tried either killing pulse and playing sound, or restarting pulse?
[22:57] <seb128> yes
[22:57] <seb128> no luck
[22:57]  * pitti suggests booting jaunty kernel
[22:57] <seb128> but pulseaudio might just get auto respawned
[22:57] <pitti> chmod 0 usually helps :)
[22:58] <TheMuso> Or creat ~/.pulse/client.conf and put "autospawn = false" into it.
[22:59] <pitti> good night everyone
[22:59] <TheMuso> Youcould try clearing your .pulse* files and restarting pulse.
[22:59] <seb128> pitti, 'night
[23:04] <seb128> TheMuso, not a pulseaudio issue, still no sound with pulseaudio binary moved somewhere else and pulseaudio stopped, I will try what pitti suggested, booting a jaunty linux version
[23:06] <TheMuso> seb128: ok
[23:11] <seb128> TheMuso, ok, 2.6.28 has sound
[23:12] <blistov1> cjwatson: brand new install. haven't touched anything with .bashrc or anything else
[23:13] <blistov1> physical terminal works. ssh does not.
[23:13] <cjwatson> blistov1: ssh *from what*?
[23:14] <cjwatson> that's likely to be really quite relevant
[23:14] <blistov1> from ... gnome-terminal of multiple versions, yakuake (multiple versions), xterm (multiple versions)
[23:15] <blistov1> cjwatson: also, "exit" doesn't actually end the session.  just prints logout, and hangs.
[23:15] <blistov1> something very odd with everything tty related.
[23:15] <cjwatson> and you said TERM=linux on the server side?
[23:16] <cjwatson> what does echo $TERM say if you run it in the same terminal before running ssh?
[23:16] <blistov1> cjwatson: if i log in on a physical console (or rather, vm console), i get TERM=linux by default.  If i login via ssh, i get xterm
[23:16] <cjwatson> that's as it should be, given an xterm-like client
[23:17] <TheMuso> seb128: ok sounds like a kernel regression.
[23:17] <seb128> TheMuso, right, what information would be useful in a bug out of the chipset reference?
[23:18] <cjwatson> blistov1: it's after 11pm here and I'm not really awake enough to work this out. Could you please use 'ssh -vvv' to get a debug log and file a bug with it?
[23:18] <blistov1> Before I ssh to the server, I have xterm set.  When i've ssh'd in to the server, i still have xterm.  If I set TERM=linux before sshing to the server, the TERM stay's "linux", but the problem remains.
[23:18] <blistov1> cjwatson: will do.
[23:18] <cjwatson> TERM is unlikely to be relevant; the values you are describing as being set are correct. Setting TERM to something different will only make things worse.
[23:19] <TheMuso> seb128: Running http://www.alsa-project.org/alsa-info.sh or using ubuntu-bug alsa-base would get what is needed.
[23:19] <seb128> TheMuso, ok thanks
[23:19] <blistov1> cjwatson: you are correct.  TERM seems irrelevant.
[23:19] <blistov1> brb
[23:19] <TheMuso> seb128: I assume the no sound was with 2.6.31?
[23:20] <cjwatson> I doubt it's actually ssh's fault, since it hasn't changed in any relevant way, but it's as good a place as any to start since it appears to be the distinguishing factor at the moment
[23:20] <seb128> TheMuso, no, current karmic, 2.6.30-10
[23:20] <TheMuso> seb128: oh ok.
[23:21] <dupondje> seb128: u have no sound ? errors ? Cause I had no sound some hours ago neither and got it fixed
[23:21] <seb128> dupondje, no, it's different from the udev permission issue
[23:21] <seb128> dupondje, I've no sound since 2.6.30 and it works using 2.6.28
[23:22] <dupondje> oh ok :)
[23:24] <TheMuso> seb128: I wonder whether its worth trying with 2.6.31. Its in the archive, but not been pushed out yet as the next kernel to upgrade to.
[23:24] <seb128> TheMuso, I will do that before opening a bug, thanks
[23:25] <seb128> but for now time to sleep, I will see that tomorrow
[23:25] <TheMuso> Ok good night.
[23:25] <seb128> TheMuso, thanks for helping me to figure what is wrong
[23:25] <TheMuso> seb128: np
[23:36] <TheMuso> c