[00:17] <cjwatson> snow_ru: problems with 64-bit environments are not unheard of, but are rare in Ubuntu in general these days, and rarer still in main
[00:20] <snow_ru> cjwatson, yes, as soon as programmers are aware of the 32 and 64
[00:20] <xorl> snow_ru: they are for the most part, people just get lazy.
[00:20] <xorl> snow_ru: The "new" still scares them even though it's not new tech by any means.
[00:21] <snow_ru> "new"?
[00:21] <xorl> I've been running 64bit since before most supported it.
[00:21] <cjwatson> snow_ru: all one has to do is abide by standards - you generally don't need to special-case them, and usually these days compiler warnings pick up the most common bugs
[00:21] <xorl> snow_ru: yeah, people fear change.
[00:21] <xorl> snow_ru: mostly large corporations.
[00:22] <snow_ru> xorl, many guys still assume they will run on 32
[00:22] <cjwatson> anyway, amd64 (or x86-64, whatever you want to call it) has been a first-class supported architecture on Ubuntu since the project began, so "new" is not particularly relevant.
[00:22] <xorl> snow_ru: exactly.
[00:22] <snow_ru> and do crazy tricks
[00:22] <xorl> I program myself and have to modify all kinds of code.
[00:22] <xorl> working with apps that only support 32bit memory stacks is hell.
[00:23] <snow_ru> xorl, with the assumption of 32, they do very "clever" tricks and it's very hard to figure out
[00:23] <xorl> snow_ru: Oh I find em most of the time.
[00:23] <cjwatson> it doesn't seem like this conversation is directly about Ubuntu - please take general discussion of how programmers suck elsewhere. :-)
[00:23] <xorl> Not very hard to tell crappy math.
[00:24] <xorl> cjwatson: haha, sure deal :)
[00:25] <snow_ru> any statistics on the languages used in the main ?
[00:25] <cjwatson> not that I know of
[00:28] <cjwatson> vast majority will almost certainly be one of C, C++, Perl, Python, with a smattering of various others
[01:01]  * snow_ru wants to apply for ubuntu dev position 
[01:30] <davidvasta> anyone here
[01:30] <davidvasta> ???
[01:49] <psusi> wow... I found an old copy of dd I had modified to use aio and it does 242 MB/s reading my ssd compared to 230 from stock dd with same settings
[01:50] <psusi> iirc, the manufacturer specs only say it does 230
[01:52] <psusi> ohh dear.. make that 247 when I turn ncq back on
[02:27] <slangasek> vvsz-
[02:41] <superm1> nixternal, the fact that you have to ask implies a bug that they aren't voiced correctly to you as the user in jockey
[02:42] <nixternal> well it says sta is preferred
[02:42] <nixternal> the non-free one
[02:42] <nixternal> it doesn't support scanning which sucks
[02:48] <superm1> sure it supports scanning
[02:48] <superm1> iwlist scan?
[04:04] <ccheney> what is the syntax to do in place sed replacement?
[04:04] <ccheney> doh i just need to read better
[04:04] <ccheney> -i does it
[06:24] <slangasek> Riddell, stgraber: any progress on the branding question?
[06:36] <pitti> Good morning
[06:37] <pitti> kees: python> mind to comment on bug 542372 then?
[07:18] <dholbach> good morning
[07:20] <maxb> If I had a bug assigned to me + "In Progress" whilst working on it, am I supposed to unassign myself and put it to another status when I request sponsorship?
[07:40] <slangasek> maxb: the sponsorship queue isn't based on bug status, so I don't think you need to
[07:45] <Jeeves_> Hi all
[07:46] <Jeeves_> If I have a general complaint about Canonical software/packages, where should I drop the complaint?
[07:55] <RAOF> Jeeves_: Bug reports go on Launchpad of course; other comments may find a more appropriate venue, depending on what the actual package is.
[07:57] <Jeeves_> RAOF: Well, it's more a observation about Canonical packages. So I guess it would be more efficient to drop the complaint than to file bugs against all packages. Don't you agree?
[07:57] <RAOF> What packages are you talking actually about?
[07:59] <Jeeves_> pyhton-software-properties, for example
[07:59] <Jeeves_> Packages in the main archive, without manpages.
[08:00] <ogra> Jeeves_, thats definately a bug, file it
[08:00] <Jeeves_> ogra: I have
[08:00] <mvo> Jeeves_: add-apt-repository lacks a man-page. that is correct and a bug. help is much appreciated in fixing it
[08:00] <ogra> great
[08:02] <Jeeves_> mvo: I would expect the developer (you?) to be able to write a manpage in about five seconds. Instead of releasing it without a manpage and sat 'go ahead, fix it. You've got the source'.
[08:02] <Jeeves_> I would expect Canonical to have a quality standard, which says 'We dont release software about which Lintian complains'
[08:04] <mvo> Jeeves_: its a valid complain, but its not always that easy, there are a lot of things to do and a lot of bugs to fix.
[08:05] <Jeeves_> mvo: By creating new bugs, you don't make your work much easier, do you?
[08:06] <mvo> Jeeves_: sorry, I have no interesst in continue a conversation like this. please note that I understand that its a valid complain and I don't like it either, but its not that simple. I don't think its unfair to call in this cases for help from the community (and I'm certain someone will step up and help wit hthat task)
[08:08] <Jeeves_> Ok, so back to my original question. Where can I drop complaints about this, other than at the developers which are to busy?
[08:10]  * pitti suggests /dev/null
[08:10] <pitti> complaints are just about the worst possible way to motivate people
[08:11] <Jeeves_> pitti: Ok, let me rephrase. Whom should I talk to, to motivate Canonical to uphold a quality standard that gives them credit and prevents complaints, and useless bugreports?
[08:12] <pitti> Jeeves_: there are certainly much more pressing bugs which need attention first
[08:12] <pitti> so by putting more resources into things like writing manpages, we had to drop resources from fixing really nasty things
[08:12]  * pitti points to bug 445852
[08:13] <pitti> Jeeves_: but in general, ubuntu-devel-discuss@ is not a bad place to start discussions about the project's direction and workflow
[08:14] <Chipzz> Jeeves_: wow. that's some astouding arrogance there
[08:14] <Chipzz> may I suggest you take it elsewhere?
[08:14] <Jeeves_> Chipzz: I don't recall being arrogant. Explain?
[08:15] <Jeeves_> pitti: That's a nasty bug indeed.
[08:15] <pitti> For starters, you claim that workign on missing manpages should be the #1 priority, without apparently knowing what the project is working on
[08:15] <pitti> and overgeneralize this as if we wouldn't care about quality
[08:15] <Chipzz> "09:02 < Jeeves_> mvo: I would expect the developer (you?) to be able to write a manpage in about five seconds."
[08:16] <pitti> that, too
[08:16] <Chipzz> Jeeves_: and no offence, but maybe it's more important to have something FUNCTIONAL than to have something perfect to the tiniest detail
[08:17] <Chipzz> and yes, I call supplying a manpage a MINOR detail
[08:18] <Jeeves_> Obviously, functionality is more important than documentation. What would you document if it doesn't work?
[08:18] <Chipzz> Jeeves_: you obviously did not consider the fact that canonical has a limited amount of manpower, and a certain amount of goals to reach.
[08:18] <Jeeves_> pitti: I never stated manpages are a #1 priority. I did say that I expect a manpage for professionally written sofware.
[08:19] <Jeeves_> Chipzz: Ofcourse I did.
[08:19] <Chipzz> you obviously did not
[08:19] <Jeeves_> Chipzz: Are there other things I did or did not do without knowing about it myself?
[08:21] <Chipzz> I suspect there are :P
[08:21] <Chipzz> but
[08:21] <Chipzz> obvious troll is obvious
[08:21] <Jeeves_> pitti: I also did not say that canonical doesn't care about quality. The existance of LTS releases proof the opposite, so why would I say that?
[08:21] <Chipzz> one for the /ignore list
[08:22] <Chipzz> Jeeves_: lol. I think you did
[08:22] <Jeeves_> Chipzz: Where, how?
[08:22] <Chipzz> at least the tone of what you said and how you said it implied hat
[08:22] <Chipzz> *that
[08:22] <pitti> Jeeves_: "motivate Canonical to uphold a quality standard that gives them credit and prevents complaints, and useless bugreports"
[08:23] <pitti> we do what we can, and we know Ubuntu isn't perfect. we wouldn't have 50.000 open bugs otherwise
[08:23] <Jeeves_> pitti: That's because you did not approve complaints because complaints are unmotivating.
[08:23] <pitti> so we have to prioritize :)
[08:23] <Jeeves_> pitti: I know it's not perfect, but it is one of the better Linux distributions. And I'm happy with it.
[08:24] <pitti> that's great to hear
[08:24] <Jeeves_> I'm just trying to make a point, that if you write a manpage in a few minutes, it save you a bugreport, it saves you replying to that bugreport etc etc etc
[08:24] <Jeeves_> And, it makes your users even happier
[08:25] <pitti> I agree
[08:25] <Chipzz> Jeeves_: writing a manpage doesn't take 2 minutes
[08:25] <Chipzz> it takes a lot longer than that
[08:25] <pitti> but still, writing a good manpage is not a "5 s" job, it's more like 30 minutes..
[08:25] <Tm_T> Jeeves_: I'm happy to receive manpage contributions from you ;)
[08:25] <Jeeves_> Chipzz: That kinda depends on the piece of software you're documenting, don't you think?
[08:26] <pitti> and more people are able to write manpages, that's why FOSS projects use bug trackers, so that everyone can contribute
[08:26] <Chipzz> pitti: I would estimate that writing the manpage content would take that much. but obviously a manpage also needs layout elements (groff or whatever is used markup)
[08:28] <Chipzz> Jeeves_: I would consider your complaint more valid if canonical were to write closed source software. but most of it is open source, so you can read the source...
[08:30] <Jeeves_> Chipzz: But it's allready released, so too late. And obviously everyone can write a manpage. But by then it allready costs more time and bugs than necessary.
[08:31] <cjwatson> Chipzz: honestly, I don't think your aggressive defensiveness is helping the tone of this conversation.
[08:32] <cjwatson> tone it down, please.
[08:34] <cjwatson> Ubuntu developers can look after themselves and don't need others to defend them from criticism
[08:36] <Chipzz> cjwatson: ok, noted. although I think that Jeeves_' attitude is inappropriate and was reacting to that
[08:37] <Chipzz> cjwatson: I appreciate the work the canonical employees do, which is why I'm "defending them from criticism"
[08:39] <cjwatson> I think Jeeves_ should just file bugs where appropriate; Canonical doesn't have separate quality standards from Ubuntu for Ubuntu development, so it doesn't make sense to make this about Canonical; there is plenty of Ubuntu software maintained by Canonical employees that does have man pages, though doubtless it has different problems instead, nobody's perfect
[08:39] <Jeeves_> Chipzz: Who's says I don't appreciate them? If I would care about it, I wouldn't be critical.
[08:39] <cjwatson> Chipzz: I can't speak for everyone, but I know I would prefer it if you were a little less vigorous. :-)
[08:41] <Chipzz> Jeeves_: you can be critical in a constructive way. but you attitude is hardly constructive...
[08:41] <Chipzz> *your
[08:43] <Tm_T> like I hear often, "complaints are welcome, especially wrapped with patch"
[08:45] <Jeeves_> Tm_T: :)
[08:47] <hyperair> mvo: i'm curious. what are these more complex issues that prevent add-apt-repository from sprouting a manpage? i'm more than willing to spend 5 minutes to write one, but i don't fully understand what add-apt-repository, nor the options it provides.
[08:47] <mvo> hyperair: I'm happy to help you with that, there are no more complex issues really, just someone needs to sit down and do it.
[08:48] <mvo> hyperair: and I'm currenly busy with other fixes that are higher on my priority list
[08:48] <Chipzz> 09:30 < Jeeves_> Chipzz: But it's allready released, so too late. And obviously everyone can write a manpage. But by then it allready costs more time and bugs than necessary. -> bugs don
[08:48] <hyperair> mvo: okay, for starters, what options does add-apt-repository provide?
[08:48] <Chipzz> ugh
[08:49] <Chipzz> bugs don't cost anything, and time... in case a bug is files it doesn't necessarily take up time of a canonical employee, like pitti pointed out, anyone can contribute a manpage
[08:49] <hyperair> you got truncated at "bugs don"
[08:49] <hyperair> ah
[08:49] <Chipzz> hyperair: accidently hit enter. hence the subsequent "ugh" ;)
[08:50] <mvo> hyperair: it takes a single line for the form "deb http://foo.bar.com/ubuntu main universe"
[08:50] <hyperair> Chipzz: ah =p
[08:50] <Jeeves_> Or it can do stuff with ppa:
[08:50] <mvo> hyperair: it also supports a shorthand synatax for PPAs (and possible others in the future)
[08:50] <pitti> hm, and also something like ppa:pitti/postgresql, no?
[08:50] <Chipzz> and now I'll stfu :)
[08:50] <hyperair> pitti: yes, that.
[08:50] <mvo> hyperair: like the line that pitti pasted
[08:51] <hyperair> mvo: options? are there any?
[08:51] <hyperair> -h doesn't document any besides -h
[08:51] <mvo> hyperair: no other options
[08:51] <hyperair> okay then
[08:51] <mvo> hyperair: it needs to run as root (obviously)
[08:52] <hyperair> mvo: right. =p
[08:52] <cjwatson> Jeeves_: the main root problem, if you must make it about Canonical, is that our staff are often overloaded with feature development, and something often has to give.  Personally I usually write man pages first, but then on the flip side I tend not to do enough regression testing, which creates more bugs than forgetting to write a man page
[08:52] <mvo> hyperair: PPAs end up in sources.list.d dir
[08:52] <cjwatson> our internal standards are biased towards regression testing
[08:52] <hyperair> mvo: and other things?
[08:53] <geser> could someone please give-back apr-util? Thanks.
[08:53] <mvo> hyperair: it will get/add keys for PPAs automatically too
[08:53] <mvo> hyperair: I think thats it :)
[08:53] <hyperair> mvo: okay cool
[08:54] <mvo> hyperair: wonderful, thanks a lot! just mail it or attach it to the bugreport
[08:54] <hyperair> mvo: okay, will do
[08:54] <Jeeves_> cjwatson: It's not really about making it about Canonical. More about the 'main' archive, which iirc, is Canonical responsibility because Canonical officially supports it.
[08:55] <hyperair> mvo: er for non-ppa external repositories, where is it put? sources.list or sources.list.d?
[08:56] <mvo> hyperair: to the main sources.list
[08:56] <hyperair> mvo: okay cool
[08:56] <mvo> hyperair: I guess that is something where a "--file=" option would come handy in the future
[08:56] <hyperair> mvo: that would be cool
[08:57]  * mvo adds a FIXME in the source
[09:03] <Jeeves_> hyperair: Thanks
[09:03] <cjwatson> Jeeves_: main does have elevated standards (https://wiki.ubuntu.com/UbuntuMainInclusionRequirements), but currently manual pages are not among them
[09:04] <cjwatson> and, even as the man-db maintainer, I'm not sure that that would make sense in all cases
[09:05] <Jeeves_> cjwatson: I'm ofter curious for a description of a running daemon.
[09:05] <Jeeves_> There's no direct need for extensive texts about options and so on
[09:05] <cjwatson> I'm not saying they shouldn't have man pages - merely saying that I don't think it makes sense to make it a requirement for main
[09:06] <cjwatson> I've probably put more effort into man pages than most people here :)
[09:06] <Jeeves_> cjwatson: I'm not sure if I should be happy with that. :P
[09:07] <cjwatson> but it's not the most important thing
[09:07] <Jeeves_> No, and I never said that
[09:07] <cjwatson> so, in particular, I don't think it would be appropriate to adopt a standard saying that we don't release software about which lintian complains
[09:08] <cjwatson> lintian is a tool to help developers, but many of its messages are inappropriate in certain situations, and the importance of the messages that are appropriate varies
[09:08] <Jeeves_> That's true.
[09:08] <cjwatson> ubiquity produces a stunning number of lintian messages because it's so weird - but very few of those messages relate to the actual bug problems that it has in practice
[09:09] <Jeeves_> Anyways, thanks for your time. Have to go in a meeting.
[09:09] <Jeeves_> ttyl!
[10:29] <bdrung> pitti: let's defer the units policy fixes to lucid+1 (including nautilus).
[10:29] <pitti> bdrung: okay
[10:30] <bdrung> pitti: great. changing half is worse than changing nothing.
[10:30] <pitti> bdrung: well, wrt. nautilus it's already "half" right now
[10:30] <pitti> but yes, we certainly have more pressing bugs right now
[10:31] <bdrung> pitti: yes, but the German translation uses "MiB" for example.
[10:32] <geser> Could someone please give-back apr-util? Thanks.
[10:32] <bdrung> pitti: my current plan is to write a library that can be configured to the users preferences. then we can port all apps to this library.
[10:32] <pitti> geser: done
[10:32] <pitti> bdrung: hm, I'm not sure whether this should really be user configurable, but if the GNOME guys agree with it, fine for me
[10:33] <bdrung> pitti: reading all user comment there should be an option for base-2
[10:33] <pitti> bdrung: ok, so like a gconf key for "geek" mode?
[10:34] <bdrung> pitti: yes, gconf or something similar. the library should work with GNOME, KDE, XFCE, LXDE apps.
[10:35] <seb128> you don't want to add a new library only for that do you?
[10:35] <seb128> using glib seems right there
[10:36] <bdrung> seb128: i think a new library is better, because not every app uses glib.
[10:37] <pitti> a separate lib seems quite overkill to me, too, TBH
[10:37] <bdrung> seb128: there are some glib dev that didn't liked the g_format_size_for_display function. i don't know if they like to have 10+ new functions.
[10:38] <seb128> bdrung, GNOME will not use yet another lib for that details
[10:38] <pitti> units don't need translations, etc. so apps could just do the formatting themselves
[10:38] <bdrung> pitti: but how do you want to have one configuration key to change all apps (including the Qt+ apps you are using in GNOME)
[10:39] <pitti> well, I don't want a configuration key :)
[10:39] <seb128> neither do I
[10:39] <pitti> at most this could be locale specific
[10:39] <bdrung> but many user want
[10:39] <seb128> if you need one get a common configuration and let glib and qt respect this one
[10:39] <pitti> so that "2 kg" becomes "4.1 lb" for our American friends, or so :)
[10:42] <bdrung> seb128: common configuration? does something like this exists?
[10:44] <seb128> bdrung, write a file on disk, both glib and qt should be able to read a file on disk no?
[10:45] <bdrung> pitti: locale specificity does not work. preferring base-2 or base-10 does not depend on the location.
[11:02] <vorlock> hi guys, I'm trying to aply quiet patch for grub but in ubuntu wiki there is advice to change 'quietboot' option to 'quiet' in a patch but I can't find option like this just function called 'quietboot_func', any hints?
[11:42] <hyperair> manpage for add-apt-repository: http://people.ubuntu.com/~hyperair/add-apt-repository.1
[11:42] <hyperair> mvo: what do you think?
[11:42] <pitti> jdstrand: do you have some time to catch up with https://edge.launchpad.net/~ubuntu-archive/+subscribedbugs during your archive day today? there's quite some backlog with approved FFE syncs, and the like
[11:44] <cjwatson> hyperair: newline after the end of each sentence (nearly everyone gets this wrong)
[11:44] <cjwatson> the NAME section is formatted wrongly
[11:44] <hyperair> cjwatson: really?
[11:45] <hyperair> er how should i format it?
[11:45] <cjwatson> .SH NAME
[11:45] <cjwatson> add-apt-repository \- Adds a repository into the /etc/apt/sources.list or /etc/apt/sources.list.d
[11:45] <cjwatson> drop the .B and the two bits on separate lines
[11:45] <cjwatson> "really" to which?
[11:45] <hyperair> nevemrind
[11:45] <cjwatson> ok
[11:45] <hyperair> it was to newline after ...
[11:45] <cjwatson> see lexgrog(1) for documentation of this
[11:46] <cjwatson> ah, that's in 'info groff' somewhere
[11:46] <hyperair> hmm
[11:46] <cjwatson> info groff --index-search Sentences
[11:46] <hyperair> other than those two issues?
[11:47] <cjwatson> those were the two I noticed, I didn't see other serious typesetting issues; not qualified to review the substance though
[11:47] <hyperair> imo we should have a wiki page documenting how to write a proper man page
[11:48] <hyperair> i picked my things up from numerous places
[11:48] <hyperair> cjwatson: okay, updated.
[11:51] <cjwatson> hyperair: personally I recommend groff_mdoc(7) anyway :-)
[11:51] <cjwatson> although that's a different macro set
[11:51] <cjwatson> it's logical markup rather than physical markup
[11:51] <hyperair> hmm i see
[11:52] <cjwatson> invented by the BSD people, so you'll find it in use for e.g. ssh(1)
[11:52] <cjwatson> its only downside at the moment is that it doesn't interact very well with making the man page translatable, or at least I haven't been able to get po4a to cooperate with it
[11:52] <cjwatson> I think that's probably more of a po4a bug though
[11:53] <hyperair> hmm
[11:55] <hyperair> oh hell, they shut down my campus's ubuntu mirror
[11:58] <matumba> hello everyone, i'm having a problem with nouveau not recognizing my CRT (bad EDID) - against which package would i file a bug or which channel should i join?
[12:11] <IntuitiveNipple> What package do I assign bugs to for the PowerPC Alternate installer, suffering SEG faults ?
[12:13] <cjwatson> IntuitiveNipple: default for the alternate installer is debian-installer
[12:13] <cjwatson> (seg is not an acronym, BTW, it's short for "segmentation")
[12:14] <IntuitiveNipple> yeah, I know, I was being economical with keystrokes
[12:14] <IntuitiveNipple> Would you happen to know of a resource that might help me catch and debug the segfault? As it's running from the alternate CD its a bit basic!
[12:16] <cjwatson> IntuitiveNipple: usually it's bloody hard :-)
[12:17] <cjwatson> IntuitiveNipple: the dmesg should at least say which process is segfaulting
[12:17] <cjwatson> sometimes situational analysis is enough, or if it's late enough in the installer then you can 'anna-install strace-udeb' and try to get a strace
[12:18] <IntuitiveNipple> on tty4 I can see the syslog output that just says "segmentation fault". I've just found https://wiki.ubuntu.com/Installer/FAQ#How%20do%20I%20debug%20the%20installer? which suggests using strace
[12:18] <IntuitiveNipple> It's during the base-install phase - and I've already verified the CD is free of errors
[12:18] <mvo> hyperair: thanks! I have a look now
[12:19] <IntuitiveNipple> it seems to repeatedly happen as packages are unpacked
[12:20] <IntuitiveNipple> cjwatson: dmesg doesn't report the faulting process. I'll have to figure out this strace method
[12:22] <jdstrand> pitti: yeah, I was planning that today
[12:26] <mvo> hyperair: looks good, many thanks. added to bzr
[12:35] <pitti> jdstrand: thank you
[12:38] <IntuitiveNipple> cjwatson: It's writing stack-traces of seg-faults to tty1; into the ncurses-style windows so its all over the screen. Is there any way to separate that so it can be captured?
[12:40] <cjwatson> IntuitiveNipple: the kernel is just writing that to the foreground console, I think.  your best hope is probably to boot with DEBIAN_FRONTEND=text and hope it reproduces with that frontend
[12:41] <IntuitiveNipple> cjwatson: Thanks, I'll try that later. What is weird is, the installer does seem to be making progress beyond the base-install, it's now asked for user details and is fetching stuff from the mirrors *fingers crossed*
[12:41] <IntuitiveNipple> I'll capture the syslog into USB key so it can be added to a bug report
[12:43] <IntuitiveNipple> cjwatson: Interesting: just seen an "Illegal instruction" report in syslog whilst setting up language-selector-common. Can you recommend someone I can talk to who knows about the PPC port?
[12:46] <ttx> jdstrand: planning to do some syncs today ? i'd need bug 543443 to be covered soon
[12:46] <jdstrand> ttx: yes I am
[12:46] <ttx> jdstrand: cool :)
[12:47] <jdstrand> ttx: can you or kirkland respond to my email regarding libvirt 0.7.7 (sent to kirkland, cc'd you and ubuntu-server so it might have gotten filtered somewhere)
[12:48] <ttx> jdstrand: yes, it's on my TODO list
[12:48] <jdstrand> cool, thanks
[12:48] <ttx> jdstrand: still catching up, been at a conference those last days
[12:48] <jdstrand> ttx: no worries, I just wanted to make sure people saw it :)
[12:49] <ttx> jdstrand: nothing can escape my GTD system, resistance is futile
[12:49] <jdstrand> hehe
[12:49] <cjwatson> IntuitiveNipple: it used to be me, but it's been years; it sounds like something is miscompiled, but I don't know who you'd talk to
[12:50] <IntuitiveNipple> cjwatson: OK, thanks, I'll poke about a bit. It's a G3 iMac I thought would be useful for testing! Runs OSX 10.4 nicely though
[13:01] <ev> Just to confirm, Xubuntu 10.04 is *not* an LTS release, correct?
[13:02] <charlie-tca> wrong
[13:02] <charlie-tca> xubuntu 10.04 is an lts
[13:02] <ev> charlie-tca: okay, thanks a bunch!
[13:02] <charlie-tca> no problem
[13:03] <charlie-tca> 8.04 was also an LTS for xubuntu
[13:14] <ttx> jdstrand: about libvirtn read and commented
[13:14] <ttx> s/n/,/
[13:22] <jdstrand> ttx: thanks! :)
[13:26] <pecisk> hi people know, does libsoup respects GNOME proxy settings?
[13:26] <pecisk> jeesh that came out wrong
[13:43] <primes2h> crimsun: Hello, if you need help and info about bug 400682 just ask me.
[13:43] <primes2h> crimsun: I mean on the Lucid side
[13:51] <Jeeves_> mvo: Thanks for the fix
[13:52] <mvo> Jeeves_: cheers, credits go to hyperair for writing it
[13:52] <Jeeves_> !hyperair++
[13:52] <hyperair> =)
[13:52] <Jeeves_> dumb bot :)
[13:52] <hyperair> it's only in #ubuntu-mirrors i think
[14:26] <ScottK> bdrung: I think upstream is really the right place to be dealing with the units issues and so now is the time to work on it for 10.10.
[14:31] <bdrung> ScottK: and what to do with not-glib applications?
[14:32] <ScottK> I think KDE already complies (at least KDE4 apps).
[14:32] <ScottK> It's a matter of evangelizing upstreams about the issue and choosing which are most important.
[14:43] <kees> micahg: any luck finding the thing that causes middle-button-pastes to disappear from my config every time I start firefox?  :)
[14:44] <bdrung> ScottK: with a separate library we can go to XFCE, LXDE, and so on and ask them to use this library.
[14:45] <ScottK> Presumably.  I'm not sure what the best approach is, but I think Ubuntu carrying a permanent difference from upstream on this topic is bad on many levels.
[14:45] <micahg> kees: sorry, not yet...probably will not get to this cycle unless you think it's really pressing
[14:47] <kees> micahg: that'll be a regression -- asac fixed it in earlier versions before.
[14:47] <micahg> kees: ok, do you have the bug handy, we should target for lucid then
[14:53] <snow_ru> yes
[14:53] <bdrung> ScottK: i want upstream to use the library. carrying a permanent diff is not a solution
[14:59] <kees> micahg: bug 548866
[14:59] <micahg> kees: I found bug 535465
[15:00] <kees> micahg: ah-ha yes
[15:00] <micahg> I'm trying to find where it was fixed in teh past though...
[15:01] <jjardon> Hello, Could combody take a look to this bug: https://bugs.launchpad.net/ubuntu/+source/gtk-doc/+bug/526794
[15:01] <jjardon> gtk-doc version in lucid is 1.11, but seems that 1.13 is available
[15:02] <jjardon> in launchpad
[15:02] <kees> micahg: I assume it's related to the changes from 1.5.dfsg+1.5.0.1-1ubuntu1 "Change various preferences: middlebutton paste disabled"
[15:03] <kees> micahg: but I can't find where asac fixed it.
[15:03] <asac> in xulrunner iirc
[15:04] <micahg> asac: kees: found it
[15:05] <kees> micahg: cool!
[15:05] <kees> micahg: I duped the older bug to 548866 since mine has a "reproducer"
[15:06] <micahg> kees: great, I'll test the patch and commit as soon as we know that 3.6.2 is clear
[15:07] <asac> micahg: i think to test you need to touch .autoreg and maybe change the version in application.ini
[15:07] <asac> micahg: e.g. to simulate upgrade
[15:07] <ccheney> doko: ping bug 417009
[15:08] <ccheney> NCommander: is one of the buildds buggy? i heard 4ubuntu1 failed but didn't see how before it was retried and worked, now 4ubuntu2 fails as well, not sure if it is the same way
[15:08]  * kees hugs micahg
[15:09] <ccheney> NCommander: and/or the same machine
[15:10] <doko> ccheney: ?
[15:11] <ccheney> doko: i can't find reference to the jaunty stuff in the copyright file, but maybe i am misreading it?
[15:11] <ccheney> doko: also 4ubuntu2 which didn't change anything relevant is failing to build with segfault, should that just be retried?
[15:11] <ccheney> doko: i think probably 4ubuntu1 did as well but it was retried before i saw what caused the failure
[15:12] <doko> looks it is removed in 1:3.2.0-4ubuntu2
[15:13] <doko> it's the usual buildd failure on armel. these are not reproducible locally unfortunately
[15:14] <ccheney> well i didn't remove it in 4ubuntu2 as you can see in the debdiff, not sure why it showed up for you under 4ubuntu1 :)
[15:14] <ccheney> doko: ok
[15:34] <emgent> hello
[15:34] <emgent> cjwatson, urgent ping
[15:51]  * iulian has tried to install Lucid Beta 1 on his laptop and failed. :-(
[15:51] <iulian> All I got on my screen was this http://people.ubuntu.com/~iulian/DSC05679.JPG.
[15:53] <nigelb> pitti: got a few minutes to help out with that cheese hook?
[15:53] <nigelb> It opens up, but the debug does not get saved
[15:54] <nigelb> correction, the debug gets saved, but not attached
[16:00] <cjwatson> pitti: bug 432631 is on the foundations list for the release meeting, but AFAICS all the rest is either desktop or assigned to you.  slangasek asked whether the remaining tasks still needed to be fixed for lucid.  Could you comment?
[16:07] <GrueMaster> crimsun: ping - I tested your fix to pulseaudio for dove HP select switch, and it doesn't work as expected.  It only adds the switch to the mute button in the sound-applet.
[16:07] <pitti> cjwatson: right, that's on our list now
[16:12] <crimsun> GrueMaster: hmm, make it a port
[16:12] <GrueMaster> ???
[16:13] <GrueMaster> Before we release a new version of pulse for this issue, lets make sure we have a completely working solution.
[16:14] <crimsun> GrueMaster: switch = select, then enumerate the options
[16:15] <GrueMaster> Ok.
[16:18] <emgent> hello
[16:18] <emgent> cjwatson, up ?
[16:18] <emgent> seems that deboostrap have some turbles
[16:19] <cjwatson> emgent: I'm here, but it would help if you gave me all the detail up-front rather than saying "urgent ping" and then quitting
[16:19] <cjwatson> makes it rather hard to actually respond to you
[16:20] <emgent> deboostrap seems faild always (lenny && ubuntu 9.10) after the packages download, with error: W: Failure trying to run: chroot /home/chroots/1 mount -t proc proc /proc
[16:21] <emgent> if you try to mount chroot by hands, skipping the mount apt-get is not avail, and also if you try to install it via dpkg and /var/cache/apt/archives/, show some lib perl errors
[16:22] <emgent> debootstrap --arch amd64 lenny /home/chroots/1 http://debian.fastweb.it/debian
[16:22] <emgent> cjwatson, take a look.
[16:23] <cjwatson> no, I'm not going to debug it with that level of detail, sorry
[16:23] <cjwatson> "some lib perl errors"
[16:24] <cjwatson> I can't run that command myself, I'm on i386 here, and I'm certainly not going to run debootstrap off a random mirror I don't know
[16:24] <emgent> -.-
[16:25] <emgent> cjwatson, what you prefer.. but anyway debootstrap is broken.
[16:25] <emgent> and you are the maintainer, np for me.
[16:26] <soren> debootstrap is run thousands of times each day on thousands of different systems in dozens of different contexts and varieties.
[16:27] <soren> I'm not saying you're lying, but you're clearly using it in a special way that makes it fail, so providing more detail on what exactly you're doing would probably be a good start.
[16:27] <soren> emgent: ^
[16:28] <sistpoty|work> actually debootstrap is broken on lenny for unstable, iirc due to Build-Essential flags, which results that apt is not available. maybe that's connected to the problem your seeing?
[16:28] <soren> emgent: If debootstrap was just plain proken, noone (in their right mind) would be able to install Ubuntu.
[16:28] <emgent> sistpoty|work, yes i think so
[16:29] <emgent> sistpoty|work, i found the same problem in lanny and ubuntu 9.10, 8.04
[16:29] <emgent> s/lanny/lenny/
[16:31] <emgent> sistpoty|work can you provide the bug id in debian tracker ?
[16:32] <sistpoty|work> emgent: sorry, can't find it right now
[16:32] <emgent> ok np
[16:32] <cjwatson> emgent: feel free to file a bug with full logs.  but if you just turn up, yell at me on IRC, and don't provide enough detail, I can't help you.  sorry
[16:34] <emgent> will do.
[16:39] <snow_> cjwatson,
[16:40] <dmart> emgent: Your chroot failure could be caused by not running as root, or typing to bootstrap an arch which can't run natively on the machine running debootstrap (in which case you would need --foreign).  I take it these aren't the problem/
[16:40] <dmart> s/typing/trying/
[16:52] <Keybuk> cjwatson, slangasek: there will be a slight delay to plymouth testing
[16:52] <Keybuk> I got an assertion error
[16:52] <emgent> dmart, stop to dream.
[16:52] <Keybuk> and hurled the netbook out of the window in fury
[16:53] <Keybuk> and some wild marmosets ate it
[17:18] <Keybuk> hmm
[17:18] <Keybuk> here's one of those things I wish I knew
[17:19] <Keybuk> when you compile source with debugging, gdb prints the source as you trace
[17:19] <Keybuk> ... how does it know where the source code is?
[17:22] <zyga> hello
[17:27] <jjardon> Hello, Could combody take a look to this bug: https://bugs.launchpad.net/ubuntu/+source/gtk-doc/+bug/526794
[17:27] <jjardon> gtk-doc version in lucid is 1.11, but seems that 1.13 is available too
[17:27] <zyga> does anyone know if alice paul uses IRC or is around here somewhere/
[17:27] <sistpoty|work> Keybuk: http://en.wikipedia.org/wiki/DWARF for a start? ;)
[17:28] <Keybuk> yes, I know that bit
[17:28] <Keybuk> but when you move the source, I've never figured out how to tell gdb it's moved
[17:28] <Keybuk> not properly anyway
[17:28] <Keybuk> not without gdb getting confused that there's 8 different files called plugin.c
[17:28] <cjwatson>    In addition to the source path, GDB provides a set of commands that
[17:28] <cjwatson> manage a list of source path substitution rules.
[17:28] <cjwatson> is that what you're looking for?  I've not used it myself ...
[17:28] <zyga> Keybuk: does the debug data contain relative source pathnames?
[17:28] <Keybuk> cjwatson: no, that never seems to work
[17:28] <cjwatson> 'set substitute-path', apparently
[17:29] <cjwatson> ah
[17:29] <Keybuk> cjwatson: ooooh
[17:30] <Keybuk> and, of course, the info file I was reading was from gdb 4.17
[17:30] <Keybuk> so no wonder it didn't mention it
[17:30] <cjwatson> what mausoleum were you looking in? :-)
[17:30] <cjwatson>        gdb | 6.4.90.dfsg-1 |     oldstable | source, alpha, amd64, arm, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc
[17:30] <Keybuk> just google
[17:31] <Keybuk> "info gdb" on Ubuntu gives you the dbm info page
[17:31] <cjwatson> really?  works for me
[17:31] <Keybuk> which is Not What I Was Looking FOr
[17:31] <cjwatson> oh, you might need gdb-doc
[17:31] <Keybuk> ahh
[17:31]  * Keybuk is having a fail day, clearly
[17:31] <zyga> mvo: hello, did you manage to run the script I sent you on the mirror?
[18:07] <Damascene> hello, I wonder about the "Generate dowload script" of Synaptic
[18:07] <Damascene> it's really a good feautre but it miss one thing.
[18:08] <Damascene> it should be able to generate update script
[18:08] <Damascene> so user can genreate update script then chose what programs and updates he want to install then he generate download script
[18:10] <Keybuk> cjwatson: ahja
[18:11] <slangasek> Keybuk: would another set of eyeballs be of any help to you this evening?
[18:11] <Keybuk> set substitute-path /tmp/buildd/plymouth-0.8.1 plymouth
[18:11] <Keybuk> :D
[18:11] <slangasek> (for looking, not for feeding to marmosets)
[18:11] <Keybuk> slangasek: a set of eyeballs that can look at the bugs I haven't
[18:11] <Keybuk> e.g. that plymouth/sendsigs bug
[18:11] <Keybuk> that should be a nice one to debug for somebody
[18:11] <Keybuk> it's easy to replicate
[18:11] <slangasek> is it? I haven't replicated it yet
[18:11] <Keybuk> and just needs decent triage to go "aha!"
[18:11] <Keybuk> slangasek: happens to me most reboots
[18:12] <slangasek> which is why I haven't tackled it
[18:12] <slangasek> yah, I haven't seen it *at all*
[18:13] <exco> any news on poulsbo @lucid?
[18:13] <Keybuk> slangasek: try changing renderer plugin?
[18:13] <Keybuk> I think I see it more with text
[18:13] <exco> there are quite some devices out ther with that us15w chipset right now ... and some particularly nice one in the near future ;-)
[18:14] <slangasek> ok
[18:14] <Keybuk> slangasek: mountall-wise
[18:14] <Keybuk> I know of "one" bug with mountall
[18:14] <Keybuk> when it does the whole boredom thing (and fsck failure, etc.)
[18:14] <Keybuk> rather than writing the message, then going back to the main loop
[18:14] <Keybuk> it basically blocks for input
[18:14] <Keybuk> this means you get
[18:14] <Keybuk> Waiting for /porn [SM]
[18:14] <Keybuk> when in reality, /porn just took a second or two more to actually appear
[18:14] <Keybuk> (or was waiting for you to type your passphrase)
[18:15] <Keybuk> so that message should just vanish
[18:15] <Keybuk> what I don't know is, how many of the "MOUNTALL TOOK A CHAINSAW TO MY LVM! I'M USING GENTOO NOW!" bugs are just dups of that
[18:15] <Keybuk> ie. in reality, mountall worked "fine" it just got bored too quickly
[18:15] <Keybuk> and once it was bored, didn't give them the option to try again
[18:15] <slangasek> hmm, mountall may be too large of a context switch for me today; but I'll see what I can do on that after I clear my own critical stuffs
[18:17] <Keybuk> or you could help smoser debug his fog problem
[18:19] <slangasek> Keybuk: yep, will try to pick from that list as time allows
[18:19] <cjwatson> Keybuk: FWIW I asked barry to look into the mountall/LVM bug; it may take him a little while to get started as it's not particularly his area
[18:20] <slangasek> Keybuk: though more immediately, I was really asking whether you thought a fresh perspective would be of any help with your plymouth woes - guess not :)
[18:20] <Keybuk> slangasek: oh, no, not really
[18:20] <Keybuk> it's just fixing-one-bug-reveals-another
[18:20] <Keybuk> and the cost of all the reboots and gdb traces and stuff to find them
[18:21] <Keybuk> and the interruptions on IRC, of course
[18:23] <Damascene> https://bugs.launchpad.net/ubuntu/+source/synaptic/+bug/251378
[18:23]  * cjwatson wishes once again that /var/log/partman were timestamped
[18:23] <Damascene> I'v reported this old time ago
[18:26] <GrueMaster> crimsun: I'm not getting very far with pulse audio.  In the Sound-applet->preferences window under the Output tab, it has a connector window for selecting "Analog Headphones" or "Analog Output".  So far, anything I create in /usr/share/pulseaudio/alsa-mixer/paths/analog-output-headphones.conf works when I select Analog Headphones.  Adding a switch=select and options for it creates additional entries in the connector window (i.e. "Analog
[18:27] <GrueMaster> What I really want is to enable the switch in Analog Headphones (done), and disable the switch in Analog Output (how?).
[18:27] <Keybuk> slangasek: and I'm hesitant to upload anything
[18:27] <Keybuk> because then I'll just get a zillion bug reports about the new bug
[18:28] <Keybuk> and a thousand people uninstalling plymouth again
[18:28] <Keybuk> and it'll take me so long to get through them
[18:28] <Keybuk> that I'll have lost the time I could have been fixing them
[18:29] <ScottK> Sounds like robbiew needs to hire a bug wrangling minion for you.
[18:29] <robbiew> oh man...don't get him started
[18:29] <slangasek> Keybuk: what is the new bug?
[18:30] <Keybuk> slangasek: "could not write bytes: broken pipe" on screen, no visible shutdown screen
[18:30] <slangasek> ok
[18:30] <Keybuk> may cause machine not to shut down at all
[18:31] <Keybuk> curiously, in this state, it replicates that sendsigs bug every time too <g>
[18:31] <slangasek> ah, then I should evidently update from bzr :)
[18:31] <Keybuk> bzr is buildable and installable
[18:31] <Keybuk> -r 1277 will give you a pre-release 0.8.1-1
[18:31] <Keybuk> just has bugs
[18:32] <Keybuk> (which I think I has fixed :D)
[18:32] <Keybuk> 1277 may have been the bug fix I needed
[18:32] <crimsun> GrueMaster: currently in conference, will have free time in an hour
[18:32] <GrueMaster> k
[18:34] <slangasek> Keybuk: btw, I'm trying to resolve several of the "passphrase display is goofy" bugs; I think the right way to fix this is to keep the passphrase prompt down in the same spot as the keys: message, and put the entry box below that, but then we don't fit on anything shorter than 1024x768 - if I scoot the text boxes up across the board on shorter displays, will I be lynched by the design team?
[18:34] <slangasek> (should I clear the change with them first before committing?)
[18:34] <Keybuk> no ;)
[18:34] <Keybuk> just move them around
[18:34] <slangasek> ok
[18:35] <Keybuk> right
[18:35] <Keybuk> if you build from bzr
[18:35] <Keybuk> and you install plymouth, libplymouth2, plymouth-x11 and plymouth-theme-ubuntu-text *only*
[18:35] <Keybuk> you should replicate the sendsigs issue :p
[18:35] <slangasek> ack, will test :)
[18:36] <Keybuk> not all of the time, but some of the time, mind you
[18:37] <Keybuk> interestingly I always see the "could not write bytes" and "terminated by KILL" together
[18:40] <Keybuk> I think this version is "good"
[18:40] <Keybuk> it's at least no worse than what we had before
[18:40] <Keybuk> except mostly no console messages, and vga16fb, etc.
[18:41] <Keybuk> though I'm pretty sure the ubuntu log is wandering off to the right of the screen :p
[18:42] <Keybuk> logo
[18:48] <jdstrand> bryceh: hi, what is going on with wacom-tools? it is in source NEW for lucid. seemed it was dropped from the archive for lucid
[18:48] <jdstrand> s/seemed/seems/
[18:51] <tjaalton> jdstrand: should be removed from the queue
[18:52] <Keybuk> slangasek: could you handle NEW for me
[18:52] <Keybuk> slangasek: the intent is that only plymouth-theme-ubuntu-* are in main
[18:52] <Damascene> could I find syanptic developer here?
[18:53] <jdstrand> tjaalton: thanks
[18:54] <slangasek> Keybuk: sure, looking
[18:54] <Keybuk> slangasek: it'll need to build first I guess, they're new binaries
[18:54] <slangasek> oh, well then
[18:54] <slangasek> yes, in theory I can handle that when they arrive :)
[19:36] <hyperair> jdstrand: banshee-extension-* source packages are meant to be deleted and superseded by b-c-e. i meant to request their deletions after b-c-e was accepted. was my ordering wrong?
[19:38] <jdstrand> hyperair: it isn't that it is out of order, I just think that the whole plan should be in the bug and ACKd so we can do it all in one go
[19:42] <andersk> Does anyone know why 534843 got marked Incomplete?
[19:42] <andersk> bug 534843
[19:45] <jdstrand> andersk: I do. it was your comments #4 and #5 that made it unclear for how ubuntu-archive should proceed
[19:46] <andersk> I think ubuntu-archive should just do the sync; it is only bugfixes.
[19:47] <jdstrand> andersk: if someone from ubuntu-release can comment and mark the bug back to Confirmed with all the necessary ACKs, then we can do that
[19:48] <andersk> Is ubuntu-release going to look at a bug that’s marked incomplete?
[19:49] <jdstrand> andersk: ubuntu-release is subscribed. you can ask them in the bug for a on whether a FFe is required/granted
[19:49] <jdstrand> s/for a/
[19:49] <andersk> Okay, I’ll try that.  Thanks.
[19:49] <jdstrand> np
[19:58] <hyperair> jdstrand: ah okay.
[19:59] <hyperair> jdstrand: so i should document everything and reupload?
[19:59] <jdstrand> hyperair: no, it is still in NEW
[19:59] <hyperair> jdstrand: it says rejected.
[19:59] <hyperair> jdstrand: well i got an email saying rejected anyway
[19:59] <jdstrand> hyperair: well, yes, document everything, but don't reupload
[19:59] <hyperair> okay
[19:59] <jdstrand> hyperair: I rejected ubuntu1
[20:00] <jdstrand> hyperair: ubuntu2 is still there
[20:01] <hyperair> jdstrand: ah okay, thanks
[20:02] <hyperair> jdstrand: okay, i've posted it as a comment.
[20:05] <jdstrand> hyperair: thanks. someone from ubuntu-release can now ACK it and mark it as confirmed, and then we can process it
[20:06] <hyperair> okay
[20:28]  * lamont looks around for an ltsp-literate person... stgraber?
[20:30] <barry> i've been trying to reproduce bug 527666 (mountall hang) but have been unable to.  i am not sure my environment is the same as the reported problem.  i've commented on the bug but if anybody has ideas for other things to try, i'm all ears
[20:33] <fabrice_sp> barry, I was having this same issue with root on real partition and home on lvm
[20:34] <snow_> apps in main are supposed to be under GNU v3 license ?
[20:35] <barry> fabrice_sp: any other partitions, real or lvm?
[20:35] <fabrice_sp> lvm: data and var/chroot
[20:36] <fabrice_sp> no other real partition
[20:36] <barry> fabrice_sp: swap on lvm?
[20:36] <fabrice_sp> yes
[20:37] <fabrice_sp> (IIRC: I had to reformat everything since then)
[20:37] <barry> fabrice_sp: okay, so... real: root; lvm: swap, home, data, var/chroot
[20:37] <fabrice_sp> yes
[20:38] <barry> fabrice_sp: ok, thanks.  was this on a vm?
[20:38] <fabrice_sp> no: on a real desktop
[20:39] <barry> fabrice_sp: okay, thanks.  i have only vms available atm, but i'll give that a shot and try to dig up a machine to try this on
[20:40] <barry> fabrice_sp: just curious, was this 32bit or 64bit, single proc or multi?
[20:41] <qense> Plymouth maintainers/developers: thank you for the great release that just landed in Lucid!
[20:47] <ScottK> snow_: No.
[20:47] <snow_> ScottK, !!
[20:48] <snow_> wonder why launchpad, not googlecode !!!
[20:48] <ScottK> Apps in Main are all under free licenses, but that's a lot more than GPL V3.
[20:48] <ScottK> If you look at Launchpad you'll find it does a lot of things that googlecode doesn't.
[20:50] <snow_> code reviews
[20:50] <Damascene> hello, could you provide a package that will install the files /var/lib/apt/lists/
[20:59] <geser> that won't work as that are the files which tell apt which packages are available (and those lists are updated hourly for the development release)
[21:03] <randomaction> Thanks to whoever has given back failed builds of apr-util.
[21:04] <geser> I asked and pitti pressed the buttons :)
[21:24] <slangasek> Keybuk: incomplete update-alternatives conversion?: /usr/share/initramfs-tools/hooks/plymouth: 39: /usr/sbin/plymouth-set-default-theme: not found
[21:27] <slangasek> Keybuk: ah right, because that hook's not used by default :-)  I'll clean it up
[21:29] <sistpoty> Keybuk: when an upstart job should wait for network to be available, is the patch provided at bug #522509 the correct procedure, or is there a more general approach than waiting for eth0?
[21:30] <ScottK> Not all systems have an eth0
[21:30] <slangasek> sistpoty: nope, that patch is wrong
[21:30] <slangasek> sistpoty: in fact, *both* start conditions are wrong
[21:30] <slangasek> it needs to be 'start on filesystem and net-device-up IFACE!=lo'
[21:30] <sistpoty> ScottK: that's why I ask, I used to have an br0 then an eth2...
[21:31] <sistpoty> slangasek: thanks for double-checking, do you comment on the bug?
[21:31] <slangasek> sistpoty: yes, was already on my todo list
[21:31] <sistpoty> thanks! (going through the list atm, trying to do my share)
[21:37] <slangasek> Keybuk: so, um.  plymouth doesn't seem to be using the x11 renderer now in my tests.
[21:40] <sistpoty> ogra: looking at bug #542662, I'm completely incompetent: what is a TI OMAP board and how does such a board boot in the first place?
[21:41] <ScottK> sistpoty: It's a new armel subarch.
[21:42] <slangasek> didn't the mobile team's report say those new packages would be deferred to M?
[21:42] <slangasek> Keybuk: ah - apparently this is a pitfall of trying to use the x11 renderer with only the text theme installed ;)
[21:46] <sistpoty> slangasek: sorry, still trying to put things together when reading the relevant FFe's. Hope I'm not causing more harm then benefit :(
[21:50] <slangasek> sistpoty: it's not your fault if they didn't update the bug status appropriately if they mean to defer
[21:51] <sistpoty> yeah, but I could have added one to one, but didn't *g*
 so omap being a bit behind made a late MIR for x-loader and uboot go away
 we will rely on the flash being properly setup for omap this cycle
[21:52] <slangasek> so ... MIR, not FFe
[21:52] <slangasek> dunno what their intent is there, then
[21:56] <Caesar> slangasek: do you happen to know Scott's reasoning behind making service foo status always exit 0?
[21:57] <slangasek> nope, sorry
[21:57] <Caesar> This is going to make managing services with Puppet a little bit of fun
[21:58] <slangasek> didrocks: after recent updates, under metacity my notify-osd windows can no longer be hidden on mouseover - was there anything in the latest metacity upload that would account for this?
[21:59] <slangasek> Caesar: in code I've written that needs to know the status, I've been parsing the output, which is fairly straightforward; in some cases I want to know a PID anyway, and there are cases where plymouth declares the job is 'started' but there's no PID and that's /wrong/...
[21:59] <slangasek> (though always a bug in the upstart job, AFAICS)
[22:00] <Caesar> slangasek: yeah, it just seems a bit dirty to have to scrape the output of service
[22:00] <slangasek> oh, wait
[22:00] <slangasek> 'service'
[22:00] <Caesar> I think I'll cross-post a thread between upstart-devel and puppet-dev
[22:00] <slangasek> that's a bug, then
[22:00] <Caesar> Puppet currently has no native Upstart support
[22:01] <Caesar> But assuming it gets it at some point, I imagine it's going to be wanting to shell out to service, not the legacy init script?
[22:01] <slangasek> 'service' is meant to be an abstraction around upstart jobs and sysvrc scripts, and I expect *its* status command to return a sensible exit code
[22:01] <Caesar> I agree
[22:01] <slangasek> if it has native upstart support, the native upstart command is "status <job>"
[22:02] <Caesar> fwiw, status foo also exits 0 regardless of state
[22:02] <slangasek> yeah; that's just not a design decision that should necessarily pass through to 'service'
[22:03] <Caesar> So you think it's okay for status foo to exit 0 always?
[22:04] <Caesar> Which interface should Puppet use? service or start,stop,status?
[22:04] <slangasek> I don't like it, but I think that's a conversation we'd need to have with Keybuk
[22:04] <Caesar> Yeah
[22:04] <Caesar> I'll do up an email a bit later
[22:05] <slangasek> I have no opinion on which interface you use; obviously if service handles parsing of 'status' output to generate a meaningful exit code, and puppet elects to use 'status' directly, there'll be code duplication
[22:08] <slangasek> didrocks: it seems this is bug #546348; but I'm not sure what component actually changed to cause the behavior change
[22:09] <chrisccoulson> slangasek - gtk changed
[22:09] <chrisccoulson> there's a similar bug about not being able to click through with compositing
[22:10] <slangasek> chrisccoulson: ah, thanks - is there a bug on gtk tracking this?
[22:10] <slangasek> 546650 maybe?
[22:11] <chrisccoulson> slangasek, yeah, that's the one
[22:11] <chrisccoulson> sorry, i was waiting for LP to catch up there ;)
[22:12] <chrisccoulson> i might do a bisect tonight if i have time
[22:13] <slangasek> chrisccoulson: Macslow posted a git commit ID to the bug already
[22:13] <chrisccoulson> ah, ok. i haven't looked at it since this morning
[22:15] <kobrien> so, best ide for deving ubuntu c code?
[22:56] <showard> Hi, I'd like to point some attention to bug #539049 and bug #457688
[22:56] <showard> both are actually the same bug, but one is a SRU and one is a bug fix upload for lucid
[22:57] <showard> we're cherry picking an svn commit from upstream and applying it to the packages
[22:58] <showard> it causes several depending packages to segfault frequently, and has been fixed for a few months. I've recently turned the patches into debdiffs, and would appreciate someone sponsoring the uploads (and a release team member to check out the SRU)
[23:00] <showard> (it has been fixed upstream and in a ppa for testing for a few months). Thank you! There has been a bunch of duplicates and pings on it lately.
[23:07] <slangasek> Keybuk: so, um... plymouth doesn't seem to be working from the initramfs any more; it seems to fall over if /proc isn't mounted
[23:07] <slangasek> (but I can't spot a relevant change in the diff)
[23:11] <Caesar> Is there a known issue with the alternate installer not finding disks?
[23:11] <Caesar> If I search for 2.6.32-17 in the kernel bugs nothing is jumping out at me
[23:13] <slangasek> Caesar: bug #546929
[23:13] <Caesar> slangasek: thanks
[23:16] <cjwatson> speaking of which, could somebody in an American timezone upload debian-installer once linux has built and published on all architectures?
[23:16] <Caesar> Please :-)
[23:16] <slangasek> if I notice it's available and I'm not stuck in initramfs hell at the time, yes
[23:16] <cjwatson> there's a bugfix in bzr, so build from there
[23:16] <cjwatson> should just be dch -r
[23:16] <Caesar> Fun times?
[23:17] <slangasek> now I understand Keybuk's frustrations with plymouth - things are broken that haven't been touched :)
[23:58] <mrooney> james_w: whoa, the GSoC project "Automated optimistic merging and testing of new upstream releases" sounds awesome! I'm sad I'm not a student anymore!
[23:59] <Keybuk> Caesar: err, that's a bug ;)