[19:14] <MichealH> Oh its Silasle :)
[19:15] <MichealH> :))
[21:41] <MichealH> Hi Mad... :(
[21:41] <MichealH> DAMN
[21:41] <MichealH> Wanted to tell him I was trying to make something similat to his mockup
[21:45] <MichealH> It may or May not work using HTML
[21:45] <MichealH> Im thinking XML
[21:45] <MichealH> So the xml is

This is a Category</title>

[21:46] <MichealH> ect.
[22:00]  * phillw waves
[22:01] <phillw> why have you not fully registered the room with Chanserv?
[22:02] <MichealH> Hi, I dunno, ask Omega
[22:02] <MichealH> We all have irssi on servers or ZNC i guess
[22:03] <phillw> if you want an '#' room, having it registered with chanserv is a good idea :)
[22:04] <phillw> how can you tell nhandler was one of my mentors for UBT :P
[22:06] <MichealH> We are registred :P
[22:06] <MichealH> We choose not to have ChanServ here
[22:07] <phillw> having the room guarded against being hi-jacked is a good idea, but it your team who must decide whether you want that protection.
[22:08] <phillw> it's just a simple   /msg ChanServ SET #ubuntu-tour GUARD ON to enable the guard, it's something I do routinely for new channels.
[22:10] <phillw> along with setting the flags for the irc staffers "Flags +votriA were set on *!*@freenode/staff/* in #channel name"
[22:12] <phillw> you may also want to " UbuntuIrcCouncil       +votriA [modified 6 days, 00:26:24 ago]" if you are part of ubuntu.
[22:13] <MichealH> Yeah
[22:13] <MichealH> Just speak with Omega :)
[22:16] <phillw> MichealH: get Omega to give me a ping, you know the channel I live on (#lubuntu-offtopic) Whilst I do not think it is mandatory, it is 'best practice' - as nhandler is a freenode staffer I follow his advice on setting rooms up.
[22:18] <MichealH> I need to go ;)
[23:05] <Omega> What's the problem?
[23:06] <Omega> Everything's cool :>
[23:52]  * jasono is away: I'm busy


[08:43] <mpt> katie, https://wiki.ubuntu.com/AccountPrivileges#Phone
[08:44] <katie> mpt, thanks
[16:14] <tkamppeter> mpt, mhall119, hi
[16:14] <mhall119> hi tkamppeter
[16:15] <tkamppeter> mhall119, did you get my e-mail about print dialog design?
[16:15] <mhall119> tkamppeter: no, would I?  It's not really my area
[16:15] <mhall119> oh wait, from the 19th?
[16:16] <tkamppeter> mhall119, yes.
[16:16] <mhall119> yeah, I got that one
[16:17] <tkamppeter> mhall119, who is in charge of UI design for Ubuntu Touch. Anyone of the people I have sent the mail to? Anyone in this channel?
[16:17] <mpt> tkamppeter, yes I did
[16:17] <mpt> tkamppeter, oreneeshy is
[16:17] <tkamppeter> oreneeshy, hi
[16:17] <mhall119> yeah, oren
[16:17] <mhall119> tkamppeter: I did however notice that it required qt4, will it not work with qt5?
[16:18] <tkamppeter> mhall119, the original author has written it with Qt4, and I have simply gotten it this way.
[16:19] <tkamppeter> mhall119, the original author is willing to continue work on it (he has retired and therefore has more time now), perhaps we can ask him to port it to Qt5.
[16:21] <tkamppeter> oreneeshy, I have sent you an e-mail about a mobile print client design done at OpenPrinting.
[16:26] <tkamppeter> mhall119, WDYT about asking the original author to port his work to Qt5/Touch SDK?
[16:27] <mhall119> tkamppeter: if we're going to use it in Touch they (phablet team) will probably like it to use qt5 like everything else
[16:28] <mhall119> if it had a good separation between front and backend, we could replace the front-end widgets with Ubuntu SDK components
[16:29] <mhall119> while I'm active in here, who's the design lead for the SDK components?
[16:29] <tkamppeter> So the port Qt4 -> Qt5 would be already a good step forward, also taking into account that frontend and backend get well separated.
[16:30] <mhall119> yeah
[16:30] <mhall119> but again, only if we plan on using it, no point in asking him to do work that won't get used
[16:30] <tkamppeter> mhall119, so on which channel do I find the Phablet team?
[16:31] <mhall119> tkamppeter: #ubuntu-touch is the public channel


[00:38] <mup> Issue operator#699 closed: Document remove_path method behaviour and exceptions properly <docs> <small item> <Created by Abuelodelanada> <Closed by benhoyt> <https://github.com/canonical/operator/issues/699>
[00:38] <mup> PR operator#1031 closed: docs: make pebble.Client.remove_path and Container.remove_path docs consistent <docs> <Created by tonyandrewmeyer> <Merged by benhoyt> <https://github.com/canonical/operator/pull/1031>
[03:58] <mup> Issue operator#1037 opened: Simplify testing code that checks the Juju version <harness> <Created by tonyandrewmeyer> <https://github.com/canonical/operator/issues/1037>
[04:13] <mup> PR operator#1038 opened: feat(charm): add RelationMeta.optional <Created by benhoyt> <https://github.com/canonical/operator/pull/1038>
[08:01] <mup> PR operator#1035 closed: Add `Unit.ordinal` <Created by carlcsaposs-canonical> <Closed by benhoyt> <https://github.com/canonical/operator/pull/1035>
[08:29] <mup> Issue operator#532 closed: Ability to detect if the charm is 'trusted'/has elevated permissions <feature> <juju change required> <Created by jnsgruk> <Closed by benhoyt> <https://github.com/canonical/operator/issues/532>
[11:36] <mup> Issue operator#1039 opened: Bump version number <Created by jameinel> <https://github.com/canonical/operator/issues/1039>
[20:18] <mup> Issue operator#1040 opened: See if Relation.app can be non-Optional <small item> <type hints> <Created by benhoyt> <https://github.com/canonical/operator/issues/1040>
[20:50] <mup> Issue operator#799 closed: Optional parameter not saved in RelationMeta class <small item> <blocked> <Created by hemanthnakkina> <Closed by benhoyt> <https://github.com/canonical/operator/issues/799>
[20:50] <mup> PR operator#1038 closed: feat(charm): add RelationMeta.optional <Created by benhoyt> <Merged by benhoyt> <https://github.com/canonical/operator/pull/1038>
[20:55] <mup> PR operator#1036 closed: ci: Pass LIBJUJU_VERSION_SPECIFIER to the mysql-k8s-operator unit tests <bug> <Created by tonyandrewmeyer> <Merged by benhoyt> <https://github.com/canonical/operator/pull/1036>
[22:54] <mup> PR operator#1041 opened: Expose juju-reboot [--now] <feature> <Created by tonyandrewmeyer> <https://github.com/canonical/operator/pull/1041>


[00:00] <cjwatson> RIGHT
[00:00] <slangasek> mathiaz: hmmm where can I read about looms?
[00:00] <cjwatson> oh, heh, I think I was 18 seconds late with the kickseed sync
[00:00]  * cjwatson blames his local clock
[00:01] <TheMuso> lol'
[00:01] <cjwatson> ... which has yet to hit midnight
[00:01] <slangasek> let's blame Keybuk
[00:02] <soren> hahah!
[00:04] <mathiaz> slangasek: http://www.flamingspork.com/blog/2008/02/22/bzr-loom-a-bzr-plugin-with-quilt-like-functionality/
[00:04] <mathiaz> slangasek: https://edge.launchpad.net/bzr-loom/
[00:04] <mathiaz> slangasek: looms is quilt for bzr
[00:07] <slangasek> yes, I gathered that, I was interested in getting ahold of the details :-)
[00:09] <PhillipA> hello, does anyone have blender and NetworkManager running on their ubuntu so I can confirm a bug? thanks
[00:09] <PhillipA> non-ati video card preferred
[00:10] <soren> Who can change build priorities?
[00:11] <directhex> soren, an archive admin!
[00:11] <Laney> buildd admin, rather
[00:12] <soren> Thinking about it some more, I'm not sure it'll make any difference.
[00:12] <Laney> https://launchpad.net/~launchpad-buildd-admins/+members
[00:17] <savvas> hm... mount command's manpage should be updated for -t ext4 type
[00:31] <slangasek> mathiaz: ah, hrm, if you're going to fire off all the patches in a batch, bug reports would probably be better
[00:31] <calc> update manager autolaunch, ugh, now i just need to go uninstall it entirely since apparently the notification icon wasn't annoying enough already
[00:34]  * calc had thought he had somehow hit the button by accident until he read the bug report that this is a new "feature"
[00:40] <directhex> calc, how about xpsp2-style "your pc will reboot in 15 mins for an update"? :)
[00:40] <calc> directhex: heh that will be when everyone switches to fedora
[00:40] <calc> directhex: that is one of the reasons I refuse to use XP for anything more than bug testing
[00:41] <calc> though there is a way to disable it, that is well hidden, it is the most evil pos
[00:41] <calc> the idea about getting a stock gnome setup though may have more users than originally intended depending on how far these feature changes go
[00:42] <calc> iirc it was thought it would only be wanted by gnome devs
[00:43]  * calc just used gconf-editor and disabled the autolaunch
[00:43] <StevenK> calc: At least the update icon is unobtrusive
[00:44] <calc> StevenK: yea the new feature is that update notifier runs on your desktop every 2 days
[00:44] <StevenK> Eek
[00:44] <calc> so really intrusive
[00:44] <StevenK> Bad
[00:44] <calc> yea
[00:44] <calc> bug 331054, its considered a new 'feature'
[00:45]  * calc hopes the DX team doesn't manage to run off all the Ubuntu users
[00:46] <calc> it won't take too much to reach windows annoyance level which will drive users elsewhere
[00:46] <TheMuso> That is a shocking feature.
[00:46] <calc> at least the users who don't know how to fix it on their machines, anyway
[00:46] <TheMuso> That will get users in more trouble than it will help them IMO
[00:46] <TheMuso> I won't want to have to keep turning that off when I create a fres install/user.
[00:47] <TheMuso> fresh
[00:48] <calc> TheMuso: feel free to bring it up on one of the mailing lists for discussion, apparently it was closed as invalid, since they want it to work that way
[00:48] <TheMuso> Hrm.
[00:48] <calc> though it looks like this might be a feature request from sabdfl after looking at the bug report :-\
[00:51]  * TheMuso sighs.
[00:51] <StevenK> The bug did say auto-updating isn't going to be the default ...
[00:51] <calc> StevenK: auto updating isn't default, but popping up to show you need to update will be
[00:52] <StevenK> Ah
[00:52]  * StevenK grumbles
[00:52] <calc> so every 2 days you get this dumb thing launched
[00:52] <calc> which i don't even use, i only don't remove it since it is depended on by ubuntu-desktop
[00:53] <slangasek> does it launch every two days, or only when there are pending updates?
[00:54] <calc> every 2 days with pending updates, so for people tracking development releases, every 2 days :)
[00:55] <calc> regardless popping up a large app window is pretty annoying
[00:55] <calc> i guess they considered the app icon showing up wasn't sufficient annoying so they wanted to make it worse
[00:56] <calc> iirc it shows up red or something like that when you need to update
[00:57]  * TheMuso will have to test it, and if it behaves badly with accessibility, will have to turn it off for accessibility use cases.
[00:57] <calc> things popping up the user didn't explicitly ask for isn't particularly good ui design (imho), it causes confusion
[00:57] <TheMuso> on the live CD/installs etc.
[01:27] <StevenK> slangasek: FF is, or is not in effect yet?
[01:28] <slangasek> is
[01:28] <StevenK> Damn
[01:28] <StevenK> So I need FFe's for all of the stuff I just cleared out of NEW?
[01:32] <FrankT-Qc> Hi ! There's been an important security update in vsftpd and I was wondering to whom should I raise a flag so that it makes it to the repos as fast as possible ??? Any Idea ?
[01:32] <StevenK> slangasek: Just worried that I should be processing NEW and syncs differently
[01:37] <ScottK> StevenK: From a motu-release perspective we have considered stuff that got uploaded prior to FF as OK even if it got processed out of new later.
[01:38] <StevenK> Right, so NEW is okay, but syncs need closer checking
[01:39] <ScottK> Even there I'd say if they were ack'ed and approved, pre-FF it's OK.
[01:39] <ScottK> Unless someone is starting a new ghc6 transition or something
[01:39] <ScottK> Someone actually asked about updating ghc6 today.
[01:39] <ScottK> We all said NO.
[01:40] <StevenK> I've only done binary NEW, so ...
[01:47] <savvas> FrankT-Qc: you could try #ubuntu-hardened - other than that, I don't know :) you could also file a bug report and check the box below the report to make it a "security risk" (or something like that) at http://bugs.launchpad.net/ubuntu/+filebug
[01:49] <FrankT-Qc> savvas : thanks
[01:50] <ScottK> slangasek: If we're past FF, then I think a "Hey, stop now" mail would be in order.  I havene't seen one yet.
[01:50] <StevenK> Indeed
[01:50] <slangasek> ScottK: will send it out in a couple of hours, unless you want to beat me to it
[01:51]  * ScottK has to deal with kids for a few more hours, so probably not.
[01:52] <ScottK> The good news is that means I don't have to stay up late tonight to finish something.  I can give myself an FFe on the weekend as easily as today.
[01:52] <slangasek> :-)
[01:53] <ScottK> slangasek: I changed /topic in #ubuntu-motu.  It's a start.
[01:54] <StevenK> $topic =~ s/open/FF (ish)/;  # ?
[02:27] <ScottK> jcastro: Just read your blog on the tool for opening upstream tasks.
[02:27] <ScottK> I guess I don't understand what good a blank upstream task does?
[02:31] <calc> ScottK: well it would make it clear the bug is an upstream issue versus something that needs fixing just in ubuntu
[02:31] <maxb> I'm rather getting the impression that the new notifier stuff was landed to get in before FF, not because it was ready :-(
[02:31] <ScottK> maxb: You sound suprised.
[02:32] <maxb> not surprised :-)
[02:32] <ScottK> calc: I guess, it just seems like a lot of effort for little gain unless you are actually going to report the bug upstream and then link it.
[02:32]  * maxb goes on bug-filing spree
[02:32] <jcastro> ScottK: unfortunately the talk I gave at UDS wasn't recorded but basically, people who triage do a good job at linking once they find that it's an upstream bug
[02:33] <jcastro> ScottK: so the idea is to get developers opening more open tasks so that triagers can link them
[02:33] <ScottK> jcastro: I see.  I guess that makes sense.
[02:33] <ScottK> Kind of.
[02:34] <jcastro> basically, if developers can grow the pile of possible bugs, it's relatively easy to grind through them and open the bugs upstream
[02:34] <ScottK> I see.
[02:34] <ScottK> I thought the theory of Triaged was the was when it was ready for developer attention.
[02:35] <ScottK> Now I'm confused again.
[02:35] <jcastro> it only looks at triaged bugs
[02:35] <ScottK> OK.
[02:36] <ScottK> I'm caught in a mental catch 22 in that I don't know how you can mark it triaged and not know it needs upstreaming, but I never understand this stuff.
[02:36] <calc> cool new 5-a-day group :)
[02:37] <jcastro> ScottK: ok, so when you are looking at a bug and you know it's upstream, you can mark it as such, and then someone like me will go through the annoying (but relatively easier) task of filing it upstream.
[02:38] <calc> jcastro: how are the stats tracked with the new group?
[02:38] <ScottK> I see.
[02:38] <jcastro> that way you do what you do best, and the triagers can do what they do best
[02:38] <ScottK> I guess that makes sense.
[02:38] <ScottK> jcastro: OK.  Thanks.
[02:38] <jcastro> that's the /idea/ anyway
[02:39]  * ScottK just wishes he see more triagers doing more than "-> Incomplete, can you still reproduce this in Jauntu".
[02:39] <cjwatson> amen
[02:40] <ScottK> I'd even much prefer "I tried to reproduce this and couldn't, how did you do it and can you still"
[02:40] <lifeless> absolutely
[02:41] <lifeless> I just put my bugs back to what they should be when folk do that to me
[02:41] <lifeless> usually with a snarky comment
[02:41] <lifeless> :(
[02:41] <NCommander> does anyone know why gcj-4.3 on HPPA seems to be MIA?
[02:41] <NCommander> LP says it built
[02:41] <NCommander> the binaries seem to have vanished into thin air ...
[02:42] <ScottK> Yes.  Me too, although I'd describe my reponse is these cases more as 'pointed'
[02:42] <Amaranth> The bug team doesn't test the bugs, they just look at the ones that are Incomplete for more than a month
[02:42] <ScottK> We could script that.
[02:42] <Amaranth> ScottK: It is scripted, the Launchpad Janitor
[02:43] <ScottK> Amaranth: That's for after they're incomplete.
[02:43] <Amaranth> I guess I missed half the conversation
[02:43] <Amaranth> Do you mean the "Does this still happen in jaunty?" ones?
[02:43] <ScottK> Yeah.
[02:43] <ScottK> It
[02:44] <ScottK> It's a new bug and the first comment is can you reproduce it and set it to incomplete.
[02:45] <ScottK> We could trivially replicate this by setting all bugs to incomplete at the last alpha and then marking them invalid if no one complains by release.
[02:45] <ScottK> I don't think this would be a good policy, but it would give us most of the same effect.
[02:49] <calc> as long as all doesn't include triaged bugs ;-)
[02:49] <cjwatson> it would give us most of the same effect and it would suck even more completely. :-)
[02:50] <calc> heh
[02:50] <NCommander> +1 cjwatson
[02:53] <NCommander> cjwatson: quick question, how often are the ports alternate CDs being built? Each milestone, or more often?
[02:53] <ScottK> cjwatson: I'm definitely not arguing in favor of it, just trying to point out how mechanical the current 'triage' effort it.
[02:54] <cjwatson> ScottK: oh, I know
[02:54] <cjwatson> NCommander: daily
[02:54] <NCommander> Oh
[02:54]  * NCommander is lagging
[02:54] <NCommander> I thought today was the 20th ...
[02:54] <NCommander> And the last build was yesterday
[02:54] <NCommander> :-)
[02:55]  * NCommander is actually trying to make our ports be shiny this release
[03:03] <ScottK> \o/ boost1.35 fixed on sparc.
[03:03] <ScottK> Speaking of ports.
[03:03] <NCommander> ?
[03:03] <ScottK> Akonadi built.
[03:04] <NCommander> Score!
[03:04] <cjwatson> speaking of sparc, can somebody fix its asm/byteorder.h?
[03:04] <cjwatson> http://launchpadlibrarian.net/22607976/buildlog_ubuntu-jaunty-sparc.glibc_2.9-0ubuntu10_FAILEDTOBUILD.txt.gz
[03:04] <NCommander> cjwatson, testbuilding the fix now
[03:04] <cjwatson> ah good
[03:04] <NCommander> (I have to build a kernel, then the fixed glibc)
[03:04] <cjwatson> I have a potential glibc change pending for the not too distant future anyway
[03:04] <cjwatson> so maybe we can do those in one upload rather than separately
[03:04] <NCommander> cjwatson, powerpc and sparc are looking quite good for this release, and if I can get an itantic, it will look good with ARM :_)
[03:04] <cjwatson> I need to get it tested from my PPA though, so tomorrow
[03:05] <NCommander> cjwatson, test what to where?
[03:06] <cjwatson> potential fix for bug 313218
[03:06] <cjwatson> it's in 'deb http://ppa.launchpad.net/cjwatson/ppa/ubuntu jaunty main' if anyone wants to try it before I do and potentially hose their system ;-)
[03:07] <NCommander> Actually, I can test this
[03:07]  * NCommander has an IPv6 network ... or did
[03:07] <cjwatson> that's one of the components of the test
[03:07] <cjwatson> I have an IPv6 network too
[03:07] <NCommander> I haven't reset up the router since I replaced it
[03:07] <cjwatson> also needs testing from the folks actually afflicted by the bug, though, which is rather more those people who have broken IPv6 connectivity
[03:07] <NCommander> oh
[03:08] <NCommander> What did you change?
[03:08] <cjwatson> pulled in a Fedora patch to disable gethostbyname4 for the time being
[03:08] <NCommander> O_o?
[03:08] <NCommander> That sounds like a necessary bit of code ...
[03:08] <cjwatson> it's from Jakub Jelinek who knows what he is doing wrt glibc.
[03:09] <NCommander> Well, if my point just didn't burn and crash
[03:09] <cjwatson> if gethostbyname4 isn't there it'll use gethostbyname3 - glibc tends to support older interfaces of things
[03:09] <NCommander> glibc's source code scares me
[03:09] <NCommander> I feel like its going to come and get me in the middle of the night and rip off my head
[03:09] <cjwatson> speaking of middle of the night ...
[03:10] <NCommander> cjwatson, I was about ot say it was kinda late your time.
[03:11] <calc> i noticed we were switching to boost 1.35 but 1.37 is also in the archive, should packages migrate to that instead?
[03:13] <ScottK> calc: We all need to use the same one.
[03:13] <ScottK> Please let's not start another switch right now.
[03:14] <ScottK> That and I just got 1.35 patched to work on sparc.
[03:14] <NCommander> cjwatson, do you know about anything on java on HPPA?
[03:15] <ScottK> NCommander: I don't think such a thing exists.
[03:15] <NCommander> :-/
[03:15] <ScottK> IIRC that's what lamont told me.
[03:17]  * ScottK goes back to trying to understand what the heck he was thinking when we wrote this beautiful code 9 months ago.
[03:18]  * NCommander watches ScottK's brain liquidify
[03:19] <ScottK> It really was a lovely way to solve the problem I was having at the time.
[03:19] <ScottK> It may, however, turn out to be just one increment short of extensible enough.
[03:21] <NCommander> ScottK, looks like kdebindings on HPPA is fixed
[03:21] <ScottK> \o/
[03:21] <NCommander> Its nice to have that fixed.
[03:21] <ScottK> Yep.  I don't think that's ever built.
[03:21]  * NCommander is officially the KDE port gurur ;-)
[03:21] <NCommander> *guru
[03:21] <NCommander> It did in the 3.x series
[03:21] <ScottK> No mono bindings in KDE3.
[03:22] <NCommander> yay
[03:22] <ScottK> We could have solved KDE4 easily enough be not shipping them.
[03:22] <NCommander> I'm kinda suprised mono is disabled on HPPA
[03:22] <NCommander> It seems to be supported
[03:22] <ajmitch> it probably wasn't supported back in the distant past
[03:23] <NCommander> maybe its worth seeing if we can kick the mono lines from PAS
[03:23]  * ScottK knows just that he wants the fricking package to build.
[03:23] <NCommander> Well, either way ...
[03:24] <ScottK> NCommander: Let's get pimlibs built on sparc before another upload first, so it'll have a chance there too.
[03:24] <ScottK> That just needs a publisher run followed by a rescore.
[03:25] <NCommander> stupid question: is porting a feature to a new architecture (i.e., fixing mono on HPPA) affected by feature freeze?
[03:26] <ScottK> NCommander: Was the lack of Mono a design decision or a bug?
[03:26] <NCommander> I think the HPPA porting group just never realized mono was ported
[03:26] <Amaranth> who has HPPA hardware?
[03:26] <NCommander> Physical, or access to one?
[03:26] <NCommander> Amaranth, lamont :-)
[03:27] <Amaranth> NCommander: He runs a KDE desktop on there? :)
[03:28] <NCommander> dunno
[03:28] <NCommander> Its a sticking point with me tha tKDE been broken on HPPA
[03:28] <NCommander> (actually, just having a hosed port is :-P)
[04:09] <TheMuso> cjwatson: I have managed to get the ia64 kernel down to 10MB, which will appear to just fit inside boot.img. I can't go any smaller without sacrificing functionality. A lot of stuff was disabled and/or built in for the last kernel as it was.
[04:11] <TheMuso> NCommander: so you made the fix to glibc? I thought the fix had to be done in the kernel.
[04:14] <NCommander> TheMuso, no, I made it to the kernel
[04:14] <TheMuso> NCommander: ah ok
[04:15] <NCommander> TheMuso, ah, the sparc kernel just finished
[04:15] <NCommander> (like five seconds ago :-)
[04:15] <TheMuso> timing
[04:15] <NCommander> But ...
[04:15] <NCommander> I built the wrong kernel
[04:15] <NCommander> wait
[04:15] <NCommander> Hold on
[04:16]  * NCommander is an idiot ...
[04:17] <lamont> NCommander: java/hppa vs doko is a long standing frustration of his.
[04:18] <NCommander> lamont, I take it is a chicken and the egg problem because to bootstrap OpenJDK, you need a JDK already in place, right?
[04:20] <lamont> NCommander: doko was at least smashing his head against openjdk/hppa, iirc.  until he got tired of the threads/kernel/libc/whatever-the-hell-it-really-is bug
[04:20] <NCommander> lamont, which seems to have gone away-ish
[04:20] <lamont> the one that has me rapidly approaching the point where I craft the email to ubuntu-devel-announce announcing the retirement of the hppa port from ubuntu
[04:21] <lamont> ish being the operative word
[04:21] <lamont> mostly, we just don't giveback things that we know kill it
[04:21] <NCommander> lamont, well, I haven't experienced the fun it caused with Ruby
[04:21] <lamont> because, well, it hurts when we do that
[04:21] <lamont> NCommander: coolness
[04:21]  * NCommander was one of the people who helped debug ruby on HPPA
[04:21] <NCommander> I'd like to drop jaunty's kernel on the porting box and see if it works.
[04:21] <NCommander> ^- better.
[04:22] <NCommander> (and then run glibc's test suite to see what our breakage level is at)
[04:23] <lamont> NCommander: here's a test for you:  pick anything amusingly interesting from _DAPPER_ and build it in a dapper+security chroot on that jaunty kernel - needs to work
[04:23] <lamont> at least until jun 2011
[04:23] <NCommander> I don't have a HPPA box I can install kernels on
[04:23]  * NCommander has root at an HPPA box at HP, but thats on the other side of the US for me ...
[04:25] <NCommander> *sighs*
[04:25]  * NCommander grabs a handbook on SPARC ASM
[04:27] <NCommander> lamont, is there a HPPA virtualization solution? (I've been trying to find an actual HPPA box for some time, but they're damn pricy, even used :-/)
[04:28] <lamont> no solution that I know of
[04:28] <NCommander> know where I can get a cheap box?
[04:29]  * lamont was part of an investigation into virtualizing hppa in about 1992ish, that determined that it would certainly require guest knowledge in lots of places, and then we dropped that
[04:30] <NCommander> ok, sparc should be fixed soonish
[04:31]  * NCommander grumbles and backports more fixes
[04:32] <NCommander> lamont, side issue, do you have access to the HPPA build chroots? They're misconfigured to disallow installing unsigned packages. I had a fun build failure in a devirtualized PPA due to that :-/
[04:39] <lamont> I'm gonna go with "no" to that, even though rules-lawyers might disagree
[04:39] <NCommander> lamont, rules-lawyers?
[04:40] <lamont> NCommander: I have root on just about every machine in the data center.  and the others I have console on.
[04:40] <NCommander> oh, I see
[04:41] <lamont> mostly, I'm just tired enough to not want to even understand the issue, let alone fix it.
[04:41] <lamont> which reminds me... I need to deal with the debian release on the debian/hppa buildd machines
[04:43] <NCommander> lamont, this leads me to my next question on why HPPA is so bleck :-/. I do remember when it was a fairly loved architecture in Debian (before NPTL ...)
[04:43] <lamont> and there you go answering your own wquestion
[04:43] <NCommander> Oh
[04:43] <NCommander> I'm just suprised HP hasn't sponsored work on it
[04:44]  * lamont goes back to the pain that he knows, with:  apt-get remove --purge libvirt-bin
[04:45] <NCommander> ouch
[04:45]  * NCommander just wish PA-RISC boxs didn't command such a high price on ebay
[04:48] <calc> hppa didn't even get bootstrapped until late 2000 iirc
[04:48] <Cxoliac> join #fedora
[04:49] <NCommander> Well, HP seems to be fairly bipolar on it; I see them moving to IA-64, and yet HPPA is quite common from what I see on their server offerings
[04:50] <calc> NCommander: iirc ia64 was supposed to be the replacement... except that ia64 wasn't that great (aiui) once it actually came out
[04:50] <NCommander> Well, ia64's are fairly cheap if your not too picky
[04:50] <NCommander> Someone told me at UDS that the ia64's in the data center were ebay specials ...
[04:52] <calc> NCommander: probably cheap because they aren't very useful, heh
[04:53] <NCommander> well, I can find plenty of SPARCStation 20's for less than 200 bucks. Might just snag one for installation testing
[04:57] <lamont> sparcstation 20 won't run ubuntu, iircf
[04:57] <NCommander> bah
[04:58] <NCommander> So HP-UX supports Java, so pa-risc support is there
[04:58]  * NCommander takes a look to see if the code to support it is there ...
[05:25] <rootard> hi all, quick q on building packages. What mechanism generates the .changes file once all of the .debs and sources are placed into the parent directory of the source?
[05:26] <rootard> oh, nm. I need caffeine
[05:33] <ScottK> It looks like at least libgpod-nogtk-dev and possible other binaries from libgpod have fallen into Universe for some archs (e.g. for i386, but no am64).  I was wondering it an archive admin is around who would clean that up?
[05:40] <dholbach> good morning
[05:43] <dholbach> bryce: wow... my gdm is in explosion loop of death and I can only click "OK"
[05:51] <dholbach> does anybody of you have something like this in your gdm log?
[05:51] <dholbach> error setting MTRR (base = 0xe0000000, size = 0x08000000, type = 1) Invalid argument (22)
[05:51] <dholbach>  ddxSigGiveUp: Closing log
[05:52] <dholbach> I believe gdm when it tells me that the xkbcomp problems are not fatal
[05:52] <dholbach> > Warning:          Type "ONE_LEVEL" has 1 levels, but <RALT> has 2 symbols
[05:52] <dholbach> >                   Ignoring extra symbols
[05:54] <slangasek> "error setting MTRR" - that's a hardware matter
[05:54] <slangasek> definitely no such error in my logs
[05:55] <dholbach> I dist-upgaded and restarted - that's what it looks like now (on my nv amd64)
[05:55] <dholbach> my i386 laptop works fine
[05:55] <dholbach> and on the amd64 I can't switch to the consoles now
[05:55] <dholbach> which sucks
[05:56] <superm1> slangasek, can you retry the livefs build for ubuntu dvd?  yesterdays didn't come out, and we were counting on some fix(es) in it.
[06:02] <dholbach> https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/331292
[06:02] <slangasek> superm1: yep, running
[06:02] <dholbach> I guess that's my issue
[06:03] <dholbach> what happened to bulletproof X?
[06:03] <dholbach> :-(((
[06:04] <dholbach> hum, maybe it's not
[06:04] <dholbach> I wasn't using nvidia
[06:05] <jdong> heh with my video chipsets whenever X really fails it tends to lock everything with it...
[06:05] <jdong> I once had a mismatch between the kernel blob and userland that triggered hardlocks...
[06:08] <dholbach> what about http://people.ubuntu.com/~dholbach/new-nm-dialogue.png - do we really mean to have that dialogue?
[06:09] <dholbach> and why does gnome-terminal crash on me?
[06:09] <dholbach> today is not going to be my day, I just know it
[06:11] <jdong> oh it is definitely one of those weeks where just about everything goes wrong :)
[06:11] <jdong> to pile up on my fun stuff this week I lost both of my Firefox profiles... on the same day... independent systems same bug :)
[06:13] <dholbach> ok... xdm instead of gdm works
[06:16] <Amaranth> dholbach: Apps that try to use notification-daemon with buttons get an error that they think means notification-daemon isn't running and fall back to showing a dialog
[06:16] <Amaranth> I like how the "You are now running on battery power" dialog has a Cancel button
[06:17] <Amaranth> Maybe if I click it the computer will automatically attach the power cord again
[06:17] <dholbach> I'm not sure those dialogues help with anything
[06:17] <Amaranth> They don't, it's something no one ever actually saw before because notifications always worked
[06:18] <calc> dholbach: does 5-a-day-stats get automatically updated by just joining the group now?
[06:19] <johanbr> Amaranth: That's apparently supposed to act as a reminder to patch those applications.
[06:19] <dholbach> calc: that's the plan - I still have to do some work to do for that
[06:19] <calc> dholbach: ok
[06:19] <dholbach> calc: now that I can log in to GNOME again, I'm one step closer to doing it :)
[06:19] <calc> dholbach: heh :)
[06:20] <dholbach> ok, it's bug 331324
[06:22] <slytherin> Can any of the archive admins please rescore libdvdread on ia64, hppa and armel? It is stuck at score 3255 for more than 30 hours.
[06:25] <Mithrandir> slytherin: no.  Done.
[06:25] <Mithrandir> (you need a buildd admin, not an archive admin)
[06:28] <slytherin> Mithrandir: thanks
[06:28] <ScottK> slytherin: There is a bit of a line tonight.
[06:32] <Mithrandir> ScottK: though, if people are actively waiting for something to build, I'm happy to rescore it so they don't get blocked.
[06:33] <ScottK> Mithrandir: Sure, I just mentioned it in there interests of 'nothing's wronge except everyone uploading tons the day before FF.'
[06:33] <Mithrandir> oh, sure.
[07:13] <slangasek> superm1: still fails to build; langpack conflicts
[07:13] <slangasek> looks like it's because of the long build queues
[07:40] <stefanlsd> Does anyone know if mom data is available in xml or csv or somthing?
[08:09] <pitti> Good morning
[08:09] <ion_> Hi
[08:12] <Koon> Good morning pitti
[08:14] <scizzo-> morning
[08:14] <primes2h> pitti: Good morning.
[08:16] <dholbach> pitti: do you know why bug 330621 was not retraced yet?
[08:21] <PecisDarbs> pitti: good morning, can I talk with you for a minute? :)
[08:48] <pitti> Meh, X froze again while I was showering
[08:48] <pitti> PecisDarbs: pong
[08:49] <pitti> dholbach: when was it filed?
[08:50] <dholbach> pitti: nm, saw your conversation with seb128 about the retracer
[08:50] <pitti> dholbach: "my conversation"?
[08:50] <pitti> it might be stuck again, but I didn't get a warning mail
[08:50]  * pitti checks
[08:52] <pitti> dholbach: oh, was it amd64? the retracer got stuck apparently
[08:52]  * pitti restarts it
[08:52] <pitti> seb128: ^ FYI
[08:52] <seb128> pitti: cf #distro
[08:52] <seb128> pitti: stop ignoring me there dude ;-)
[08:52] <pitti> seb128: didn't see anything
[08:52] <beuno> pitti, mine is freezing as well (we seem to share a lot of hardware!). I also have to log in twice to gdm. Is that a known issue?
[08:53] <pitti> beuno: happens to me, sometimes, a few minutes after suspend from hibernate; otherwise it's behaving
[08:54] <beuno> pitti, it has happened to me twice in the past few days, but not related to hibernating or suspending, unfortunetly
[08:56] <pitti> beuno: can you still ssh in?
[08:56] <pitti> beuno: I can, and I tried stracing X, and got a busy loop with
[08:56] <pitti> --- SIGALRM (Alarm clock) @ 0 (0) ---
[08:56] <pitti> sigreturn()                             = ? (mask now [])
[08:56] <pitti> ioctl(11, 0x40046445, 0xbfb8e4a4)       = -1 EINTR (Interrupted system call)
[08:57] <beuno> pitti, ah, I haven't tried. Will do next time.
[09:00] <\sh> soren: you have main powers, right? would you like to review bug #331410 (jaunty debdiff) for net-snmp
[09:01] <pitti> beuno: me too, I'll check if it's the same next time
[09:01] <pitti> beuno: oh, and I just tried stracing X in X; don't do that...
[09:01] <pitti> gives a nice lockup :)
[09:02] <beuno> hahah
[09:02] <ion_> :-D
[09:03] <pitti> ssh'ing in and kill -9'ing strace recovers, though
[09:03] <beuno> pitti, other than those two things, Jaunty seems much more solid than Intrepid
[09:03] <pitti> tseliot: btw, did GNOME stop respecting .config/monitors.xml a week ago (or so) as well?
[09:04] <pitti> tseliot: that's pretty nasty, I always have to start the session with reconfiguring screens, compiz --replace, killall gnome-panel..
[09:04] <pitti> beuno: what hardware do you have?
[09:04]  * pitti -> back in 5
[09:04] <tseliot> pitti: no, did you file a bug report about it?
[09:05] <beuno> pitti, dell xps1330 with GM965 and 3945ABG
[09:08] <tseliot> pitti: if you do, I'll be happy to fix that
[09:15] <pitti> tseliot: yes, I did, let me find it
[09:16] <pitti> tseliot: bug 329410
[09:16] <pitti> tseliot: .config/monitors.xml didn't change AFAICS (did it?), so it seems that gnome-settings-daemon or whatever else is responsible for reading and acting on it doesn't work any more?
[09:18] <tseliot> pitti: no but there can be different (temporay) configuration files. I'll try to reproduce the problem here and I'll fix it
[09:21] <pitti> tseliot: it just seemed to coincide with the new-style capplet (separate on/off, and so on)
[09:21] <pitti> might be pure coincidence, though
[09:21] <pitti> tseliot: is g-settings-daemon the piece that should read it?
[09:22] <tseliot> pitti: yes, through libgnome-desktop.
[09:22] <pitti> ah
[09:22] <pitti> tseliot: so maybe something was ported to drop libgnome?
[09:22] <tseliot> pitti: I've done some serious work on it therefore I should be able to figure out where the problem lies
[09:22] <pitti>   * debian/control.in:
[09:22] <pitti>      - the new version doesn't require libesd, libpulse, libgnomeui
[09:22] <pitti> gnome-settings-daemon (2.25.2-0ubuntu1) jaunty; urgency=low
[09:23] <tseliot> I doubt they can be the cause of the problem
[09:23] <pitti> ah, no, that's too  old
[09:23] <pitti> it just stopped working a week ago or so
[09:24] <tseliot> I have some suspects ;)
[09:43] <pitti> ArneGoetje: hardy/intrepid-proposed langpacks accepted
[09:51] <cjwatson> NCommander: java/hppa> absolutely no idea
[09:52] <cjwatson> TheMuso: ia64 kernel> thanks, sounds good
[09:59] <PecisDarbs> pitti: did a changes in sl-modem-daemon.init patch you suggested, a little bit optimized all alsaload along the way. Patch attached to bug report.
[09:59] <pitti> PecisDarbs: great, thanks
[10:00] <majeru> hello, i'd like to propose some enhancements to the display manager applet, is there anyone that is in charge with it?
[10:01] <pitti> anyone on current KDE? can you tell me where Konqueror stores its cookie file/database?
[10:02] <pitti> majeru: display manager applet? you mean the fast user switcher in the panel, with your name and status?
[10:02] <majeru> no, i mean that one that may change the screen resolution
[10:02] <pitti> majeru: tseliot primarily
[10:02] <majeru> ok, thanks
[10:03] <tseliot> majeru: what's the problem?
[10:05] <majeru> there's no problem, i have some usability proposals
[10:06] <majeru> mostly for those people with multiple display setups
[10:06] <majeru> like having profiles accessible from the notification menu
[10:07] <majeru> and sub-menus for each display's resoluton
[10:07] <tseliot> majeru: can you file a bug about it and send me a link to it, please? I'll have a look at it later
[10:07] <majeru> okay, thanks
[10:08] <ogra> tseliot, oh, while you're at discussing the screen applet, do you know about https://blueprints.launchpad.net/ubuntu/+spec/mid-screen-rotation ?
[10:08] <pitti> Riddell: can you tell me where Konqueror stores its cookie file/database?
[10:09] <ogra> tseliot, would be nice to have a version for MID with all capabilities cut out of the applet apart from teh rotation settings, that way we could use it in MID
[10:10] <tseliot> ogra: it can be done by reusing libgnome-desktop or doing it from scratch
[10:11] <ogra> tseliot, well, thats what i wanted to avoid :)
[10:11] <ogra> youse seems perfect for the task, it just has to many options
[10:11] <ogra> *yours
[10:12] <tseliot> ogra: which one?
[10:12] <ogra> the little display i can add to the systray
[10:13] <ogra> MID uses a systray and the menu apart from the "open display settings" button is prefectly what we are looking for
[10:14] <ogra> either bryce to tjaalton told me that you wrote that
[10:15] <tseliot> I worked on it but that depends on libgnome-desktop though. It's part of gnome-control-center
[10:15] <ogra> oh, even the applet ?
[10:15] <tseliot> yes
[10:16] <ogra> ah, k, i guess then i'll just steal your code and adapt it in 9.10
[10:16] <tseliot> ok ;)
[10:16] <ogra> i doubt we want libgnome-desktop or gnome-control-centerin MID
[10:16]  * ogra needs to reboot after upgrade ... bbs
[10:16] <tseliot> it shouldn't be difficult to write something from scratch
[10:17] <ogra> yeah, i grokked that, but its usually even easier to write a patch that just compiles code again with a different configure option to disable features :)
[10:17] <ogra> pitti, is it normal that i dont get a reboot notification icon anymore ?
[10:18] <ogra> i had the popup message telling me i need to restart after the upgrade ...
[10:18] <pitti> ogra: I'm not sure, ask mvo?
[10:18] <ogra> mvo, ^^^
[10:18] <ogra> but no icon in systray
[10:18] <mvo> ogra: yes, its all part of the new design
[10:18] <mvo> https://wiki.ubuntu.com/NotificationDesignGuidelines
[10:19] <ogra> hrm, so i dont have a way to postpone the reboot and still have a reminder
[10:19] <ogra> thats a bit odd
[10:20] <soren> Is there a way to see the the build queue? I mean the specific order in which stuff in "Needs building" is going to get built?
[10:20] <persia> soren, I believe it is https://launchpad.net/ubuntu/jaunty/+builds
[10:21] <soren> persia: I was expecting a link that didn't have "jaunty" in it.
[10:21] <Riddell> pitti: .kde/share/apps/kcookiejar/cookies
[10:21] <soren> -proposed and -backports and all that jazz is in the same queue, is it not?
[10:21] <Riddell> sorry for the delay there
[10:21] <pitti> Riddell: that's a file?
[10:21] <Riddell> pitti: yes
[10:21] <pitti> Riddell: thanks a lot
[10:22] <persia> soren, As I understand it, they are different queues, and the queues are processed on the same buildds in a specific order.
[10:23] <persia> Hrm.  https://launchpad.net/ubuntu/+builds seems to also work, but I believe it misses -security stuff (which also uses the same buildds).
[10:23] <soren> persia: Oh. I thought I tried ubuntu/+builds already. That's odd.
[10:23] <soren> Oh.
[10:23] <soren> You have to sepll "builds" correctly, apparantly.
[10:24] <soren> And "spell" as well.
[10:24]  * ogra thought that was deliberate :)
[10:24] <persia> I seem to remember there was some reason why I always use /ubuntu/${dist}/+builds, but I can't recall the actual reason.
[10:25] <soren> persia: Do you happen to know how to limit it to a single arch?
[10:27] <persia> soren, Only on a per-release basis (e.g. https://launchpad.net/ubuntu/jaunty/hppa/+builds)
[10:27] <persia> That the generalised form doesn't work might be a bug, but you've the use case for it, so would be the better candidate to file than I.
[10:27] <soren> persia: That works. Thanks!
[10:35] <soren> Is anyone filling in as the substitute archive admin of the day today?
[10:35] <pitti> soren: why substitute?
[10:36] <soren> pitti: I'm told today is a bank holiday in Australia.
[10:36] <pitti> oh, I see
[10:36] <soren> ...and AFAIR, it's StevenK's aa day.
[10:36] <soren> pitti: Did you just volunteer? :D
[10:36] <pitti> nope
[10:37] <pitti> I stepped down from archive days :)
[10:37] <soren> Didn't think so, but thought I'd try my luck anyway. :)
[10:37]  * pitti has 150% hands full, sorry
[10:38] <soren> pitti: Don't worry about it. I'll find another helpless victim.
[10:39] <directhex> me! me! pick me!
[10:40] <PecisDarbs> directhex: helpless victims usually don't show iniciative, so keep your voice down :)
[10:40] <soren> directhex: You're clearly not helpless.
[10:40] <PecisDarbs> :D
[10:40] <soren> doing it wrong.
[10:46] <cjwatson> archive> I'll do some in a bit, but I need to reboot first
[10:46] <directhex> (into his vista partition)
[10:46] <cjwatson> :-P
[10:50] <MacSlow> why can't I change the "Importance" of a bug in e.g. https://bugs.edge.launchpad.net/ubuntu/+source/notify-osd/+bug/331235 ?
[10:51] <dholbach> MacSlow: not in ~ubuntu-bugcontrol?
[10:51] <directhex> MacSlow, nobody can unless they have launchpad awesomeification powers
[10:51] <directhex> or what dholbach said
[10:51] <MacSlow> dholbach, directhex: but I could change the importance of some other bugs
[10:52] <dholbach> MacSlow: that were not in the lp.net/ubuntu namespace and your own project?
[10:52] <MacSlow> dholbach, directhex: problem there currently is ... there are 3 or 4 pages where pepole can file bugs on alsdorf/notify-osd
[10:56] <Geek`N`Proud> Hey guys.  Is Ubuntu 9.04 getting Firefox 3.1 at any point?
[10:58] <jeromeg> could someone please review xfce4-notifyd which is waiting in NEW ?
[11:04] <cjwatson> Geek`N`Proud: there's a firefox-3.1 package for people to play with; I don't know about the default
[11:14] <Geek`N`Proud> cjwatson: okay cool =]
[11:27] <MacSlow> what's gnome-stracciatella ?
[11:29] <cjwatson> MacSlow: https://blueprints.launchpad.net/ubuntu/+spec/stracciatella-session
[11:29] <cjwatson> I gather that stracciatella is some kind of fancy word for vanilla
[11:29] <directhex> MacSlow, hard to install on the command line, that's what
[11:29] <cjwatson> actually a bit more than that. http://en.wikipedia.org/wiki/Stracciatella
[11:30] <MacSlow> cjwatson, I only know it as ice-cream
[11:30] <MacSlow> ah interesting
[11:30] <pitti> cjwatson, MacSlow: it's not plain vanilla GNOME, it still has some brownish bits in it (Ubuntu patches, and smaller Ubuntu changes)
[11:30] <pitti> MacSlow: yes, it indeed is a pun referring to ice cream
[11:31] <giskard> stracciatella == cream + chocolate drops (icecream)
[11:31] <pitti> providing a pure vanilla GNOME session would be very hard to do with current technologies
[11:31] <pitti> that's rather for grumpy groundhog
[11:34] <giskard> anyway, i've sent a test mail to my ubuntu.com mail address and suddenly i'm receiving a lot of spam to this address. it's a coincidence?
[11:34] <ogra> "some brown crumbs" haha
[12:25] <maxb> What determines whether a package is chosen to be in ubuntu-desktop's Depends, vs. its Recommends ? Is it just a matter of a design decision on the relative importance of the package? Or is there some greater significance?
[12:26] <IntuitiveNipple> Depends means it is required for the package to function, Recommends means it won't crash if that package isn't there
[12:26] <IntuitiveNipple> See the Debian Policy for the precise definitions of course
[12:27] <maxb> IntuitiveNipple: those definitions don't really apply to a metapackage
[12:27] <maxb> ubuntu-desktop doesn't "function" it just exists to cause the package manager to behave in certain ways
[12:31] <IntuitiveNipple> Policy seems pretty clear to me: "The Recommends field should list packages that would be found together with this one in all but unusual installations"
[12:31] <IntuitiveNipple> "This declares an absolute dependency. A package will not be configured unless all of the packages listed in its Depends field have been correctly configured"
[12:31] <cjwatson> maxb: loosely, the intent is that Depends are core parts of the desktop without which it really isn't the Ubuntu desktop, and Recommends are things like applications that you can reasonably swap out for alternatives
[12:31] <cjwatson> this is not necessarily implemented entirely consistently, but that's the idea
[12:32] <cjwatson> IntuitiveNipple: I think he understands that, he's asking for reasoning
[12:33]  * maxb wonders whether the argument "notify-osd can reasonably be swapped out for notification-daemon, please demote to recommends" would gain any sympathy
[12:33] <IntuitiveNipple> cjwatson: Hah! While you're there. Those partman issues with Ubiquity... I've supported two other users via remote SSH with the similar situations. One was caused by the 'Automatic resize' option and left the partition table on-disk different to the one in-memory.
[12:33] <cjwatson> I'm not here for long enough to diagnose that :-) I'm about to go out for lunch
[12:34] <cjwatson> I assume you are busy gathering all the necessary log files, preferably including a hex dump of the boot sector
[12:34] <IntuitiveNipple> cjwatson: No, I'm not expecting you to.... just a heads-up ... I spent 6 hours on it.
[12:34] <cjwatson> (od -Ax -tx1 -N512 /dev/sda)
[12:34] <IntuitiveNipple> cjwatson: I have enough that I *hope* (when I can find time) to be able to reproduce it in a VM
[12:34] <cjwatson> IntuitiveNipple: sounds like the sort of thing that could be caused by a missing ped_commit_to_disk or whatever it is, and that could well be due to a partman logic bug; /var/log/partman will be necessary
[12:35] <TuTUXG> after update the restricted-modules, nvidia driver(180.29) keeps crash my X, I can see the nvidia logo but cannot get into gdm screen, any ideas?
[12:35] <cjwatson> maxb: do bear in mind, though, that it is not a design goal of Ubuntu that all conceivable changes can be made without removing the ubuntu-desktop package; indeed for certain changes it makes sense to remove ubuntu-desktop, since you're now taking broad responsibility for your own package selection
[12:36] <IntuitiveNipple> cjwatson: It caused 'logical partition to overlap extended' - due to multiple sub-extended partition sectors
[12:36] <TuTUXG> jaunty
[12:36] <cjwatson> what is a "sub-extended partition sector"?
[12:36] <cjwatson> the sector vs. cluster thing that you were talking about earlier?
[12:36] <IntuitiveNipple> cjwatson: primary -> extended > extended > extended
[12:37] <cjwatson> oh, you mean chained extended partitions
[12:37] <IntuitiveNipple> cjwatson: Yes :)
[12:38] <IntuitiveNipple> The user's situation was two existing file-systems, one at start of disk, one towards the end, and resized to create gaps between where new extended/logical were created... poor thing just got itself confused :)
[12:39] <ogra> cjwatson, did you make the changes for nslu2 in d-i to disable the keyboard selection ?
[12:40] <ogra> (the stuff i verified recently)
[12:43] <cjwatson> ogra: you mean removing console-setup-udeb? no, not yet
[12:43] <cjwatson> ogra: I'll do it after lunch
[12:43] <ogra> cjwatson, there was more ... http://paste.ubuntu.com/120104/
[12:44] <ogra> though it still hits oom ... i'll need to see what i can do about bug 331510
[12:44] <pitti> apw: just reviewed https://code.edge.launchpad.net/~apw/apport/suspend-resume-pt3/+merge/3684, needs some changes
[12:44] <apw> pitti, no problem
[12:46] <apw> pitti, where will you feedback?
[12:47] <pitti> apw: I did it in the merge request itself
[12:47] <apw> cool
[12:49] <pitti> apw: but great idea to autoamtically include it in the bug title -- that will also help to avoid filing dupes
[12:49] <pitti> since LP proposes existing bugs with the same title
[12:49] <apw> yeah i see how i missed the dmidecode one as the resume stuff is always root, bah
[12:50] <pitti> apw: I really think the existing info from hal should suffice
[12:50] <apw> yeah it does, i wish i'd noticed it was in there, i've been asking people for info
[12:50] <apw> which was hiding there all alone!
[12:51] <pitti> I guess it's not immediately visible, since it's an attachment
[12:51] <apw> yeah, silly error on my part
[12:51] <ogra> also please dont forget that we support arches that dont have PCI busses exposed to the system or dont have dmidecode :)
[12:51] <apw> yeah i knew that, and expect it to just add a not found to the report
[12:51] <ogra> i.e. make them fail gracefully please if you implement something based on it
[12:51] <pitti> apw: also, do you actually need to run attach_hardware? the linux package hook already does that
[12:52] <apw> it gets run after the report generator runs
[12:52] <pitti> apw: if it isn't there on existing reports, then there's something wrong with the hook, or how it is called
[12:52] <apw> so i don't have the pr[Hal] th
[12:52] <apw> thing defined yet
[12:52] <pitti> right, indeed
[12:52] <apw> it gets defined on submit, ie after i needed it to set the title
[12:52] <apw> that was one of my queries, if there was a correct way to run the hooks earlier
[12:54] <apw> i could add it unconditionally to all kernel reports i believe
[12:54] <apw> ie, not doing it in the suspend specific parts, but it does feel like it would be nice to have it possible there
[12:55] <apw> pitti, it is a little supprising that the hooks don't run at apport.report.Report('foo') time
[12:55] <pitti> apw: they can't, they need the SourcePackage: and Package: fields first
[12:55] <apw> perhaps we could offer an optional
[12:56] <apw> apport.hookutils.trigger_hooks()
[12:56] <pitti> apw: so, for now it's fine to call attach_hardware in your script
[12:56] <apw> which runs them ealrly
[12:56] <pitti> apw: that's report.add_hookinfo()
[12:56] <pitti> add_hooks_info(), sorry
[12:56] <apw> does it handle being run twice cleanly
[12:56] <apw> ie. do nothing the second time.
[12:56] <apw> if so then that might be a clean way to do it
[12:56] <pitti> should, it's just not very efficient
[12:57] <apw> i add that, and make it do nothing the second time
[12:57] <apw> ie. self detecting
[12:57] <pitti> apw: for now I propose that you just call attach_hardware()
[12:57] <pitti> i. e. as you do now
[12:57] <apw> will do
[12:58] <pitti> take it as it is, parse out system.hardware.product and system.hardware.vendor and mangle the bug title accordingly
[12:58] <apw> yep, on it
[13:14] <NCommander> infinity, or lamont, can someone determine why https://edge.launchpad.net/ubuntu/jaunty/+source/kdebindings/4:4.2.0-0ubuntu2 didn't get dispatched to HPPA? (its not in P-a-s- as far as I know and 0ubuntu1 did get attempted ...)
[13:21] <doko> Koon: were you able to work with the updated ecj and eucalyptus?
[13:22] <Koon> doko: not exactly.
[13:24] <apw> pitti, ok, i've reworked that branch and pushed it up.  merge request updated
[13:49] <pitti> apw: great, thanks
[13:59] <pitti> apw: looks great now
[14:00] <apw> pitti, cool thanks
[14:00] <pitti> apw: I assume that you tested this already? or should I give it another go?
[14:01] <apw> i have tested it on my crashy laptop, let me test all three interfaces one more time
[14:02] <apw> seems to generate the right thing in all three on my crashy laptop
[14:08]  * cjwatson attempts to resurrect his IPv6 networking
[14:09] <cjwatson> I have to cast Turn Undead on the bloody thing every time I care
[14:19] <mvo_> hm, under what circumstance can X_LOADTEMPLATEFILE hang? I get this from grub/ucf on failed upgrades apparently
[14:19] <mvo_> when dpkg --configure -a runs for recovery
[14:36] <cjwatson> mvo_: suggests to me that it isn't connected up to debconf properly
[14:36] <cjwatson> if it runs properly, it's just walking through a file, there's no reason it should hang
[14:39] <mvo_> thanks cjwatson
[14:43] <cjwatson> mvo_: of course IME the usual solution to this is to sit down and think very hard about what fds are connected to what other fds :-/
[14:43] <cjwatson> sometimes involving paper
[14:51] <seb128> jdstrand_: hey, sorry I was busy when you pinged yesterday and forgot to reply to your question yesterday
[14:52] <jdstrand_> seb128: np! I know how these things go :)
[14:53] <seb128> jdstrand_: alt-f2 is a gnome-settings-daemon shortcut I think
[14:53] <jdstrand> seb128: does it work for you?
[14:53] <seb128> jdstrand: is it listed in gnome-keybinding-properties as a "show the run application dialog box" action?
[14:53] <seb128> jdstrand: yes
[14:54] <jdstrand> odd...
[14:54] <seb128> jdstrand: do you use compiz?
[14:54] <jdstrand> seb128: I do, yes
[14:54] <seb128> could be a compiz issue, though I don't get the bug on my laptop which runs compiz
[14:54] <seb128> jdstrand: did you try with a new user?
[14:55] <jdstrand> seb128: yes, on my laptop, which doesn't run compiz, it works
[14:55] <seb128> that would tell us if that's due to some configuration for your user
[14:55] <seb128> I would first bet on some compiz setting creating the issue
[14:55] <jdstrand> (the yes was not an answer to your new user question, which is 'no')
[14:55] <seb128> could you try with a new user or guest session? ;-)
[14:56] <cjwatson> grr, for some reason connect() to an IPv6 link-local address isn't working
[14:56] <cjwatson> it seems to work to a global-scope address
[14:56] <cjwatson> connect(3, {sa_family=AF_INET6, sin6_port=htons(46372), inet_pton(AF_INET6, "feac:0:0:1499::11", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EINVAL (Invalid argument)
[14:56] <cjwatson> connect(3, {sa_family=AF_INET6, sin6_port=htons(46374), inet_pton(AF_INET6, "2001:41a8:604::1:1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0
[14:57] <cjwatson> mdz: ^- this is what we were seeing on the plane I think
[14:58] <cjwatson> mdz: aha; the problem is that one needs to explicitly specify an interface when connecting to link-local addresses
[14:58] <mdz> cjwatsonweird
[14:58] <cjwatson> ping6(8) documents this (-I)
[14:58] <mdz> cjwatson: which applications actually let you do that?
[14:59] <cjwatson> tracepath6 doesn't
[14:59] <cjwatson> traceroute6 does
[14:59] <cjwatson> as for, you know, actual applications I have no idea
[15:00] <cjwatson> but at least now I know how to debug my network
[15:00] <jdstrand> seb128: I will check as a new user and look into compiz. if it is a real bug I'll file it. thanks for your help :)
[15:00] <seb128> jdstrand: you're welcome
[15:04] <siretart> cjwatson: FYI, `ssh feac:0:0:1499::11%ethX` seems to do the trick for ssh
[15:04] <cjwatson> thanks; interesting, that's undocumented
[15:06] <cjwatson> ah, it's implemented in getaddrinfo()
[15:06] <cjwatson> so that's probably in fact quite widely-supported
[15:08] <cjwatson> and indeed works with tracepath6
[15:24] <calc> anyone happen to know if apt package list does not get updated if you are not on a regular net connection?
[15:24] <calc> eg does it still update across mobile broadband, i'm looking at the script and it looks like it downloads anytime you are on mains power(?)
[15:34] <calc> yipee my new laptop hd will be here today :)
[15:36] <pitti> calc: ssd? fast as hell? :-)
[15:37] <pitti> calc: apt-get> I think that's correct, whenever you have a default route it'll download them
[15:37] <pitti> arguable if you are on a mobile connection, indeed
[15:38] <calc> pitti: not a ssd but a 7200 500gb drive
[15:38] <pitti> calc: wow, that'll fit a couple of OO.o trees :)
[15:39] <calc> pitti: yea for the mobile case that could be very expensive and even in flat rate cases usually have low limits
[15:39] <calc> pitti: heh yea
[15:39] <calc> pitti: the update-notifier change reminded me about the fact apt pulls the data daily
[15:39] <ion_> pitti: About three?
[15:40] <calc> for devel releases that is around 1.3GB/month of package lists
[15:40] <pitti> ion_: heh
[15:40] <slytherin> Does anyone know any particular reason why *ubuntu-restricted-extras has direct recommends on libdvdread3 and libmp3lame0?
[15:40] <pitti> ion_: well, I never had such a large internal hard disk (my /home is usually 50 GB), and I built OO.o before
[15:41] <pitti> slytherin: isn't that its primary purpose?
[15:41] <ion_> calc: Someone should finish apt-sync. :-)
[15:41] <pitti> to pull in the questionable codec/CSS stuff?
[15:42] <slytherin> pitti: but it already recommends gstreamer0.10-plugins-bad and other similar packages which will pull these libraries anyway.
[15:42] <pitti> slytherin: ah, I see; I guess those can be droppped then
[15:43] <slytherin> pitti: are *-restricted-extras packages managed by any seed?
[15:43] <pitti> slytherin: I don't think so; apparently it's not even in bzr
[15:43] <slytherin> ok, then I will update those packages.
[15:44] <seb128_> tseliot: hey
[15:44] <seb128_> Original exception was:
[15:44] <seb128_> Traceback (most recent call last):
[15:44] <seb128_>   File "/usr/bin/nvidia-detector", line 2, in <module>
[15:44] <seb128_>     import NvidiaDetector
[15:44] <seb128_> ImportError: No module named NvidiaDetector
[15:44] <seb128_> is that a known issue?
[15:44] <seb128_> current jaunty
[15:44] <pitti> seb128_: you have nvidia-common installed?
[15:44] <pitti> $ nvidia-detector
[15:44] <pitti> none
[15:44] <seb128_> pitti: I guess since that's the postinst for this one breaking
[15:44] <pitti> ah, python-central fun
[15:45] <seb128_> hum
[15:45]  * seb128_ looks at doko
[15:45] <tseliot> seb128: mvo reported the problem to me and I committed what he suggested and volunteered to sponsor the upload
[15:46] <doko> which package is this?
[15:46] <seb128_> doko: nvidia-common
[15:46] <tseliot> seb128_:  we tried adding export DH_PYCENTRAL=nomove to the debian/rules
[15:47] <saispo> hi
[15:48] <saispo> it's possible to rsync somewhere old feisty* repository ?
[15:48] <pitti> saispo: old-releases.ubuntu.com
[15:48] <saispo> pitti: thanks, will see
[15:49] <pitti> saispo: archaeology? :-)
[15:49] <saispo> pitti: yep :/ i ha ve a lot of feisty server :/ and when i rsync i lost all things ;)
[15:50] <pitti> saispo: eww -- not in production on the internet, I hope
[15:50] <savvas> saispo: you can upgrade using the alternate cd, choose "No" when asked to upgrade from the internet
[15:50] <saispo> pitti: it's hard to explain ;)
[15:51] <savvas> http://www.ubuntu.com/getubuntu/upgrading#Upgrading%20Using%20the%20Alternate%20CD/DVD
[15:51] <saispo> savvas: with near 12000 server ? ;)
[15:51] <saispo> pitti: old-release.ubuntu.com have an rsync server ?
[15:51] <ogra> get some inline skates :)
[15:51] <pitti> saispo: I don't know
[15:51] <savvas> hehe
[15:51] <savvas> ogra: original :P
[15:52] <saispo> ogra: in ethernet wired ? ;)
[15:52] <savvas> saispo: then support this: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/319146 :P
[15:53] <saispo> savvas: thanks to help me ;)
[15:55] <savvas> saispo: but the alternate cd and choosing "No" is the only working way I found, I don't know about the servers unfortunately, there's probably a similar "non-gui-through-console" way to mass-upgrade them
[16:03] <slytherin> pitti: should I also remove libdvdread3 and libmp3lame0 for kubuntu-restricted-extras?
[16:03] <kagou> bryce, please hace a look at my last comment on #325394
[16:05] <bryce> kagou: sure
[16:06] <kagou> thnaks
[16:06] <kagou> thanks
[16:08] <pitti> slytherin: if it's pulled in by something else, then sure; but these libraries might get dlopen()ed, so please triple-check, and check the changelog why they were added
[16:10] <Riddell> slytherin: why remove them?
[16:10] <cjwatson> I'd like anyone who can to test the glibc packages in "deb http://ppa.launchpad.net/cjwatson/ppa/ubuntu jaunty main", relating to bug 313218
[16:10] <slytherin> pitti: they were added back in gutsy. No explanation as to why they should be there for kubuntu. kubuntu apps use xine backend by default IIRC.
[16:10] <cjwatson> I'm interested in tests from people with real IPv6 connectivity as well as from people who suffer from that bug, since I've been unable to resurrect my IPv6 setup so far
[16:10] <pitti> slytherin: for example, some programs used to dlopen() libdvdcss
[16:10] <slytherin> Riddell: I am just asking. In case of ubuntu and xubuntu they will be pulled by gstreamer plugins so no point in having those direct dependencies.
[16:11] <BUGabundo> pitti: https://bugs.edge.launchpad.net/ubuntu/+source/apport/+bug/124338/
[16:11] <slytherin> pitti: right. I will leave them for kubuntu for now.
[16:11] <BUGabundo> its failing to build
[16:11] <BUGabundo> https://edge.launchpad.net/ubuntu/+source/apport/0.132/+build/875501
[16:12] <seb128> BUGabundo: uploaders get build failure emails no need to ping on IRC too
[16:12] <pitti> dh_pycentral: /usr/share/debhelper/autoscripts/prerm-pycentral does not exist
[16:12] <pitti> make: *** [binary-install/apport] Error 1
[16:12] <pitti> WTF?
[16:12] <BUGabundo> ok seb128
[16:13] <BUGabundo> it seems pitti did not read the email in time
[16:13] <BUGabundo> ehehe
[16:13] <pitti> BUGabundo: will look later
[16:13] <BUGabundo> thanks
[16:13] <BUGabundo> btw can I just branch LP?
[16:13] <BUGabundo> its a python script right?
[16:13] <seb128> BUGabundo: if people don't read there email every 5 minutes that's often because they try to get work done ;-)
[16:13] <seb128> there -> their
[16:14] <BUGabundo> I know the feeling seb128
[16:14] <BUGabundo> I just read the announment and tried to get it
[16:14] <BUGabundo> and then found the failure
[16:14] <seb128> BUGabundo: well, IRC ping doesn't go in the right direction then, they just add extra noise to the stack
[16:14] <pitti> I know, people are probably eager to test apport-collect :)
[16:14] <BUGabundo> sorry
[16:14]  * BUGabundo shuts up
[16:14] <BUGabundo> pitti: it will come in handy
[16:15] <pitti> BUGabundo: but in general seb128 is right, at FF everyone is busy and needs to batch their work for efficiency
[16:15] <BUGabundo> right now I just upload the logs to new bugs and get them marked as dupes
[16:15] <seb128> BUGabundo: don't get me wrong I appreciate you being enthousiastic but there is no need to ping people in the second something goes wrong, better to let them handle their schedule and ping after a while if nothing is happening
[16:15] <pitti> BUGabundo: feel like finding out what went wrong? it builds fine on my machine
[16:15] <BUGabundo> hey you won't here from me more about *this* issue
[16:17] <BUGabundo> pitti: I would if a I new a bit more about it
[16:17] <BUGabundo> and right now you guys don't have the time to hand carry me..
[16:17] <BUGabundo> maybe next time
[16:17] <pitti> ah, there's a new python-central coming through apt-get dist-upgrade
[16:17] <pitti> maybe doko broke it :)
[16:18] <BUGabundo> ehhe
[16:19] <BUGabundo> see.. know I learned something (from all this noise)
[16:29] <seb128> kirkland, james_w, jdstrand: does anybody of you want to process syncs today?
[16:29] <seb128> the list has quite some waiting and it would be nice to clean it
[16:30] <kirkland> seb128: i can push some through
[16:30] <seb128> kirkland: would be appreciated
[16:30] <jdstrand> kirkland: leave a couple for me. I haven't processed a sync request yet :)
[16:31] <kirkland> jdstrand: :-D
[16:31] <slytherin> I have a question. I filed a sync bug today (about 12 hours ago) not knowing FF was in effect. Do I need to convert it to FFE?
[16:31] <kirkland> jdstrand: you can tackle them if you want :-)
[16:31] <jdstrand> kirkland, james_w: sure-- I'll get started and ping you guys if/when there are any left
[16:32] <kirkland> jdstrand: no prob, have fun
[16:32] <seb128> slytherin: is that a new upstream version?
[16:32] <slytherin> seb128: yes
[16:32] <seb128> it's border line then, usually request filed before the freeze are just synced
[16:33] <slytherin> Ok. I will add all the info needed by FFE to the bug anyway.
[16:33] <slytherin> When did the freeze come into effect exactly?
[16:53] <pitti> apw: whoops, I forgot to upload apport with your changes; done now
[16:53] <apw> heh happens to the best of us
[16:56] <LaserJock> is a FFe needed for a new binary that results from a bugfix?
[16:56] <kirkland> jdstrand: i found it useful to do a few syncs by hand, and after i got the hang of it, i used syncbugbot
[16:57] <LaserJock> it lands in NEW so I'm guessing so, but it's not new source or new upstream release
[16:57] <jdstrand> kirkland: that is exactly what I am doing
[16:57] <kirkland> jdstrand: ;-)
[17:01] <kirkland> Keybuk: ping, regarding pitti's comments on ubuntu-devel@ about powernowd and the server
[17:02] <kirkland> Keybuk: we just recently added powernowd to the server to get cpu freq scaling (and ondemand by default)
[17:02] <Keybuk> did you add it because of the daemon or the init script?
[17:03] <kirkland> Keybuk: init script, i think;  the daemon isn't running
[17:03] <Keybuk> ok, great
[17:03] <Keybuk> that's solved by the kernel patches in 2.6.28
[17:03] <Keybuk> in fact, the init script was broken anyway
[17:03] <kirkland> Keybuk: sweet, let me remove powernowd and reboot
[17:03] <Keybuk> kirkland: make sure you have 2.6.28-8.24
[17:04] <jdstrand> kirkland: in the bugs I see 'Sync request ACKed'. am I to assume that this review is required to sync?
[17:05] <kirkland> jdstrand: yeah, check that it's ack'd by someone with MOTU or core-dev privs
[17:05] <kirkland> jdstrand: you might also check the changelog too
[17:06] <kirkland> jdstrand: to sort of make sure that the sync is mostly bug fixes at this point (past FF)
[17:06] <kirkland> Keybuk: linux-image-2.6.28-8-server
[17:07] <Keybuk> kirkland: which version?
[17:07] <kirkland> Keybuk: rebooting atm
[17:07] <Keybuk> the version is important ;)
[17:08] <kirkland> Keybuk: ii  linux-image-2.6.28-8-server       2.6.28-8.24                       Linux kernel image for version 2.6.28 on x86
[17:08] <kirkland> Keybuk: rc  powernowd                         1.00-1ubuntu3                     control cpu speed and voltage using 2.6 kern
[17:08] <kirkland> Keybuk: ^ removed
[17:09] <Keybuk> kirkland: that's ok - that includes the right patches
[17:09] <kirkland> Keybuk: ls /sys/devices/system/cpu/cpu0/cpufreq/ checks out
[17:09] <kirkland> Keybuk: rock-tastic
[17:09] <Keybuk> kirkland: what does scaling_driver and scaling_governor say?
[17:09] <calc> the drive actually arrived, i am somewhat surprised since i bought it from a questionable website
[17:09] <kirkland> $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
[17:09] <kirkland> ondemand
[17:09] <Keybuk> and driver?
[17:09] <kirkland> $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
[17:09] <kirkland> powernow-k8
[17:09] <Keybuk> sweet
[17:09] <calc> no other companies in the US had the drive in stock though so i just went for it ;)
[17:10] <kirkland> Keybuk: cool, do you agree it's safe to remove powernowd from the server seed?
[17:11] <LaserJock> calc: have you looked in the box? :-)
[17:11] <calc> LaserJock: yea and even checked to make sure the drive is listed as in warranty :)
[17:11] <LaserJock> calc: I once bought a CD burner from Walmart that was an empty CD drive case with a photocopy of the burner's frontplate on the front :-)
[17:11] <calc> LaserJock: its a new seagate moments 7200.4 500gb g-shock drive
[17:12] <calc> about to rip the tiny 160gb drive out of my x200 to replace it with this
[17:13] <Keybuk> kirkland: I think I already removed it ;)
[17:13] <Keybuk> I just didn't regenerate the meta package
[17:16] <Keybuk> slangasek: if you want to remove powernowd from the archive ... <g>
[17:17] <tkamppeter> pitti, I have seen that you have passed the -proposed package of CUPS to the updates. Cab you take the next one from the queue to -proposed? It is supposed to fix 3 or 4 bugs.
[17:17] <kirkland> Keybuk: so you have :-)
[17:18] <pitti> tkamppeter: I'll attack the SRU soon again, yes; these days are just pretty crazy due to FF
[17:18] <jdstrand> kirkland: for LPUID it should be the requester, not the acker, correct?
[17:18] <Keybuk> pitti: btw, have you rebooted your laptop in the last couple of days?
[17:18] <Keybuk> if not, want to check something
[17:19] <tkamppeter> pitti, yes, everyone is rushing in the last stuff, I have done arouind 20 dputs this week.
[17:19] <pitti> Keybuk: I reboot every day
[17:20] <pitti> Keybuk: I have some recent trouble with suspend/hibernate
[17:20] <Keybuk> pitti: damn
[17:20] <Keybuk> pitti: I guess you have a /sys/devices/system/cpu/cpu0/cpufreq ?
[17:20] <kirkland> jdstrand: i put the acker, if the requestor doesn't have commit priv's
[17:20] <pitti> Keybuk: yes; that didn't change in ages, AFAIK
[17:20] <pitti> (the structure, anyway)
[17:20] <kirkland> jdstrand: ie, the person we can track down and ask about it, if the sync goes boom :-)
[17:20] <jdstrand> kirkland: is that policy documented somewhere?
[17:20] <Keybuk> pitti: are you sure?
[17:20] <Keybuk> pitti: my laptop stopped loading a cpu scaling driver a while back
[17:21] <Keybuk> so it wasn't actually working
[17:21] <pitti> Keybuk: well, admittedly it's the first time I looked into it in jaunty
[17:21] <kirkland> jdstrand: I think that's what Riddell advised me in #ubuntu-release
[17:21] <kirkland> Riddell: can you please confirm that I understood you correctly?
[17:21] <pitti> Keybuk: last time was probably in intrepid or even hardy
[17:21] <kirkland> jdstrand: if Riddle confirms, we should probably add that to the wiki page
[17:21] <jdstrand> kirkland: yes, I shall
[17:21] <pitti> Keybuk: I'm just 100% sure that the actual CPU scaling has always worked
[17:21] <Keybuk> pitti: what does scaling_driver say?
[17:21] <pitti> thus I had no real reason to poke it
[17:21] <pitti> Keybuk: acpi-cpufreq
[17:22] <pitti> Keybuk: I still have powernowd installed; shouldn't I?
[17:22] <Keybuk> pitti: that at least has likely changed
[17:22] <Keybuk> pitti: you can safely purge powernowd
[17:22] <pitti> Keybuk: $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
[17:22] <pitti> ondemand
[17:22] <Keybuk> pitti: powernowd's init script _probably_ preferred speedstep-centrino for your machine
[17:22] <pitti> I think that was "userspace" in ancient days; is that possible?
[17:22] <Keybuk> pitti: powernowd does require that to be userspace
[17:22] <Keybuk> but the powernowd init script always set it to "ondemand" in recent years and didn't start powernowd
[17:23] <Keybuk> now we just changed the kernel config to be right to begin with ;)
[17:23]  * pitti purges
[17:23] <pitti> I'm glad for every bit that doesn't slow down my boot ime :)
[17:23] <Riddell> kirkland: "first person who knows what they're doing" generally, so if the requester doesn't have upload right but is an active contributor who's likely to sort things out if there's a problem that's ok
[17:23] <Keybuk> do you still have freaky I/O ?
[17:23] <Riddell> jdstrand: ^^
[17:23] <jdstrand> Riddell: ok thanks
[17:24] <kirkland> Riddell: thanks.
[17:24] <pitti> Keybuk: should that have changed recently?
[17:24] <Keybuk> pitti: I'm slowly narrowing that down, scarily it seems to only affect certain laptops
[17:24] <pitti> oh
[17:24] <pitti> Keybuk: after purging powernowd
[17:24] <pitti> $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
[17:24] <Keybuk> bootcharts I have from thinkpad users don't show it
[17:24] <pitti> performance
[17:24] <Keybuk> pitti: did you reboot after purging?
[17:24] <pitti> no
[17:24] <Keybuk> ah, the init script probably changed it on its way out
[17:24] <Keybuk> as a parting gesture
[17:24] <pitti> right and it doesn't scale right now
[17:25] <Keybuk> reboot :p
[17:25] <pitti> heh, no problem
[17:25] <pitti> Keybuk: if I'm at it, I'll measure boot time with the kernel du jour
[17:28] <cjwatson> syncs> TBH I just feed the sync to syncbugbot and let it sort it out
[17:28] <cjwatson> which generally produces the original requestor, but ... time
[17:28] <calc> does anyone know if there is a trick to ejecting an ultrabay device? i have a x200 ultrabase with a ultrabay dvdrw i want to eject but i can't determine how to make it eject
[17:29] <pitti> Keybuk: so the 12 second hang from grub to usplash reduced to 5, but total grub->gdm time increased slightly to 54 seconds
[17:30] <Keybuk> got a bootchart?
[17:30] <pitti> Keybuk: no, I'm usually running without; if you are interested, I can do one
[17:30] <pitti> Keybuk: eek, this now pulls in the entire openjdk
[17:31] <LaserJock> pitti: apport-collect sounds awesome, thanks for that
[17:31] <pitti> Keybuk: with -headless I just had to add a symlink to load the awt library at a different place
[17:31] <pitti> LaserJock: \o/
[17:31] <LaserJock> pitti: will it just be available for >= Jaunty or can it get backported somehow?
[17:32] <pitti> LaserJock: it just needs python-apport (pretty much any version >= gutsy should work) and python-launchpadlib
[17:32] <slytherin> calc: is that like slot loading drive?
[17:32] <calc> wow hdparm returns 97MB/s for this hd
[17:32] <calc> slytherin: its a removable drive for thinkpads, but i can't seem to make it remove
[17:32] <Keybuk> pitti: oh, if there's a better way to fix bootchart, please upload
[17:33] <pitti> Keybuk: not sure how it figures out the library locations; it crashed with "cannot find /something/awt.so"
[17:34] <tkamppeter> pitti, I have a little SRU problem. See bug 303691. stek79 reports that the last fix on foomatic-rip (0ubuntu3) solved his problem. Unfortunately I have put a wrong bug number into the debian/changelog and so the bug does not get connected to the package. Can you move foomatic-rip 0ubuntu3 into -updates? Thanks.
[17:34] <calc> my desktop drive only does 110MB/s so this laptop drive is pretty fast :)
[17:34] <Keybuk> pitti: yeah, I know very little about Java :-(
[17:37] <calc> is there a high speed non zero device i can use to write data to disk? urandom doesn't seem that fast at least on this machine for some reason
[17:38] <calc> its only doing ~ 5MB/s
[17:38] <pitti> calc: you could cat >/dev/null an .iso file, to get it into the cache, and then cp it to a new file?
[17:38] <pitti> calc: or try hdparm -tT /dev/sda ?
[17:39] <calc> pitti: i'm trying to write to all sectors on disk to prime it for smart
[17:39] <pitti> calc: but what's actually wrong with /dev/null? I don't think it creates sparse files by default
[17:39] <calc> i suppose writing zeros may be good enough for that
[17:39] <calc> eg dd if=something of=/dev/sda bs=16M
[17:39] <pitti> if I want to properly delete all unused disk blocks on a HD I'm about to give away, I cat /dev/zero > bigfile and rm it afterwards
[17:39] <pitti> and it actually writes down zero blocks
[17:40] <calc> pitti: basically i want to force writes to all sectors on the drive because smart needs that (aiui) to detect if there are any bad sectors that need to be remapped
[17:41] <pitti> calc: well, at least with the drives I tried it on, dd was okay; that won't catch the reserve sectors, of course, since that's HD firmware controlled
[17:41] <calc> so i think using /dev/zero probably is good enough assuming linux isn't too smart and detects the sector is already zeroed out
[17:41] <calc> yes, thats fine :)
[17:46] <calc> wow intrepid cd is too old to recognize my wifi :-\
[17:50] <cjwatson> slangasek,directhex: I've made britney treat Recommends from packages in Section: metapackages as if they were Depends; so that mono uninstallability we had will be caught in future
[17:50] <directhex> cjwatson, that's great!
[17:51] <directhex> now to work on monodevelop
[17:55] <slangasek> Keybuk: removing powernowd from the archive> can we have a bug report, please? :)
[17:56] <pitti> Keybuk: http://people.ubuntu.com/~pitti/tmp/jaunty-20090219-1.png
[17:57] <pitti> Keybuk: note that this is with GNOMEified readahead
[17:57] <pitti> Keybuk: oh, and I removed l-r-m
[17:58] <slangasek> cjwatson: ok, cool :)
[18:08] <pitti> slangasek: do you just need grub-common in main, or grub-pc and friends as well?
[18:08] <pitti> slangasek: with just -common I'd have a much less aching stomach :)
[18:09] <slangasek> pitti: grub-common now, but grub-pc eventually
[18:12] <Keybuk> pitti: care to try http://people.ubuntu.com/~scott/sreadahead_1.0-1~_i386.deb ?
[18:13] <pitti> Keybuk: with the default readahead list or my fat one?
[18:13] <Keybuk> it doesn't matter
[18:13] <pitti>  Conflicts: readahead
[18:13] <pitti> I see :)
[18:13] <Keybuk> you'll have to --force-depends --purge readahead anyway ;)
[18:13] <Keybuk> the first boot will generate you an sreadahead pack
[18:14] <Keybuk> (wait for /var/lib/sreadahead/pack to appear)
[18:14] <Keybuk> the second boot will use it
[18:14] <pitti> yay dynamism
[18:14] <pitti> Keybuk: when does it stop profiling?
[18:14] <Keybuk> it profiles for one minute after boot
[18:14] <pitti> is that tweakable?
[18:14] <Keybuk> yes
[18:14] <pitti> one minute hardly gets me to gdm
[18:14] <Keybuk> edit /etc/event.d/sreadahead and add -t 120
[18:15] <Keybuk> for example
[18:15] <pitti> Keybuk: trying...
[18:25] <pitti> Keybuk: done
[18:25] <pitti> Keybuk: first run with sreadahead: grub->gdm 77s, gdm->desk 46s
[18:25] <Keybuk> pitti: better with or without
[18:25] <pitti> kees: second run (with pack): grub->gdm 80s, gdm->desk 16s
[18:25] <pitti> erm, Keybuk ^
[18:25] <Keybuk> what was it with old readahead?
[18:25] <pitti> Keybuk: so, with the grub->gdm is slightly slower, but gdm->desktop is very fast
[18:26] <pitti> Keybuk: including GNOME, grub->gdm 50s, gdm->desktop 20s
[18:26] <pitti> ^ old readahead
[18:26] <Keybuk> ok
[18:26] <Keybuk> that fits my own testing
[18:26] <pitti> Keybuk: is it expected that bootchart stops working with sreadahead?
[18:26] <Keybuk> sreadahead is much slower than readahead if you have rotary disk
[18:26] <pitti> I didn't get any
[18:27] <Keybuk> pitti: probably a bootchart bug, I've noticed it fails to run sometimes
[18:27] <kenvandine> pitti: bootchart works fine for me with sreadahead
[18:27] <pitti> not even a log file
[18:28] <Keybuk> the question, of course, is whether sreadahead can be patched to behave like old readahead when you have a rotary disk
[18:28] <Keybuk> since it's collector is *far* better
[18:28] <pitti> bootchart> hang on, I suck; forgot to stop it
[18:29] <pitti> Keybuk: do you need bootcharts from both cases?
[18:29] <Keybuk> no, just your own observation is fine
[18:29] <Keybuk> proves I'm not going nuts
[18:30] <Keybuk> afaict. the problem is that sreadahead reads things in by order of when they were requested
[18:30] <Keybuk> whereas readahead reads things in by on-disk position order
[18:30] <slytherin> may I please know who processed the sync for libdvdnav? I just finished adding all the info assuming that it was going to be FFE.
[18:30] <pitti> Keybuk: sreadahead seems to have very little effect on booting; I see a lot of I/O in actual programs/daemons
[18:30] <Keybuk> (sreadahead also runs in parallel, readahead runs in series)
[18:30] <Keybuk> right
[18:30] <Keybuk> because sreadahead is fighting with the other processes for the I/O they need
[18:30] <pitti> readahead in parallel had a similar effect
[18:30] <Keybuk> and sends the disk seeking all over the place
[18:32] <Keybuk> pitti: now you have an sreadahead list fil
[18:32] <Keybuk> change the event.d start on to "start on starting rcS"
[18:33] <Keybuk> and delete/comment out the "service" line
[18:34] <pitti> Keybuk: oh, the test goes on; sorry, already reinstalled readahead
[18:35] <pitti> Keybuk: trying again
[18:35] <Keybuk> no problem :p
[18:35] <pitti> Keybuk: hm, sreadahead doesn't trigger an initramfs rebuild, should it?
[18:36] <Keybuk> no
[18:36] <pitti> ok
[18:36] <Keybuk> (it's not done in the initramfs :p)
[18:37] <Keybuk> oh, hmm, that doesn't work
[18:42] <Keybuk> pitti: that might work with the updated package
[18:44] <pitti> Keybuk: you mean "start on starting rcS" won't work?
[18:44] <pitti> Keybuk: anyway, I'm producing more accurate numbers and bootcharts for all cases
[18:44]  * pitti -> reboot again
[18:44] <Keybuk> it'll work with the new sreadahead package I think
[18:45] <Keybuk> heh, I just worked out why the powernowd init script doesn't work for me
[18:47] <Keybuk> no, I just unworked it out again
[18:47] <Keybuk> damn, it wasn't the bug I thought
[18:48] <Keybuk> not that it matters, I killed it :p
[18:52] <pitti> Keybuk:
[18:52] <pitti>                 1st     2nd     start on rcS
[18:52] <pitti> grub->gdm       82      84.5    70
[18:52] <pitti> gdm->desktop    43.5    16      16
[18:53] <pitti> Keybuk: so "start on rcS" is not far behind with gnome-tweaked readahead, and just about on par with default readahead
[18:53] <pitti> well, I tweaked sreadahead with -t120
[18:54] <Keybuk>  Keybuk: including GNOME, grub->gdm 50s, gdm->desktop 20s
[18:54] <Keybuk> "on par" being 20s slower ? :p
[18:55] <pitti> right, still 16 secs
[18:55] <pitti> Keybuk: except that I apparently forgot to rm /etc/rc2.d/stop-bootchart
[18:55] <pitti> so it created the bootchart during boot sequence, and doesn't include the desktop
[18:55] <pitti> grrr
[18:56] <Keybuk> heh
[18:56] <pitti> so a couple of seconds were wasted on that
[18:56] <Keybuk> still slower though :(
[18:56] <pitti> yes, definitively
[18:56] <Keybuk> much faster on SSD tho
[18:56] <Keybuk> maybe I should just include the readahead code in sreadahead, so it can do both <g>
[18:57] <pitti> but right now SSD is still pretty much a corner case
[18:57] <Keybuk> indeed
[18:57] <Keybuk> right, bbl
[18:57] <pitti> Keybuk: can you re-sort the sreadahead pack by disk order?
[18:57] <Keybuk> pitti: that's the idea
[18:57] <Keybuk> ie. write the code to do that
[18:57] <pitti> depending on whether it's rotary, of course
[18:58] <pitti> Keybuk: need any further tests?
[18:58] <pitti> otherwise I'll set up my desktop again and continue to do useful stuff :)
[18:59] <pitti> dear compiz, please react properly to resolution changes. love, pitti
[18:59] <pitti> s/compiz/gnome-panel/ as well
[19:12] <Svendo> Can proftpd be compiled with mod_tls as default so there is security for the users accounts ?
[19:16] <jdstrand> kirkland, james_w: fyi, sync requests are done for now
[19:21] <james_w> thanks jdstrand
[19:22] <Svendo> I've been wondering about this for quite a while and appears odd. Why is ubuntu the only distribution that doesnt supply proftpd with encryption ?
[19:24] <infinity> Svendo: We do...
[19:24] <Svendo> infinity, how ?
[19:24] <infinity> Svendo: It's linked with libssl, you just need to enable encryption in your configs.
[19:25] <Svendo> "proftpd -l" tells me there no mod_tls
[19:26] <Svendo> Theres no such thing you know
[19:26] <Svendo> Not in jaunty either as seems
[19:26] <infinity> /usr/lib/proftpd/mod_tls.la
[19:27] <infinity> /usr/lib/proftpd/mod_tls.so
[19:27] <infinity> It's compiled as an external module, not statically.
[19:27] <Svendo> So you have to add include statements you mean ?
[19:28] <infinity> /etc/proftpd/modules.conf
[19:28] <infinity> Just add LoadModule mod_tls.c
[19:28] <infinity> Which is actually there on my config.
[19:28] <infinity> I'm betting that "proftpd -l" only lists statically compiled modules, not runtime-loaded ones.
[19:29] <infinity> So, yeah.  I'd say it's working as intended, just configure SSL/TLS in your configs with whatever directives you need.
[19:30] <infinity> http://www.proftpd.org/docs/howto/TLS.html might prove helpful.
[19:33] <Svendo> infinity: That is true, all modules are compiled as such. Hence theres trouble supporting this feature on the debian/ubuntu side.
[19:33] <Svendo> Checked Jaunty dist
[19:35] <Svendo> Next, why cant bind/named be run within a chroot ?
[19:35] <Svendo> This is an outstanding issue with Jaunty as seems .. ?
[19:37] <Svendo> and the ubuntu dists before it
[19:37] <Svendo> It would be good if that can be done
[19:37] <infinity> adconrad@lucifer:~$ grep chroot /etc/init.d/bind9
[19:37] <infinity> # for a chrooted server: "-u bind -t /var/lib/named"
[19:37] <Svendo> can you start it then ?
[19:38] <infinity> (Change OPTIONS in /etc/default/bind9)
[19:38] <Svendo> Check it maybe..
[19:38] <Svendo> In my Jaunty it cant even read etc/localtime
[19:38] <Svendo> permission denied
[19:39] <Svendo> Even though its started as root
[19:40] <Svendo> Read by named:named from the named process and localtime is chmod named:named
[19:40] <infinity> Svendo: README.Debian has a pointer to http://www.tldp.org/HOWTO/Chroot-BIND-HOWTO.html
[19:41] <infinity> Svendo: Which should, I assume, hilight the files that need to be copied to the target chroot directory for it to work.
[19:41] <infinity> Svendo: It's not going to magically be able to read anything it can't get at, that's sort of the point of a chroot.
[19:42] <Svendo> Its not getting permission to read its own files in the chroot that is owned by the process owner. Kinda odd
[19:43] <Svendo> Could it be an selinux issue with named running from another directory in /var/named/... ?
[19:44] <Svendo> or /var/bind/...
[19:44] <infinity> If you're running selinux, it very much could be an issue, yes.
[19:44] <Mithrandir> selinux + chroots is teh fail, according to a friend of mine who played with it the other day.  Well, or at least needs a bit of tuning.
[19:44] <infinity> Anyhow, this has gone far beyond a -devel discussion, and is probably more appropriate for #ubuntu
[19:45] <Svendo> Mithrandir: It cant be told to relax permissions so that named can read its own files ? .. wouldnt this make selinux less secure then ?
[19:46] <Mithrandir> Svendo: no idea.  I don't use selinux.
[19:46] <Svendo> since bind cannot be run in a chroot
[19:46] <Svendo> i try to avoid it as much as possible too
[19:46] <Svendo> My trust is with the source ;)
[19:47] <Svendo> Seriously, selinux can probably be good but im seeing the opposing factor
[19:52] <soren> If I have a new package that I'd like to upload, what's the procedure? Should I file an FFe and have it approved before I upload?
[19:53] <soren> ...and then perhaps reference the FFe in the changelog?
[19:53] <ScottK> soren: Generally it's FFe before upload.
[19:54] <Svendo> Mithrandir: If the modules where compiled in like in all other dists, then the ubuntu users would have encrypted sessions.   Can I go ahead and fix that or is there more stuff that you need to upload first?