[04:55] <etate> allo ppl, i'm looking for a package that is apparently supposed to be in a repo, but cannot find it
[04:55] <etate> gwydion-dylan-dev to be precise
[04:56] <etate> by supposed to be i mean "was last year"
[04:59] <ScottK> We've got nothing like that.  In the future, #ubuntu is the support channel.
[05:00] <etate> oh my bad
[05:00] <etate> by "we've got nothing like that", you mean, there isn't a package in the ubuntu repositories?
[05:01] <etate> s/a package/the gwydion dylan package/
[05:02] <ScottK> Searched on qwydion and got nothing.
[05:03] <ScottK> See http://packages.ubuntu.com.
[05:03] <etate> nice, thanks
[06:14] <dholbach> good morning
[07:02] <tjaalton> calc: is OO.org 3.1 planned for jaunty?
[07:13] <tjaalton> Keybuk: heh, the server keyboard doesn't work in premount phase
[07:13] <tjaalton> so that didn't work out
[07:13] <tjaalton> maybe I could use the serial console..
[07:37] <tjaalton> Keybuk: ok, so for some reason it doesn't match the "RUN+=kpartx .." rule
[07:48] <dholbach> ara_: would it be a good idea to get the qa tools into Ubuntu proper? WDYT?
[07:49] <ara_> dholbach: yes, I think it should be a good idea. To do so, it needs a lot of cleaning first ;-)
[07:50] <dholbach> ara_: we're before feature freeze - I think we can handle a few bugs :-)
[07:50] <dholbach> ara_: maybe it makes sense to take a look at ubuntu-dev-tools for the packaging
[07:50] <ara_> dholbach: ok, I'll have a look
[07:50] <dholbach> ara_: let me know how it goes :)
[07:51] <ara_> dholbach: are you sending me homework, teacher? ;-)
[07:53] <dholbach> ara_: I'm really not into teacher games - my dad is a teacher and in the street where I grew up there were lots of teachers and lots of their kids became teachers too, I was really hoping to avoid the same fate :-)
[07:54] <tjaalton> Keybuk: think I got it.. the rule has just %N in it, when it should probably be /dev/%k
[07:54] <ara_> dholbach: don't worry; I have been always good at self-learning, Mr. ;-)
[07:56] <tjaalton> Keybuk: but it still timeouts way too early
[08:08] <tjaalton> the timeout seems to be around 20s
[08:08] <tjaalton> when it took ~1min to probe the SAN
[08:08] <tjaalton> Keybuk: ^^
[08:38] <pitti> Good morning
[08:38] <evand> morning
[08:42] <Hobbsee> hey there pitti!
[08:45]  * pitti hugs Hobbsee and evand
[08:45] <Hobbsee> :)
[08:45] <pitti> tjaalton: btw, I reviewed all Fedora hal patches yesterday, and there was just one tablet related which was relevant and still applied to git head
[08:45] <pitti> tjaalton: feedback appreciated if it works the way you want now
[08:45] <tjaalton> pitti: great, thanks
[08:46] <tjaalton> ogra might want to test it now
[09:04] <nijaba> dholbach: hello.  still no reply from soren, what do you think we should do regarding tonight?  I can prepare to do it alone, but may not have all the answers to questions
[09:06] <dholbach> nijaba: is there anybody else from the server team who might help out?
[09:06] <nijaba> dholbach: sincerely, most of the dev on vmbuilder was done by soren and I
[09:07] <dholbach> nijaba: probably it'd make sense to collect all the questions you don't have answers for, promise answers and do a blog post about it later on
[09:08] <dholbach> nijaba: blogging about vmbuilder would be a good thing anyway ;-)
[09:08] <nijaba> dholbach: ok, sounds like a plan
[09:08] <dholbach> rock on
[09:08] <dholbach> nijaba: thanks a lot for taking care of it
[09:09] <nijaba> dholbach: first time I prepare this type of thing.  I think it makes sense to prepare what you want to say in advance, right?
[09:09] <nijaba> dholbach: so that just mostly do cut and paste during the session
[09:09] <nijaba> (apart for Q&A)
[09:09] <dholbach> nijaba: I usually do it ad-hoc, but I know that a lot of people prepare text in advance
[09:09] <nijaba> dholbach: ok, thanks
[09:10] <dholbach> I think it makes sense to prepare stuff, especially if it's complicated stuff
[09:10] <nijaba> dholbach: preparing in general is not an option, agreed
[09:10] <nijaba> dholbach: I just wanted to know best practice for actual pre made text
[09:11] <dholbach> it's definitely fine to paste in stuff
[09:11] <nijaba> dholbach: then I think that's what I'll start with. thanks
[09:11] <dholbach> thanks Nick
[09:11] <nijaba> np
[10:06] <lool> Keybuk: There's this warning / error when upgrading dbus:
[10:06] <lool>  * Reloading system message bus config...                                       Error org.freedesktop.DBus.Error.Failed: Element <syslog> not allowed inside <busconfig> in configuration file
[10:06] <lool> Or any service doing a dbus reload actually
[10:07] <Unggnu> hi all
[10:07] <lool> Keybuk: My understanding is that the running daemon doesn't know about this new <syslog/> mechanism
[10:07] <Unggnu> Is there a reason why the CD bootloader doesn't show the current Ubuntu version?
[10:09] <Unggnu> I guess it would make sense. The release name would be fine too.
[10:33] <cjwatson> Unggnu: no particular reason; file a bug against gfxboot-theme-ubuntu, please
[10:34] <fabbione> Keybuk: is there a way to cope with this udev stuff without using Break: by any chance?
[10:35] <Unggnu> cjwatson: thx
[10:35] <fabbione> Keybuk: maybe a clever "postinst" that will create the rule file in the right place?
[10:36] <fabbione> Keybuk: it makes it very hard to do backport of the cluster stack to a stable release for testing basically..
[10:40] <andrew_sayers> Hi all, I'm thinking about how to get devs back into ubuntu-devel-discuss.
[10:40] <andrew_sayers> Would there be any value in making a Thunderbird plugin that only showed messages that have been replied to with "+1"?
[10:41] <seb128> not sure the people you try to bring back there use thunderbird ;-)
[10:41] <seb128> and having +1 replies on lists doesn't seem something to encourage
[10:42] <andrew_sayers> I don't know how to hack evolution, and it's easier to play around with ideas in Javascript than Procmail :)
[10:42] <andrew_sayers> I disagree about the +1 thing - I for one am very aware about accusations of noise, but don't feel like a I have a good understanding of what constitutes signal vs. noise.
[10:43] <seb128> why do you want to bring extra people to this list?
[10:43] <seb128> what is the issue you are trying to solve?
[10:43] <Hobbsee> seb128: because it's the list that users are pointed to to communicate with developers
[10:44] <seb128> I for one read the list but I usually don't find discussion really interesting or worth replying that's why I don't post there
[10:44] <Hobbsee> however, the S/N ratio has gotten so bad that most developers either a) never read it, or b) unsubscribe.
[10:44] <BUGabundo> andrew_sayers: do you have any idea how many of them are left, compared to one year ago?
[10:44] <seb128> Hobbsee: that's why we had the -discuss split no?
[10:44] <andrew_sayers> BUGabundo: no, sorry.
[10:44] <Hobbsee> seb128: precisely
[10:44] <seb128> Hobbsee: you are trying to get a -discuss-discuss now?
[10:45] <andrew_sayers> The thing is, I suspect there's going to be a constant chase unless we get some form of moderation.
[10:45] <Unggnu> cjwatson: consider done Bug #319545
[10:45] <Hobbsee> seb128: I thought you were asking about the issue that he was trying to solve, and I thought I answered that...
[10:45] <seb128> andrew_sayers: there is already a moderated list and there is -discuss
[10:45] <andrew_sayers> There will always exist users that think they need a dev, but either don't, or don't know how to ask the question.
[10:46] <andrew_sayers> seb128: Yes, and the moderated list is too restrictive, and the unmoderated list is not restrictive enough.
[10:46] <seb128> get somebody to Cc the moderated list when a discussion is worth it rather than try to create a new moderation system there?
[10:46] <Hobbsee> andrew_sayers: moderating that list too might be a good idea.  I don't think there's a charter for what should be on there, apart from "this is how users can contact developers by mailing list", which should probably change, too
[10:47] <seb128> Hobbsee: you want to moderate that list and create a discuss-discuss not moderated next?
[10:47] <Hobbsee> seb128: halfway there.  Ditch the rest of the traffic to the forums or brainstorm or something.
[10:47] <Hobbsee> or just plain /dev/null it with an explanation.
[10:47] <seb128> there is already a moderated list, what would be the point to have an another one?
[10:48] <seb128> -discuss is for open discussion
[10:48] <Hobbsee> because people can't be trusted to DTRT on the unmoderated one.  OTOH, if they actually *had* a charter for that list, perhaps that would improve.
[10:48] <seb128> if something should be escalated get somebody to cc the other list?
[10:48] <andrew_sayers> One problem with moderation is that it gives the wrong impression, like people aren't invited.
[10:49] <seb128> Hobbsee: well, there is no DTRT there
[10:49] <seb128> andrew_sayers: well, that's why -discuss is where people are pointed and it's not a moderated list
[10:49] <seb128> I'm not sure what you consider the issue there
[10:49] <andrew_sayers> Maybe I should have pointed that comment at Hobbsee :)
[10:49] <cjwatson> Unggnu: thanks
[10:49] <Hobbsee> andrew_sayers: i'd firstly start by finding out what the ideal charter is (as in, what kind of questions / mail should be there), and then getting it written up on the u-d-d list.
[10:50] <Hobbsee> andrew_sayers: indeed.  Although, at the end of the day, they're (unfortunately) right.  Mail that doesn't make the 'cut' as signal mail, rather than noise, is effectively unwelcome, whether it's just ignored, or killed by moderation.
[10:50] <andrew_sayers> Hobbsee: There's a philosophical issue between us here: you're suggesting a pre-hoc set of rules laid down based on logic, I'm suggesting a post-hoc set of rules set down by precedent.
[10:50] <cjwatson> there is a charter for -devel-discuss
[10:50] <seb128> andrew_sayers: it seems that what you are trying to do is to get busy people to read user issues when they don't want to read about those, that's not really a technical issue
[10:51] <Hobbsee> cjwatson: beyond "this is the way for users to contact developers?"  I'll have to go check that
[10:51] <andrew_sayers> Not really - also, I'd like to point out that one dev's signal is another dev's noise.
[10:51] <cjwatson> but I agree with seb128; there is no point in repeatedly moderating previously unmoderated lists in succession, and creating further unmoderated lists as a result
[10:51] <cjwatson> andrew_sayers: I think that's relatively rare actually
[10:51] <cjwatson> Hobbsee: https://wiki.ubuntu.com/UbuntuDevelModeration
[10:52] <cjwatson> or https://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-December/000227.html is a better link
[10:52] <cjwatson> that has the charters for -devel and -devel-discuss both
[10:53] <Hobbsee> hrm, i thought that's what it said.
[10:54] <cjwatson> andrew_sayers: if there is a problem with the -devel moderation being too strict, then maybe that problem would be easier to solve
[10:54] <cjwatson> andrew_sayers: do you have specific examples of problems there?
[10:55] <andrew_sayers> cjwatson: TBH, I don't subscribe to -devel, I'm put off by the moderation and general reputation of it.
[10:55] <Hobbsee> andrew_sayers: not sure on your pre-hoc / post-hoc comment.  Where would you be planning to put the post-hoc set of rules?  How would they be implemented.
[10:55] <cjwatson> general reputation?
[10:57] <andrew_sayers> Hobbsee: Generally, precedent-based systems don't have a written set of rules, you just pick it up as you go along.  That said, I shouldn't be surprised if there ended up with a page on help.ubuntu.com.
[10:58] <Hobbsee> andrew_sayers: right.  The only problem with that sort of situation is that it can be perceived to be biased, and i'm not sure how one goes about solvign that.
[10:58] <cjwatson> andrew_sayers: I think it would be good to have the rules for the list better-known and more clearly-defined (if necessary); I don't think that requires moderation
[10:58] <cjwatson> BTW, the information from the link earlier is at https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss too
[10:58] <andrew_sayers> cjwatson: It's a developer list for people involved in the development of Ubuntu.  I have yet to make a direct contribution to the distro, so it would be kind of like interrupting a private party.
[10:59] <emgent> james_w: ping
[10:59] <cjwatson> andrew_sayers: that's the exact signal/noise thing we were addressing with the list split, though, and the major reason developers pay more attention to -devel than to -devel-discuss
[11:00] <james_w> hi emgent
[11:00] <emgent> james_w: good morning
[11:00] <emgent> james_w: cane you explaine to me this ACK https://bugs.launchpad.net/ubuntu/+source/drupal6/+bug/317337 ?
[11:00] <cjwatson> andrew_sayers: you can't make -devel-discuss magically attractive to developers to read unless you say that only people with the necessary background to form qualified opinions can post opinions :-)
[11:00] <Hobbsee> Ideas and suggestions about future development of Ubuntu  <-- should probably be for brainstorm
[11:00] <emgent> s/cane/can/
[11:00] <andrew_sayers> Hobbsee: Good point, how about changing "+1" to "<ping devs>" or something that sounded less judgemental and more like signalling that devs should be interested.
[11:00] <cjwatson> Hobbsee: not exclusively
[11:01] <andrew_sayers> cjwatson: I disagree.  You do it by having people with said background flag up posts that devs would be interested in.
[11:01] <Hobbsee> emgent: I think you're mistaking drupal6 with drupal5 there
[11:01] <cjwatson> andrew_sayers: why wouldn't such people just move the thread to -devel?
[11:01] <emgent> Hobbsee: the same problem..
[11:02] <Hobbsee> cjwatson: so it should be in multiple places?  I wasn't aware of that, but OK
[11:02] <cjwatson> much simpler than a complex flagging system (remember, please, that developers generally have a favourite mail client and are uninterested in changing)
[11:02] <james_w> emgent: what's the issue with it?
[11:02] <andrew_sayers> cjwatson: aside from the reasons I specified above, they would have to port the whole thread and act as a go-between.
[11:02] <Hobbsee> emgent: then pull the debian version, and make additional changes after that.  There are no ubuntu changes on it currently.
[11:03] <emgent> james_w: ubuntu use postfix in default not exim4
[11:03] <cjwatson> Hobbsee: the correct place for ideas varies wildly - yes, we advertise brainstorm as the main place because that gives us de-duplication and voting and such, but that isn't to say that mailing lists are necessarily inappropriate (or even wishlist bugs)
[11:03] <andrew_sayers> Actually, now I remember my other problem with subscribing to -devel.  If I can only post a reply when I get permission, but you can post one whenever you like, there's a disparity there that could be quite frustrating.
[11:03] <Hobbsee> cjwatson: right.
[11:03] <cjwatson> andrew_sayers: surely not, all that's necessary is to call the attention of developers to it
[11:03] <cjwatson> andrew_sayers: yes, that's why cross-posting between -devel and -devel-discuss doesn't work
[11:03] <Hobbsee> andrew_sayers: excluding the recent fiasco with the desktop screenshots, the u-d list gets moderated pretty quickly, most of the time.
[11:04] <emgent> james_w: can you invalidate bug please ?
[11:04] <james_w> emgent: yes, but we haven't patched every package, and that's not something that has changed in Debian, so we're not making the situation any worse by syncing that package
[11:05] <andrew_sayers> cjwatson: I agree about calling dev's attention, I just disagree about the best mechanism.
[11:05] <emgent> james_w: last drupal version use postifx and IMHO is good to continue this road
[11:05] <emgent> ubuntu decided a standard road with postifx
[11:06] <emgent> so.. why ack wrong sync ?
[11:06] <Hobbsee> emgent: then why not fix the bug, and mark the syncs invalid?
[11:06] <andrew_sayers> There is an evidential issue here.  I'm assuming there's a significant number of people that don't know what signal would look like, or do but don't want to take issues to -devel for other reasons...
[11:06] <james_w> emgent: no it didn't: http://packages.ubuntu.com/jaunty/drupal6
[11:06] <cjwatson> andrew_sayers: nothing that depends on a specific mail client will be viable
[11:06] <andrew_sayers> Would a questionnaire sent to both lists work at all?
[11:06] <Hobbsee> emgent: iirc this was discussed a few weeks ago when I was looking at the queue.  But no one's actually done anything about it.
[11:06] <andrew_sayers> cjwatson: which client(s) do most devs use?
[11:06] <cjwatson> varies
[11:07] <emgent> Hobbsee: ya correct, i mean explaine the problem to bhavani shankar and tel him to make the correct merge
[11:07] <Hobbsee> emgent: where is this policy actually documented.
[11:07] <Hobbsee> s/./?/
[11:07] <cjwatson> you can grep User-Agent headers if you want statistical information; my point is not that you should be hacking on some different client, but that developers use a wide variety of clients and simply hacking one of them is unlikely to be useful. (Also I think the mail client is completely the wrong layer for this anyway.)
[11:08] <emgent> dont remember now, i'm not at home.. but anyway there are a doc in wiki if i remember well
[11:08] <Hobbsee> hrm.  brainstorm got updated.
[11:08] <emgent> and anyway the problem is that drupal is used by loco and more people (see popcon), and it`s creazy change the mailbox deps
[11:09] <emgent> *mailserver*
[11:09] <Hobbsee> emgent: then why wasn't it done months ago?
[11:09] <james_w> emgent: but the drupal6 in the archive won't change
[11:09] <cjwatson> last 1000 User-Agent headers in -devel have alpine, gnus, icedove, IMP, kmail, mutt, pan, squirrelmail, thunderbird
[11:10] <emgent> Hobbsee: someone acked it.. and someone uploaded sync..
[11:10] <emgent> but IMHO it's a big error.
[11:10] <andrew_sayers> cjwatson: Looking on the bright side, that's only one web-based client.
[11:10] <Hobbsee> emgent: then make your changes, rather than complaining about it?
[11:10] <cjwatson> andrew_sayers: I repeat, hacking the mail client won't work
[11:11] <cjwatson> andrew_sayers: perhaps the right answer here is that people reading -devel-discuss who're qualified to say "developers should be paying attention to this" (with good s/n ratio) should also be qualified to file a well-documented bug that will sail through bug triage
[11:12] <andrew_sayers> cjwatson: I don't see how that helps... do you mean something like, if I write 10 good bug reports, I'm allowed to start CCing things to -devel?
[11:12] <cjwatson> huh? no, that's not what I mean
[11:12] <cjwatson> filing a well-documented bug is a way to bring something to the attention of developers
[11:13] <cjwatson> and surely that's the right way to deal with many things on -devel-discuss
[11:13] <andrew_sayers> Ah right.  Many interesting points don't fit neatly into a bug report though.
[11:13] <andrew_sayers> For example, that thing a while back about bugs not getting fixed... it started out as just another flame, then turned into an interesting procedural discussion.
[11:14] <emgent> Hobbsee: correct, i'm olny asking..
[11:14] <emgent> errare humanum est
[11:14] <emgent> s/olny/only/
[11:14] <emgent> james_w: correct? :)
[11:15]  * Hobbsee personally doesn't see the rationale for "this sync is not correct, as it did not follow a piece of documentation somewhere on the wiki, which may, or may not be policy, so the person should be told off", but whatever ;)
[11:15] <james_w> emgent: I'm happy for you to do whatever you want, I don't see why you needed to come to me with it.
[11:15] <james_w> emgent: it didn't change in the sync, and I'm not going to start reviewing the entire package to ACK a sync request.
[11:15] <cjwatson> andrew_sayers: if more things were dealt with that way, then the volume of -devel-discuss could be expected to drop somewhat, making it more appealing to developers to read
[11:16] <james_w> emgent: no-one filed a bug on the issue, no-one fixed the package that is currently in the archive, and it would have been really easy to upload a fix for this after the sync was done.
[11:16] <andrew_sayers> cjwatson: What are your thoughts about a questionnaire?  I've got the time at the minute to put the work into one, and it would help clear up all our assumptions.
[11:16] <emgent> james_w: i only asked why, because for me it`s an error.. dont worry
[11:16] <andrew_sayers> E.g. to what degree this is a problem of education, reputation, ease-of-use, etc.
[11:17] <cjwatson> andrew_sayers: I'm not sure I have any thoughts on a questionnaire
[11:17] <Hobbsee> fwiw, there don't seem to be many bugs on that list now.
[11:17] <cjwatson> except for "please make sure replies don't go to the list" ;-)
[11:17] <james_w> emgent: I make lots of mistakes, but you will have a hard time selling this one as an error to me though. Thanks for catching the issue and doing something about it though.
[11:17] <Hobbsee> it's more random discussion about stuff in ubuntu, and new things
[11:17] <andrew_sayers> Hobbsee: you're referring to -devel-discuss there?
[11:17] <Hobbsee> or at least, that's what my looking at the archives tell me.
[11:17] <cjwatson> andrew_sayers: speaking only for myself, I find that having other people draw my attention to things they think I should be reading doesn't work very well
[11:17] <Hobbsee> andrew_sayers: yes
[11:18] <cjwatson> andrew_sayers: they draw my attention to lots of noise, and dismiss the things I would actually have really wanted to fix with "oh, it's meant to be like that"
[11:18] <cjwatson> (or similar)
[11:18] <emgent> james_w: me too. ;)
[11:19] <andrew_sayers> cjwatson: true.  I think everyone that's ever written a program has experienced that :)
[11:19] <andrew_sayers> cjwatson: Where do you get your best tips then?
[11:20] <cjwatson> andrew_sayers: I cannot give you a single answer to that
[11:20] <cjwatson> andrew_sayers: bug reports, IRC, mailing lists that are low enough s/n to be worth reading, people phoning me up in a blind panic about stuff :-)
[11:22] <andrew_sayers> cjwatson: Fair enough.  Last question then - If I subscribed to -devel and posted a questionnaire (to compare the results with -devel-discuss), would I get booed off stage?
[11:22] <elmo> I can vouch for that last one
[11:22] <cjwatson> andrew_sayers: busy people tend to be extremely reluctant to participate in what they see as "market research"
[11:23] <cjwatson> andrew_sayers: if you wanted to figure out which of the respondents are developers, I would recommend doing that by looking at the membership of the ubuntu-core-dev and ubuntu-dev teams in LP
[11:24] <cjwatson> it may well not be statistically significant, of course
[11:25] <andrew_sayers> And if mailman will give me a list of subscribers, I can at least come up with some rough numbers about the number of devs still on -devel-discuss.
[11:29] <andrew_sayers> Hmm, it won't.  Is there someone I could ask to check the correlation between -devel, -devel-discuss, and those teams?  A couple of numbers wouldn't take much time or violate any privacy.
[11:41] <james_w> emgent: as a bonus I just fixed the other two packages in the archive that still preferred exim
[11:43] <emgent> james_w: thanks for this
[11:44] <james_w> and at the same time making a mistake :-)
[11:48] <emgent> james_w: heheh :-)
[11:54] <directhex> ta seb128
[12:01] <james_w> does the script used to sync pick up the requested version from the bug, or does it take the latest in the requested <that word for unstable,experimental etc. that I've forgotten>
[12:03] <cjwatson> the latest
[12:03] <Keybuk> lool: correct, just ignore it
[12:03] <cjwatson> if you want a specific version, flag it in the subject line
[12:16] <seb128> directhex: you're welcome
[12:26] <directhex> seb128, now only 3 apps (libs is a distinct topic) in ubuntu haven't been transitioned as part of the mono 2.0 transition. one's waiting on a lib in debian NEW, one's waiting on a new mono package.
[12:26] <seb128> directhex: ok
[12:55] <tkamppeter> keybuk, hi
[12:56] <Keybuk> hi
[12:56] <tkamppeter> Keybuk, it is about bug 318262, you have moved it to HPLIP without giving any comment.
[12:56] <Keybuk> that's because I just did an upload
[12:56] <Keybuk> has to be on hplip for lp to close it
[12:57] <tkamppeter> What did you upload?
[12:57] <Keybuk> hplip, obviously
[13:00] <tkamppeter> Keybuk, you uploaded it only some minutes ago?
[13:00] <Keybuk> yes
[13:01] <tkamppeter> This second it came through. Thanks.
[13:02] <Keybuk> that rule should be suitable for upstream
[13:02] <Keybuk> and eventually for inclusion in udev-extras
[13:02] <tkamppeter> Keybuk, as soon as LP has generated the debdiff I will apply it to the Debian BZR, as we are managing the package there.
[13:03] <tkamppeter> Keybuk, you mean HPLIP upstream or UDEV upstream?
[13:03] <Keybuk> HPLIP upstream at first
[13:03] <Keybuk> but a little later on, udev-extras upstream
[13:03] <Keybuk> (which is where we think such "device catalogue" rules will go)
[13:13] <tkamppeter> Keybuk, is there a way to generally make /dev/bus/usb/*/* accessible for "lp" if the device is a printer? Or do we need a list of each and every printer to do this?
[13:14] <tkamppeter> Keybuk, the problem is that soon CUPS 1.4 will get released and its USB backend is libusb-based.
[13:15] <Keybuk> how do you know whether or not the device is a printer?
[13:15] <Keybuk> it's not as if USB has any kind of class information :-/
[13:15] <Keybuk> (well, not one that anyone bothers with anyway)
[13:18] <Laney> Why did I get both rejected and accepted mails for all of my syncs that were processed today?
[13:19] <Laney> "The source audit - 1.7.11-1 is already accepted in ubuntu/jaunty and you cannot upload the same version within the same distribution. You have to modify the source version and re-upload"
[13:23] <seb128> Laney: not sure, I did the syncs the normal way and they seemed to have been synced correctly
[13:28] <directhex> yeah, happened to me too
[13:28] <directhex> didn't wanna bring it up in case i seemed ungrateful
[13:28] <Laney> :O
[13:28] <Laney> I was just raising it incase something went wrong
[13:29] <Laney> seems to have appeared fine though
[13:35] <tkamppeter> Keybuk, somehow the Kernel's usblp module can also detect (and very reliably) whether a USB device is a printer. AFAIK it checks for USB interface class 7 and subclass 1. I use this method also in /usr/share/hal/fdi/policy/10osvendor/10-hal_lpadmin.fdi for the hal-cups-utils. They auto-setup a printer even if the usblp module is not available.
[13:35] <Keybuk> yes, BUT
[13:35] <Keybuk> the usblp module is a driver that operates on USB *interfaces*
[13:35] <Keybuk> USB interfaces to indeed have a class as you describe
[13:36] <Keybuk> and the interface is exposed as /dev/usblpN
[13:36] <Keybuk> you're telling me that CUPS plans not to use USB interfaces at all
[13:36] <Keybuk> but access the USB device in a raw fashion through the raw device access node /dev/bus/usb/XXX/YYY
[13:36] <Keybuk> since that raw device is *one* per USB device, the interface class does not apply
[13:37] <Keybuk> indeed, since it's a raw device, there's no requirement for you to even acknowledge the usb interface specification
[13:37] <Keybuk> if you access the device in a raw fashion, it's up to you to figure out whether it's a printer or not
[13:37] <tkamppeter> So one has to look into the CUPS 1.4 sopurce code to see what the new backend actually does.
[13:38] <tkamppeter> Keybuk, I assume that it polls the IEEE-1284 device ID. If the USB backend does not succeed it is not a printer or so.
[13:40] <tkamppeter> Keybuk, could UDEV do such things or would we need HAL then.
[13:40] <Keybuk> HAL is going away
[13:40] <tkamppeter> HAL is going obsolete? What will replace it?
[13:40] <asac> james_w: http://paste.ubuntu.com/107768/ ... bzr-builddeb version confusion?
[13:40] <Keybuk> udev and DeviceKit
[13:40] <ogra> devicekit
[13:41] <asac> james_w: nevermind
[13:41] <asac> ;)
[13:42] <tkamppeter> Things change quickly, nothing seems to live for more than 2 years, I am wondering why we are still working with CUPS, Foomatic, and Ghostscript.
[13:46] <Keybuk> same reason that scanner stuff stays in a largely broken state
[13:46] <Keybuk> geeks don't use paper :p
[13:46] <ion_> :-)
[13:47]  * pitti hugs his ebook reader
[13:49]  * directhex rolls up an ebook & beats Keybuk with it
[13:50] <asac> doko_: jflex was now promoted. do you have the comments lool made on your radar still?
[13:50] <Keybuk> directhex: don't forget to call me "bitch"
[13:51] <tseliot> lol
[13:51] <directhex> ooo err
[13:56] <asac> doko_: ok created a follow-up bug for the comments and targetted it for jaunty beta (319607) so it doesnt slip through. Thanks.
[14:27] <Keybuk> cjwatson: http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=5f03ed8a56d308af72db8a48ab66ed68667af2c6
[14:27] <Keybuk> this should solve the installer case ;)
[14:35] <cjwatson> Keybuk: perfect, thanks
[14:36] <cjwatson> when is resolve_names == 0?
[15:04] <Keybuk> cjwatson: see the next patch ;)
[15:04] <Keybuk> libudev supports ==0 to mean "resolve names for each event"
[15:05] <Keybuk> so I added --resolve-names=late as well
[15:05] <Keybuk> but did that separately in case Kay decided that he wanted to drop the support for the other
[15:05]  * cjwatson nods
[15:13] <Keybuk> glatzor: watch out for future packagekit releases
[15:13] <Keybuk> it's possible that hughsie may port to the new policykit
[15:15] <glatzor> Keybuk, Thanks for notifying. Which new policykit? I plan to to stick at 0.3.x in jaunty.
[15:16] <mrvanes> anyone any idea why the last hal update segfaults on my personal built 2.6.28.1 kernel and not on jaunty's default?
[15:17] <Keybuk> glatzor: davidkit released 0.90 pre today
[15:17] <glatzor> Keybuk, the later release of Fedora already lead to some late feature additions in previous cycles.
[15:19] <tjaalton> hrm, sounds seems busted.. alsamixer can't find libasound_module_conf_pulse.so
[15:19] <Keybuk> cjwatson: got a moment to be a teddybear?
[15:24] <cjwatson> Keybuk: teddybear? (I have to go out now to take B to his cello lesson, back for the meeting ...)
[15:32] <unstable> Is there a rough feature list for Jaunty somewhere?
[15:32] <Keybuk> need to bounce an idea off someone, and in the process of telling that person about it, work out the solution for myself ;)
[15:37] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek Day 3 to kick off in #ubuntu-classroom in 23 minutes! :-)
[15:42] <mvo> go dholbach go
[15:42]  * mvo cheers
[15:42] <dholbach> mvo: no... seb128 go! :)
[15:42] <mvo> no seb128 here .)
[15:42] <mvo> he ran away!
[15:43] <dholbach> he's up first in 17 minutes
[15:56] <Keybuk> \o/ I now have iPhone reminders for my work calendar
[15:57] <calc> tjaalton: no
[16:19] <Keybuk> tkamppeter: err, why did you change the priority of the hplip rules?
[16:19] <Keybuk> package rules should be 40, see /lib/udev/rules.d/README
[16:19] <tkamppeter> Keybuk, I have overtaken it from upstream, the original rules file had 55.
[16:20] <Keybuk> right, but 55 is wrong ;)
[16:22] <tkamppeter> Keybuk, does 40-xx not say 40 and higher?
[16:22] <Keybuk> no
[16:22] <Keybuk> 40-xx means 40
[16:22] <tkamppeter> Keynuk and rules coming with packages seem to be all < 60 in this file.
[16:22] <Keybuk> basically 40 for everything unless you have a good reason not to
[16:25] <tkamppeter> Keybuk, the last line of the hplip.udev file has a RUN+="<some little shell script for scanner setup>". Is it still 40 then or is it now 85 due to running a program?
[16:26] <Keybuk> you're reading the old REAMDE
[16:26] <Keybuk> the current one has no clause about running programs needing to happen later
[16:27] <Keybuk> unless you need information from the udev db
[16:27] <Keybuk> your file seems pretty self-contained, so it can basically go anywhere
[16:27] <Keybuk> thus 40 ;)
[16:27] <Keybuk> btw, can I just point out that the RUN rule won't work anyway ;)
[16:27] <Keybuk> so it's kinda irrelevant
[16:28] <tkamppeter> Keybuk why does RUN not work? Deprecated? How to replace it?
[16:33] <Keybuk> tkamppeter: read your rule
[16:33] <Keybuk> what does it do?
[16:33] <ion_> keybuk: Want to bounce the idea off me? :-)
[16:35] <Keybuk> tkamppeter: shall I just tell you ? :p
[16:36] <Keybuk> the filesystem is read-only when udev runs
[16:36] <Keybuk> you can't edit config files <g>
[16:36] <Keybuk> and why isn't that support just built-in to sane-backends in the first place ?!
[16:37] <ogra> Keybuk, ugh, no more RUN ? ltspfs kinda relies on that
[16:37] <cjwatson> ogra: does it edit files from a RUN rule?
[16:38] <tkamppeter> Keybuk, when it identifies the device as an HP printer it owner, group, mode and in addition the sane_hpaio env var. And if this var is set, it edits /etc/sane.d/dll.conf and this it actually did for me.
[16:38] <Keybuk> tkamppeter: won't work on boot
[16:38] <Keybuk> also *PLEASE* do NOT set OWNER
[16:38] <Keybuk> really, don't
[16:39] <Keybuk> that's reserved for other rules, just set GROUP
[16:40] <tkamppeter> Keybuk, I have simply taken it from upstream, so that we need not to maintain our own. Setting OWNER upstream has really overdone it as GROUP is enough with the permissions they give.
[16:40] <Keybuk> then upstream is wrong
[16:40] <Keybuk> we can patch it in Ubuntu
[16:40] <Keybuk> bug #319660
[16:41] <Keybuk> bug #319661
[16:42] <Keybuk> bug #319662
[16:42] <Keybuk> tkamppeter: assigned them to you
[16:42] <ogra> cjwatson, it runs scripts that create files
[16:42] <Keybuk> note that Ubuntu's udev is completely pristine
[16:43] <Keybuk> we have no patches to upstream udev
[16:43] <Keybuk> and we only ship the upstream udev rules
[16:43] <Keybuk> without modification
[16:43] <Keybuk> therefore your upstream is also wrong, they should match the default udev upstream
[16:43] <tkamppeter> The Ubuntu package of HPLIP ships a /etc/sane.d/dll.d/hplip which makes sane-backends using hpaio, so if the UDEV rule does not work is no problem.
[16:43] <Keybuk> not the strange configuration of other distributions
[16:43] <Keybuk> tkamppeter: then please drop the RUN rule
[16:47] <Keybuk> tkamppeter: oh, I have yet more bugs
[16:47] <Keybuk> you use SYSFS{...}
[16:47] <Keybuk> that should be ATTR{...}
[16:48] <Keybuk> bug #319665
[16:50] <tkamppeter> As it seems that HPLIP's UDEV file breaks all and everything with current Ubuntu (and probably all other distros which use current UDEV), the best is if you send me your file again, I only merge in the new device numbers and I propose it to upstream. Simply attach it to your bug report.
[16:51] <tkamppeter> Keybuk, I will add an upstream task then and ask them to use the new UDEV rules file.
[16:52] <Keybuk> tkamppeter: if you hadn't had deleted the file I uploaded, you wouldn't need to
[16:52] <Keybuk> I'm sure you can retrieve it from Launchpad
[16:52] <Keybuk> old source packages and builds are made available from there
[16:52] <Keybuk> you probably even have the .dsc and .diff.gz in your working directory
[16:53] <tkamppeter> Keybuk, sorry, I simply followed the policy of taking as much as possible from upstream ...
[16:53] <Keybuk> since assumedly you downloaded it, then deleted the correct file out of it to replace it with your incorrect one
[16:53] <Keybuk> we don't have a policy
[16:53] <Keybuk> we have a policy of fixing upstream of course
[16:56] <Keybuk> cjwatson: so, have an interesting issue
[16:57] <Keybuk> during upgrade of udev, it's probably wise to stop it and start it again after
[16:57] <Keybuk> but because it's an rcS.d script, the start and stop have other side-effects
[16:57] <Keybuk> is adding a start-daemon and stop-daemon option valid?
[16:57] <cjwatson> you've always said that you couldn't really stop/start udev, I thought
[16:57] <Keybuk> well, you can't really
[16:58] <Keybuk> but there's an interesting bug with this particular upgrade
[16:58] <Keybuk> if you cause udevadm trigger to be run, all of your device nodes will lose permissions
[16:58] <Keybuk> now, I'd say it's a bug that anything is doing udevadm trigger at all
[16:58] <Keybuk> but mdz disagrees, and says udev shouldn't fail so badly
[16:58] <cjwatson> perhaps it would be wiser to have a restart-daemon option, to avoid encouraging people to leave udev stopped?
[16:59] <tkamppeter> Keybuk, are the first three lines of the original UDEV rules also broken/deprecated:
[16:59] <tkamppeter> ACTION!="add", GOTO="hpmud_rules_end"
[16:59] <tkamppeter> #SUBSYSTEM=="ppdev", OWNER="lp", GROUP="lp", MODE="0660"
[16:59] <tkamppeter> SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", GOTO="pid_test"
[16:59] <tkamppeter> SUBSYSTEM!="usb_device", GOTO="hpmud_rules_end"
[16:59] <cjwatson> well, /etc/init.d/udev restart calls udevadm trigger :-)
[16:59] <mdz> Keybuk: that's not true, I didn't express an opinion either way about whether it was a bug that udevadm trigger was being run
[16:59] <Keybuk> cjwatson: yes
[16:59] <cjwatson> Keybuk: in general it's certainly valid to add extra custom options to init scripts beyond the standard set
[16:59] <cjwatson> and often useful
[16:59] <mdz> I did say that the system probably shouldn't melt down in this case though
[17:00] <Keybuk> mdz: the only way to make it not melt down is to stop/start the udev daemon
[17:00] <Keybuk> which will cause other bugs
[17:00] <Keybuk> personally I still think we should find out what caused the melt down
[17:00] <cjwatson> I wonder why udevadm/udevd don't have some kind of versioning in the protocol they use to talk to each other
[17:00] <Keybuk> cjwatson: they do?
[17:01] <cjwatson> then why can't you just bump the version and make udevadm refuse to do anything if talking to an older udevd?
[17:01] <Keybuk> because udevadm never knows what udevd it's talking to
[17:01] <Keybuk> udevd knows what version of udevadm it is
[17:01] <Keybuk> but that'd involve patching the udevd already running ;)
[17:01] <cjwatson> it wouldn't
[17:01] <cjwatson> let me explain
[17:02] <cjwatson> if udevd is talking the old protocol, udevadm can carry on and behave as before
[17:02] <Keybuk> "talking" ?
[17:02] <Keybuk> I think you're assuming some kind of full-duplex protocol here <g>
[17:02] <cjwatson> oh
[17:02] <cjwatson> hm, ok, that's unfortunate
[17:02] <Keybuk> it's just a single message sent from udevadm -> udevd
[17:03] <Keybuk> what happened in mdz's case is that the old udevd was still running
[17:03] <cjwatson> you could change the message to one that an older udevd will ignore
[17:03] <Keybuk> and had noted that it's configuration had all gone away
[17:03] <Keybuk> that's ok in of itself
[17:03] <cjwatson> TRIGGER_2 rather than TRIGGER
[17:03] <Keybuk> cjwatson: I can't imagine Kay would accept that patch
[17:03] <Keybuk> actually
[17:03] <Keybuk> I'm being silly
[17:04] <Keybuk> there's no udevadm->udevd contact at *all* in this case
[17:04] <Keybuk> udevadm trigger doesn't contact udevd
[17:04] <Keybuk> it walks sysfs and pokes the kernel uevent node
[17:05] <Keybuk> the problem is that trigger causes the running udev (the old one, with no configuration) to rebuild /dev
[17:05] <Keybuk> since it has no config, it just reverts the whole thing to root:root/660
[17:08] <tkamppeter> Keybuk, is 'ACTION!="add"' and 'SUBSYSTEM!="usb_device"' also deprecated?
[17:08] <Keybuk> tkamppeter: no recent kernel has a usb_device subsystem
[17:10] <Keybuk> cjwatson: of course, now I think about it - the traditional stop in preinst start in postinst won't work either - the installed udev package wouldn't stop
[17:10] <cjwatson> there are two traditions here :)
[17:10] <ogra> so is RUN deprecated ?
[17:10] <ogra> (sorry, had network probs)
[17:10] <Keybuk> ogra: only for you ;-)
[17:10] <tkamppeter> Keybuk, as I want to find a rules set which is best compromise between upstream
[17:10] <ogra> Keybuk, :P
[17:10] <cjwatson> for daemons you don't want to be stopped for very long (and udevd is definitely one such), it's usual to do restart in postinst
[17:11] <Keybuk> tkamppeter: the rules I uploaded are the best ones to be shipped upstream
[17:11] <cjwatson> ogra: Keybuk never said that - he said that you couldn't write to files from a RUN rule
[17:11] <Keybuk> tkamppeter: since they match udev upstream
[17:11] <ogra> cjwatson, ah, then i misunderstood
[17:11] <Keybuk> cjwatson: my concern about the restart in postinst is that it's likely after whatever problem mdz had anyway
[17:11] <tkamppeter> Upstream supports "Linux kernel 2.4.19 and above (2.6.x recommended)." Am I safe dropping usb_device subsystem support then.
[17:12] <Keybuk> tkamppeter: udev doesn't support 2.4.x :p
[17:12] <cjwatson> Keybuk: I don't suppose there's any way to tell what version of udevd is running?
[17:12] <Keybuk> cjwatson: no
[17:13] <tkamppeter> And 2.6.x dropped usb_device entirely already from the beginning?
[17:13] <Keybuk> no
[17:13] <Keybuk> 2.4 doesn't even have /sys
[17:14] <cjwatson> Keybuk: you could divert udevadm in preinst, replace it with /bin/true, and put udevadm back in the postinst
[17:14] <cjwatson> after restarting the daemon
[17:14] <cjwatson> you may vomit now
[17:14] <Keybuk> cjwatson: I _like_ that idea ;)
[17:14] <cjwatson> it's actually sort of elegant in a twisted kind of way
[17:15] <cjwatson> and would cope with all the packages that probably try to use udev while it's unconfigured
[17:15] <Keybuk> indeed
[17:15] <cjwatson> you might want to replace it with something a little bit more sophisticated than /bin/true, of course
[17:15] <Keybuk> surely you'd want packages that were trying it on to fail anyway?
[17:15] <cjwatson> it would be nice if it still passed through info
[17:16] <cjwatson> I'm not sure - but you get the general idea I think
[17:17] <cjwatson> I expect that a number of packages are avoiding dependencies on udev for one reason or another
[17:17] <cjwatson> (mostly bogus in Ubuntu)
[17:17] <cjwatson> there is a wider problem here
[17:17] <Keybuk> wider problem?
[17:17] <cjwatson> lots of packages have conditional-use idioms in their maintainer scripts - i.e. "use this feature if it is present"
[17:18] <cjwatson> there is no way to check "use this feature if it is present and the corresponding package is configured"
[17:18] <cjwatson> the lack of this has caused a number of really rather fun upgrade problems of late, particularly around perl, but also elsewhere
[17:19] <cjwatson> by diverting udevadm, you'd be simulating this feature by force :)
[17:21] <tkamppeter> keybuk, I have attached an udev rules file to propose to upstream to bug 319660, WDYT, is it OK?
[17:23] <tkamppeter> keybuk, I hope this works with all 2.6.x kernels, has nothing deprecated concerning UDEV and also not rules which are not working on boot.
[17:24] <Keybuk> tkamppeter: nothing works with all 2.6.x kernels and the current udev
[17:26] <Keybuk> udev's compatibility is based on, for lack of a better word, epochs
[17:26] <tkamppeter> So udev rules always need to be made individually for each release of a distro?
[17:26] <Keybuk> the latest version of udev is compatible with the latest kernel release, and previous kernel releases for a given time period
[17:26] <frandieguez> hi to all
[17:26] <Keybuk> that time period is pretty much deliberately chosen based on the release cycles of distributions
[17:26] <TheMuso> tjaalton: can confirm the alsamixer bug, working on it now.
[17:27] <frandieguez> I've generating a custom live cd with uck
[17:27] <frandieguez> but I need to put a link into all the desktop users
[17:27] <frandieguez> put it into /etc/skel is the only way?
[17:27] <frandieguez> thanks after all
[17:27] <Keybuk> you can't even *compile* udev with kernels older than a year or two
[17:28] <Keybuk> the current minimum version of kernel it supports at all is 2.6.22
[17:28] <jdstrand> kirkland, nijaba: so I just installed screen-profiles 1.12-0ubuntu1, and for giggles had it add /usr/bin/screen-launcher to .bashrc. Interesting side-effect: I open a gnome-terminal and do some stuff. I open another gnome-terminal and I an attached to the same screen session and when I type in one terminal, it shows up in both
[17:28] <tkamppeter> Keybuk, so it seems to be better then that if we upstreamize these UDEV rules that we should do it in udev-extra and not in HPLIP?
[17:28] <Keybuk> tkamppeter: that's the long-term plan
[17:28] <jdstrand> kirkland, nijaba: that is intended?
[17:28] <kirkland> jdstrand: yes, by design
[17:28] <Keybuk> at least for that kind of rule
[17:28] <kirkland> jdstrand: F6 to detach
[17:29] <nijaba> jdstrand: yes, I find it very usefull
[17:29] <jdstrand> kirkland: but F6 takes me out of screen entirely
[17:29] <Keybuk> tkamppeter: perhaps a better way to put it
[17:29] <kirkland> jdstrand: you can add/remove it independently from your .bashrc or .bash_profile
[17:29] <Keybuk> "udev doesn't care about backports"
[17:29] <jdstrand> kirkland, nijaba: I can see the utility, it was just quite surprising
[17:29] <Keybuk> personally, if I maintained hplip upstream, I'd just state that you need a recent kernel and recent udev for it to work
[17:29] <tkamppeter> HPLIP tries to make everything so that it works with the maximum possible amount of distros, therefore probably these UDEV rules. which work on Jaunty but can break on Jaunty+1 due to deprecated stuff in there.
[17:29] <Keybuk> and wouldn't bother supporting 2.6 releases older than a year or two, let alone 2.4!
[17:30] <kirkland> jdstrand: i think that's the effect of adding it into .bashrc
[17:30]  * nijaba loves surprising jdstrand :)
[17:30] <kirkland> jdstrand: i think it's the .bash_profile bit that does it on login
[17:30] <nijaba> kirkland: no, the -Xrr does it
[17:30] <jdstrand> kirkland: oh it certainly was-- it didn't do that before the change to .bashrc
[17:30] <kirkland> jdstrand: anyway, open a bug, if you like, and we can separate that functionality in the profiles-helper, to allow for adding to both, none, one, or the other
[17:31] <tkamppeter> Keybuk, so perhaps I simply put our UDEV rules into the package for now and do not upstream them to HPLIP. Feel free to upstream them to udev-extra.
[17:31] <Keybuk> actually
[17:31] <Keybuk> now I think about it
[17:31] <Keybuk> udev doesn't even work on ARM ;)
[17:31] <jdstrand> (well, screen-launcher did it-- whatever screen-launcher behind the 'screens' I don't know :)
[17:31] <kirkland> Keybuk: can we discuss encrypted swap at the Berlin sprint?  I'm curious if/how that's going
[17:31] <Keybuk> I should probably mention that at some point
[17:31] <ogra> Keybuk, ?
[17:31] <Keybuk> ogra: oh, hai
[17:31] <ogra> Keybuk, what does make you think udev doesnt work on arm
[17:32] <ogra> works just fine
[17:32] <Keybuk> ogra: ARM doesn't implement pselect() or ppoll()
[17:32] <Keybuk> it's possible to deadlock due to a race condition in the libc wrapper
[17:32] <ogra> well, the deamon runs and i have devices that are not statically there
[17:33] <kirkland> jdstrand: i've changed my work model a little bit
[17:33] <Keybuk> sure, but every now and then, probably only whenever a CEO of an important client tests it, you'll end up with a wedged udevd and not much in /dev
[17:33] <ogra> so to some extend it works
[17:33] <Keybuk> and probably a hung boot
[17:33] <kirkland> jdstrand: i now have one gnome-terminal tab per host I ssh to
[17:33] <ogra> and i dont see any segfaults or anything
[17:33] <Keybuk> (you'll hit exactly a similar bug with Upstart)
[17:33] <Keybuk> oh, it won't segfault
[17:33] <Keybuk> it'll just hang
[17:33] <kirkland> jdstrand: and within each gnome-terminal tab (a single host), i'm running a screen session with multiple tabs on that host
[17:33] <Keybuk> sitting in select()/poll() waiting for a signal that'll never happen
[17:34] <ogra> strange, i havent had any probs since i started with arm
[17:34] <Keybuk> there's probably lots of programs that'll experience the same bug, really
[17:34] <Keybuk> ogra: you know about pselect() etc. right?
[17:34] <Keybuk> why they exist?
[17:34] <jdstrand> kirkland: that certainly seems sane
[17:34] <jdstrand> lord knows my 9 open terminals isn't...
[17:35] <kirkland> jdstrand: :-0
[17:35] <kirkland> jdstrand: it adds a key stroke ....
[17:35] <Keybuk> put simply, you have children and you want to break out of select() when a child dies so you can reap it
[17:35] <ogra> Keybuk, well, reading/writing to fds
[17:35] <Keybuk> you might write code like this
[17:35] <kirkland> jdstrand: when i want to ssh somewhere, i'm now doing, ctrl-shift-t then F6
[17:35] <Keybuk>   sigprocmask (SIG_UNBLOCK, &set, NULL);
[17:35] <Keybuk>   select (...);
[17:35] <Keybuk>   sigprocmask (SIG_BLOCK, &set, NULL);
[17:35] <Keybuk> where set includes SIGCHLD
[17:35] <cjwatson> Keybuk: does udev not use the standard self-pipe workaround?
[17:36] <jdstrand> kirkland: ctrl-shift-t is to open a new tab in gnome-terminal, right? (meaning-- you didn't override that in screen did you?)
[17:36] <kirkland> jdstrand: righto
[17:36] <Keybuk> cjwatson: no, it deliberately uses ppoll() because the standard self-pipe workaround has another bug when you fill the pipe up ;)
[17:36] <jdstrand> (I do use tabs as well, but often I like to see stuff at the same time)
[17:36] <Keybuk> ogra: the problem with the above code is that it's racey
[17:36] <cjwatson> hmm, I suppose that does actually happen in udevd with the number of processes it spawns
[17:36] <ogra> Keybuk, but really, i havent seen any probs with udev yet on the five different boards i have here
[17:37] <Keybuk> ogra: if the SIGCHLD occurs after sigprocmask but before the select(), you will never terminate the select() due to SIGCHLD
[17:37] <ogra> right
[17:37] <Keybuk> so pselect() was invented, that atomically changes the signal mask around a select()
[17:37] <Keybuk> but ARM doesn't implement it
[17:37] <Keybuk> so any program using pselect() or ppoll() is susceptible to the same race condition
[17:38] <Keybuk> pgraner: it would be nice if the kernel could implement those syscalls on ARM ;-)
[17:40] <ogra> ogra@******:~/linux-omap-2.6-old$ grep -R pselect *|grep arm
[17:40] <ogra> arch/arm/include/asm/unistd.h:					/* 335 for pselect6 */
[17:40] <ogra> hmm
[17:40] <jdstrand> kirkland, nijaba: actually, I'm not entirely sure I do see the utility of this feature. can you explain a use case (the shared screens between to separate gnome-terminals)
[17:40] <Keybuk> kirkland: encrypted swap?  I've not seen anybody working on that
[17:41] <kirkland> jdstrand: hmm, so you think the .bash_profile entry would be sufficient?
[17:42] <kirkland> Keybuk: uh-oh...  then this has slipped through the cracks
[17:42] <Keybuk> kirkland: who is the assignee?  I thought you were :p
[17:42] <Keybuk> you were the only person at UDS who was interested in it that I noticed
[17:42] <TheMuso> tjaalton: Hrm after a restart, it works for me now.
[17:43] <kirkland> Keybuk: hmm, rick has shifted me off of ecryptfs stuff
[17:43] <jdstrand> kirkland: well, you would then still have the same behavior as soon as someone checked 'Run command as login shell', no?
[17:43] <kirkland> Keybuk: anyone using encrypted-home will absolutely need encrypted-swap, for their solution to be at all secure
[17:43] <Keybuk> kirkland: the spec is assigned to you, and you are drafter
[17:43] <kirkland> Keybuk: in that scenario, all of their supposedly encrypted data will live in memory in the clear
[17:43] <Keybuk> but no spec has been drafted
[17:43] <jdstrand> kirkland, nijaba: keep in mind, I'm not saying it isn't useful, I just don't know how it is :)
[17:43] <kirkland> Keybuk: fark...  it didn't get reassigned
[17:44] <Keybuk> I maintain my basic objection to the idea
[17:44] <kirkland> Keybuk: i'll raise this with rick immediately, ask how to proceed
[17:44] <kirkland> Keybuk: breaking hibernate?
[17:44] <Keybuk> it's not possible to encrypt swap in the multi-user machine case
[17:45] <nijaba> jdstrand: I have mutiple virtual desktop (web/email/chat/dev/office/calendar).  I keep terminal open in a few of them to follow stuff, copy and paste etc.  I like to be able to see the same stuff than in my other virt desktops
[17:46] <jdstrand> nijaba: couldn't that be achieved with a sticky window?
[17:46] <nijaba> jdstrand: the *some of them* part would not
[17:46] <jdstrand> (aka 'Always on visible workspace')
[17:47] <liw> if you're worried about encrypting swap, why not use the whole-disk encryption things that already work well?
[17:47] <jdstrand> nijaba: true enough
[17:47] <jdstrand> kirkland, nijaba: fyi, bug #319691
[17:47] <nijaba> liw: would work only if swap is stored in files, not in its own partition, which would not be encrypted, IIUC
[17:48] <pitti> tseliot: where is the new version of dontzap?
[17:49] <nijaba> jdstrand: in the reverse, do you really open multiple terminal to the same host, or would you open multiple windows in screen?
[17:50] <jdstrand> nijaba: I do everything, but I'm nuts
[17:50] <nijaba> jdstrand: aren't we all?
[17:50] <jdstrand> heh
[17:50] <jdstrand> nijaba: if I ssh into another host, 9 times out of 10, it will be in a separate gnome-terminal
[17:51] <liw> nijaba, my swap seems to be in a partition (or lvm volume), and encrypted
[17:51] <nijaba> jdstrand: yes, I do the same, but I have different profiles in gnome terminal that opens to diffrent hosts
[17:51] <jdstrand> nijaba: beyond that, it is highly dependent on what I am doing (ie, do I need to see two terminals at once)
[17:52] <nijaba> jdstrand: I have learned to color code my window to different host, to avoid shuting down the wrong one :)
[17:52] <pitti> tseliot: oh, Vcs-Bzr:, nevermind
[17:52] <liw> nijaba, with the standard encrypted-lvm setup Ubuntu already supports, that is
[17:52] <jdstrand> nijaba: I use different colored prompts...
[17:52] <tseliot> pitti: right ;)
[17:52] <pitti> bzr FTW
[17:52] <nijaba> jdstrand: yep, I do too, but in that case, I open to terms, both using the same screen env, but focusing on different screen windows
[17:52] <liw> (of course, anyone really caring about their security and privacy, doesn't do anything sensitive on a multiuser machine ;-)
[17:53] <ion_> nijaba: apt-get install molly-guard
[17:53] <jdstrand> nijaba: but I'm in no way suggesting that screen-profiles be adjusted to my workflow, only questioning if the current setup is a good default
[17:53] <nijaba> jdstrand: ttytt, I have no idea, that's why I like discussing it :)
[17:54] <tkamppeter> Keybuk, fixed HPLIP is uploaded. All is tested with therre HP printers and it works.
[17:55] <tkamppeter> s/therre/three/
[17:55] <nijaba> ion_: thanks, quite a usefull addition to make to my "standard package list"
[17:56] <nijaba> liw: huh, you're right, I just started a vm with this setup, and the swap is in lvm, indeed.  Thought it was external...
[18:01] <asomething> ScottK: hi, you closed bug 275375, but I don't see the package in jaunty-changes, the archives, or the build queue. how do you know that a sync has been done?
[18:01] <asomething> bug 275375
[18:02]  * cjwatson responds to somebody reformatting a patch as a debdiff for sponsorship (by adding the changelog, and not crediting the original contributor) by committing the patch upstream, crediting the original contributor, and *not* crediting the person who reformatted it as a debdiff
[18:02] <cjwatson> I hope this is reasonable ...
[18:02] <LaserJock> cjwatson: nice
[18:02] <asomething> ^oops, that should be in ubuntu-motu
[18:12] <cjwatson> james_w: should lp:~james-w/bash-completion/ubuntu be moved to ~ubuntu-core-dev?
[18:12] <james_w> cjwatson: probably.
[18:12] <cjwatson> I was about to upload bash-completion and noticed that branch
[18:12] <james_w> ah
[18:12] <cjwatson> james_w: will you, or should I just branch from you and push?
[18:12] <james_w> Debian maintain it in bzr, so a "bzr send" would be appreciated
[18:13] <cjwatson> my laptop can't send mail itself. How do I tell bzr send to output to a file so that I can scp it to my mail machine?
[18:13] <cjwatson> (yes, I should fix my laptop)
[18:14] <james_w> cjwatson: I can't move it to core-dev, as I'm not a core-dev, so please push and I'll delete that branch
[18:14] <james_w> bzr send -o file
[18:14] <cjwatson> oh, I'd forgotten you weren't core-dev
[18:14] <cjwatson> ok
[18:14] <cjwatson> (why not? :-) )
[18:15] <kirkland> jdstrand: for me, the use case is the first launch of my gnome-terminal
[18:16] <jdstrand> kirkland: I see the utility in starting screen in the terminal absolutely-- I'm talking about the shared screen business
[18:17] <jdstrand> (where other terminals are attached to the first one by default)
[18:17] <tkamppeter> Keybuk, fresh HPLIP uploaded, now it is your action item to upstreamize the UDEV rules to udev-extra.
[18:18] <shaya> does anyone else see tracker killing desktop performance due to the same sqlite issue as firefox?
[18:18] <pitti> wasn't that due to calling fsync() a lot, which doesn't really do what you want on Linux?
[18:21] <shaya> yes
[18:21] <shaya> and tracker is current killing my system
[18:22] <shaya> very heavily modifying sqlite db's
[18:22] <shaya> and sqlite calls fsync in default config
[18:22] <shaya> hence, I assume its same issue
[18:23] <shaya> for instance, can't watch a video, as it locks up the system on fsync and hence constant stutter
[18:37] <Keybuk> http://bazaar.launchpad.net/%7Eubuntu-core-dev/udev/ubuntu/revision/2414?compare_revid=2411
[18:37] <Keybuk> cjwatson: that should do the trick, I think
[18:41] <cjwatson> Keybuk: looks fine, I think. (It would be cleaner to use "cat <<'UDEVADM'" so that you don't have to escape all the dollar signs.)
[18:42] <cjwatson> Keybuk: perhaps "without a dependency on udev" => "while udev is unconfigured" in case users happen to run udevadm in that period?
[18:42] <Keybuk> true
[18:42] <cjwatson> Keybuk: what used init.d restart (now refresh-devices)?
[18:42] <Keybuk> cjwatson: nothing
[18:42] <cjwatson> ok
[18:43] <cjwatson> I take it it isn't possible to use that in case the sequence number changed?
[18:45] <Keybuk> that has other bugs ;)
[18:45] <Keybuk> most of the system doesn't like it
[18:45] <Keybuk> e.g. network manager
[18:47] <cjwatson> right
[18:47] <apw> pitti, about?
[18:49]  * Keybuk has a clever idea
[18:49] <apw> pitti, i have an apport fix proposed for merging and suspect you are the only one who will look at it :)
[19:01] <cjwatson> Keybuk: I was going to look at bug 285531, but it seems like more your kind of thing. Fancy grabbing it?
[19:01] <Keybuk> sure
[19:01] <cjwatson> thanks
[19:46] <\sh> cjwatson: bug #314004 happend to me during hardy -> intrepid dist-upgrade just now...
[19:48] <cjwatson> \sh: I need all the appropriate log files (including /var/log/installer/syslog) filed as a *separate* bug report please, as it may not in fact be the same issue even if it looks like it
[19:48] <cjwatson> \sh: also /var/log/dpkg.log
[19:48]  * cjwatson &
[19:49] <\sh> cjwatson: /var/log/installer/syslog is empty..(I was using apt-get dist-upgrade) but I can check for dpkg.log
[19:50] <cjwatson> \sh: it should have been created during installation. It is likely only readable by root, but is not likely to be empty
[19:50] <\sh> cjwatson: believe me :) http://paste.ubuntu.com/107931/ :)
[19:51] <\sh> cjwatson: it's not installed via d-i it was more a automated installation by hoster. but apt-get dist-upgrade should full dpkg.log
[20:00] <NCommander> cjwatson, ping?
[20:01] <NCommander> cjwatson, could you look to seeing if we could merge the fix for http://bugs.debian.org/504555 into our initramfs-tools? It would be handy for the ARM port
[20:06] <Keybuk> NCommander: probably better off directing that one at me
[20:08] <NCommander> Keybuk, the RedBoot MTD support would be useful since a lot of ARM devices use RedBoot, do you think there would be any issues with merged that patch in?
[20:09] <Keybuk> NCommander: looked sane to me
[20:09] <Keybuk> can you file a bug?
[20:09] <Keybuk> feel free to assign it to "scott"
[20:09] <NCommander> Keybuk, sure
[20:09] <\sh> NCommander: hmm...ubuntu on my nas device?,-)
[20:10]  * NCommander already has Ubuntu on his NSLu2
[20:10] <NCommander> :-)
[20:10] <\sh> NCommander: hopefully redboot doesn't fck up during install, if so, Ican throw away my nas device ,-)
[20:11] <NCommander> \sh, we don't reinstall RedBoot (actually, ATM, we don't even have an installer for NAS)
[20:12] <\sh> NCommander: if we will have it, I'll test :)
[20:16] <ogra> NCommander, you didnt tell him about the if_first_name_stephan_and_last_name_hermann_wipe_redboot() function ?
[20:17] <NCommander> ogra, oh, that spec got implemented?
[20:17] <\sh> ogra: lol :)
[20:17] <ogra> secretly, shhh
[20:17] <ogra> :)
[20:17]  * NCommander now has four machines running different versions of Ubuntu
[20:17] <NCommander> woo :-P
[20:18] <\sh> ogra: you know why I do have a Nas device? Because a friend wanted to have linux on it, I fragged it, and now it's mine and runs ,-)
[20:19] <ogra> heh
[20:19] <\sh> and it looks like that I fragged the dev esx too
[20:19]  * ogra knows why he doesnt let \sh near his machines :P
[20:21] <NCommander> ACK, VMWARE
[20:21]  * NCommander dies
[20:21] <\sh> ogra: not my fault ;) select 20 instances at once and tell esx to suspend it...with 18gig ram, and 16 gb occupied...that means: die esx die
[20:21] <ogra> heh
[20:22] <NCommander> \sh, so much for VMware's fault tolerant solutions
[20:22]  * NCommander notes that fault tolerance often isn't user tolerant ...
[20:22] <\sh> NCommander: yepp...
[20:22] <\sh> and reminder: doing esx updates via cli is much faster then doing it via vcenter update manager
[20:25] <NCommander> Keybuk, bug #319730
[20:28] <TomJaeger> Hi.  How do I add an ubuntu package to a bug?
[20:29] <\sh> time to leave the office and go home...good night folks
[21:33] <cjwatson> \sh: if it was installed specially, I'm not really sure I can help
[21:35] <cjwatson> \sh: for custom installs like that, just installing grub first would be fine, assuming that that's appropriat
[21:35] <cjwatson> e
[21:56] <directhex> nobody's planning on putting dh7.1 into jaunty are they?
[22:09] <shaya> there's a crasher bug in firefox in intrepid that was fixed in 3.0.2 that is still crashing ubuntu's build
[22:09] <shaya> https://bugzilla.mozilla.org/show_bug.cgi?id=441368
[22:09] <shaya> the test case in that bug crashes my intrepid firefox
[22:17] <dtchen> shaya: might want to repeat in #ubuntu-mozillateam
[22:24] <lfaraone> Hi, how long does it take for NEW synced packages to be approved?
[22:25] <seb128> lfaraone: until an archive admin process those, some hours to some days usually, why?
[22:25] <dtchen> there's no upper bound, but usually less than one working week
[22:27] <seb128> lfaraone: I just newed the one synced today
[22:28] <maxb> Which channel would I be best off in for finding someone to give me hints on how to debug some guts of network-manager?
[22:28] <seb128> maxb: either this one or #ubuntu-bugs
[22:28] <lfaraone> seb128: I saw :)
[22:29] <lfaraone> seb128: thanks.
[22:31] <seb128> lfaraone: you are welcome
[22:32] <maxb> thanks
[22:32] <LaserJock> hmm, these new signed PPAs are a bit unfriendly in terms of UI
[22:32] <directhex> a smidge
[22:34] <LaserJock> the help page just tells you to see if the fingerprint is the same and keep downloading
[22:36] <LaserJock> I wonder how helpful it is to sign the packages if you don't let apt/dpkg verify the signature
[22:36] <maxb> no help at all, but I imagine the annoyance of the warning will drive people to sort out adding the keys to their apt keyring
[22:37] <maxb> I whipped up a maxb-ppa-keyring package for my own PPA, but it would have been nice if template packages for that had been made officially
[22:38] <LaserJock> or at least had a gpg line to get it
[22:48] <superm1> maxb, LaserJock bug 319355
[23:18] <hongli> hi. I want to repackage gtk with a backported fix from upstream
[23:19] <hongli> is there any documentation on how to do this?
[23:20] <pochu> hongli: no, but that would be like with any other package
[23:20] <hongli> but how do I do it in general?
[23:21] <hongli> I know how to build a deb, I know how to code. but what I don't know is how gtk's build system integrates with the debian package building process
[23:21] <hongli> specially because debian/ubuntu keeps its own patch set
[23:21] <pochu> apt-get source gtk+2.0; cd into the unpackaged package, put the patch in debian/patches, add a changelog entry and rebuild it
[23:22] <directhex> pochu, no series/00list etc?
[23:22] <hongli> so am I supposed to apply all the patches, then run ./configure && make install DESTDIR=/foo, then copy 'debian/' into /foo/DEBIAN, then package /foo?
[23:22] <pochu> oh, yeah
[23:22] <pochu> we use quilt for it
[23:22] <pochu> err
[23:22] <pochu> hongli: does your patch touch configure.ac or any Makefile?
[23:22] <hongli> no
[23:23] <pochu> then you should do something like this:
[23:24] <pochu> 00:18 <@    Np237> export QUILT_PATCHES=debian/patches; quilt delete 15_blahblah; quilt push 14_blahblah; quilt new 15_blehbleh; quilt edit foo.c bar.c ... ; quilt refresh
[23:24] <pochu> but you don't need to delete any patch :)
[23:24] <hongli> quilt huh, first time I've heard of that tool
[23:25] <pochu> it's like git but for patches :P
[23:25] <hongli> is there an ubuntu document about quilt?
[23:25] <hongli> I was looking in https://wiki.ubuntu.com/ContributeToUbuntu
[23:25] <pochu> hmm, let's see
[23:25] <pochu> !quilt
[23:25] <hongli> I haven't found anything that mentions quilt
[23:26] <pochu> there's something in Debian
[23:26] <pochu> it's the same, so you can use that
[23:26] <pochu> http://pkg-perl.alioth.debian.org/howto/quilt.html
[23:26] <hongli> hm, if only there's a 'The Definite Guide to Contributing to Ubuntu' or something like that :(
[23:26] <LaserJock> pochu: there's the patching part of the Packaging Guide
[23:26] <pochu> hongli: ^
[23:26] <pochu> !patch
[23:26] <pochu> second link :)
[23:26] <hongli> so is quilt what all debian packagers use for maintaining downstream patches?
[23:27] <pochu> nope
[23:27] <LaserJock> https://wiki.ubuntu.com/PackagingGuide/PatchSystems#quilt%20(example%20package:%20xterm)
[23:27] <pochu> there's quilt, dpatch, simple-patchys, modifying sources in the diff.gz...
[23:27] <hongli> ok
[23:27] <pochu> "You can install 521 updates"
[23:27] <pochu> ouch!
[23:28] <hongli> another question, is there a way to increase awareness or priority for a certain ubuntu bug?
[23:28] <hongli> I've been an ubuntu user for years
[23:28] <hongli> but unfortunately each new release introduces new regressions
[23:28] <hongli> most of them are marked 'low priority' on launchpad
[23:28] <hongli> I'm wondering how to get more attention to them. is donating a good option?
[23:28] <pochu> hongli: yeah, you can discuss about it in #ubuntu-bugs
[23:29] <pochu> hongli: I think if you say it's a regression it will be given a higher priority
[23:29] <hongli> these days I'm a very busy man and I wouldn't mind donating some money if I can get regressions fixed
[23:29] <hongli> I discovered 2 annoying bugs upon installing 8.10 yesterday (was using 8.06 previously)
[23:30] <hongli> one is that setting the keyboard repeat rate doesn't work (X.org bug)
[23:30] <hongli> the other is that the gtk file dialog is unusably small
[23:30] <hongli> the latter is so obvious that I wonder how it got past QA
[23:30] <hongli> which is why I was asking how to repackage gtk so I can fix the bug myself
[23:31] <pochu> because it may be due to your configuration
[23:31] <hongli> this is a clean install
[23:31] <pochu> oh
[23:31] <pochu> hongli: if the patch is small, there could be an Stable Release Update
[23:32] <pochu> but since it's GTK, it may well be rejected as it may not be worth the risk for such a fix
[23:33] <hongli> the alternative is a literally unusable file dialog
[23:34] <hongli> so I think fixing this is the only answer no matter what the risk is. don't you agree?
[23:34] <savvas> hongli: did you report them? http://bugs.launchpad.net/ubuntu/+filebug
[23:35] <hongli> it was already reported: https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/285285
[23:35] <hongli> I confirmed the bug as well
[23:35] <hongli> fix was committed upstream
[23:35] <hongli> but not backported to intrepid
[23:36] <hongli> so I guess I'll wait for a few days and see how they respond to this bug report
[23:36] <savvas> hongli: nominate it if you want, but I don't think it will be approved, jaunty is just a few months away
[23:37] <hongli> "a few months" is quite a long time
[23:37] <savvas> hongli: www.ubuntu.com/testing :)
[23:37] <hongli> if this bug doesn't get fixed, and if I don't have the time to do it myself (I probably don't),
[23:37] <hongli> then I'll have to use OS X :(
[23:37] <hongli> something which I want to avoid because the keyboard on my macbook sucks
[23:37] <savvas> hongli: ubuntu 8.04 has the same problem?
[23:38] <hongli> no, 8.04 is okay
[23:38] <savvas> so?
[23:38] <savvas> there are regular backports to the long term release
[23:38] <hongli> downgrading means I can't use the latest software packages
[23:38] <hongli> what I actually want is to be able to keep my software as up to date to upstream as possible, while still being stable
[23:39] <hongli> instead of stable but stuck with ancient versions
[23:39] <savvas> hongli: then you want debian testing
[23:39] <hongli> not ubuntu?
[23:39] <directhex> "stable" by definition means "not constantly changing"
[23:39] <Hobbsee> hrm.  jaunty actually works now.
[23:39] <savvas> ubuntu gets most of its packages from debian (and vice versa)
[23:40] <hongli> directhex: formally you may be right, but "stable" means "things don't crash/have lots of bugs" as far as most end users are concerned
[23:40] <hongli> and that's what I mean with "stable" as well
[23:40] <hongli> change is okay, but I want things not to crash or have lots of bugs
[23:40] <hongli> and that things don't break
[23:40] <LaserJock> right, which is why we have a Stable Release Updates policy
[23:40] <savvas> hongli: there are way to get around with different distributions, debian testing seems to be what you need - at least for now, until jaunty is out
[23:41] <hongli> I have used all kinds of distros in the past
[23:41] <directhex> hongli, and how do you apply QA to a new upstream version?
[23:41] <hongli> directhex, use it, check whether there are obvious bugs, if so reject it, if not accept it?
[23:42] <directhex> hongli, there are 25000 packages in the archive. and a lot of bugs which happen as a result of intersections between those 25000
[23:42] <hongli> anyway, that isn't important right now. suppose that I can't get the fix backported to intrepid by just raising my concern
[23:42] <hongli> can I donate money to someone to have it done anyway?
[23:42] <hongli> even if it's just a third party package
[23:43] <hongli> as long as it's fixed
[23:43] <LaserJock> hongli: I'm doubting money is going to do much
[23:43] <hongli> heck, can I pay one of you to do it?
[23:43] <LaserJock> hongli: but you might ask around for to see if somebody would want to do it for you
[23:43] <hongli> I have a job so I can't do this every time I encounter a bug
[23:43] <LaserJock> but I'd first see if an SRU is possible, it might be
[23:43] <hongli> SRU?
[23:44] <LaserJock> Stable Release Update, getting the fix into intrepid-updates
[23:44] <LaserJock> it's a fairly minor bug, but if there's enough demand for it maybe it'd make it
[23:44] <hongli> LaserJock, with all due respect, why do you think it's "minor" if the dialog is unusable by default?
[23:45] <hongli> and by unusable I mean it
[23:45] <LaserJock> because you can easily resize it
[23:45] <hongli> but I encounter it dozens of times, on a daily basis
[23:45] <LaserJock> sure
[23:45] <hongli> in the mean time, someone posted this issue on reddit
[23:45] <LaserJock> it's an annoyance, no doubt
[23:45] <hongli> this spawned *320* comments
[23:45] <hongli> 90% negative
[23:45] <hongli> and yelling how gtk/ubuntu sucks
[23:45] <LaserJock> but compared to applications that don't even start or crash
[23:45] <hongli> it's giving you a bad reputation
[23:45] <LaserJock> it's minor
[23:46] <LaserJock> hongli: I certainly understand where you're coming from
[23:46] <LaserJock> but it's not always that straightfoward
[23:47] <LaserJock> and in comparison to the other bugs out there this one if fairly minor, even though annoying
[23:47] <LaserJock> *is
[23:47] <LaserJock> of course that doesn't mean we can't give it a go at fixing it
[23:50] <LaserJock> the fix is 1 week old and looks fairly invasive
[23:50] <hongli> ok I understand that there are lots of packages and that you have to prioritize
[23:51] <hongli> if I can't provide you with manpower, is there anything I can do to help?
[23:51] <hongli> is financial help really not worth much?
[23:52] <LaserJock> I don't think particularly helpful, though I could be wrong
[23:53] <LaserJock> hongli: your comments for today on that bug are probably helpful in raising the bugs profile
[23:53] <directhex> you want a patched gtk package? one off?
[23:54] <hongli> I want a patched gtk package that fixes the resize bug
[23:54] <directhex> and you already know the revision which fixes it?
[23:54] <hongli> the file dialog resize bug
[23:54] <LaserJock> directhex: there's 4 svn commits that are supposed to fix it
[23:54] <hongli> frederico mentions the revision on the upstream bug tracker
[23:54] <LaserJock> directhex: in the Gnome bug that's linked
[23:56] <hongli> has anyone ever considered a "bounty repository"?
[23:56] <hongli> that is, users who experience regression/annoying bugs like this can put up bounties
[23:56] <savvas> hm.. I just noticed something on debian testing: Get:56 http://ftp.no.debian.org testing/main 2009-01-19-0229.27.pdiff [2341B]
[23:56] <hongli> users can donate
[23:57] <hongli> interested developers can fix these problems
[23:57] <savvas> is the new aptitude getting package differences?
[23:57] <hongli> and publish the changes in a third party repository
[23:57] <maxb> pdiffs are nothing new
[23:57] <LaserJock> hongli: we've done a bounty system in the past and it didn't work
[23:57] <hongli> what went wrong?
[23:58] <LaserJock> well, frankly I think people underestimate 1) how much money it takes and 2) how much people don't do this for the money
[23:58] <pochu> hongli: this is your bug, isn't it? http://blogs.gnome.org/mortenw/2009/01/21/the-gtk-file-chooser-dialog/
[23:58] <hongli> pochu: no I'm not him
[23:58] <hongli> but yes it's the bug I mean
[23:58] <pochu> I mean your bug, not your blog :)
[23:59] <pochu> hongli: money is not going to help you get the bug into intrepid-updates probably, as it's not a metter of somebody doing it but rather of the SRU team accepting it
[23:59] <hongli> LaserJock: I was about to ask whether enough effort was spent on marketing the system
[23:59] <hongli> but if 2 is true then it is a problem that isn't easily fixed
[23:59] <pochu> it can help you if you find somebody that is willing to prepare the packages in a private repository, though
[23:59] <hongli> short of getting corporations to hire developers
[23:59] <pochu> but I'd suggest try to get it accepted for an SRU before, as that will benefit everybody using intrepid
[23:59] <directhex>  ChangeLog                    |   44 ++++++++++++++++++++++++++++
[23:59] <directhex>  gtk/gtkfilechooserdefault.c  |   66 ++++++++++++++++++++++++++++++++++++++----
[23:59] <directhex>  gtk/gtkfilechooserdialog.c   |   65 ++++++++++++++++++++---------------------
[23:59] <directhex>  gtk/gtkfilechoosersettings.c |   67 +++++++++++++++++++++++++++++++++++++++++++
[23:59] <directhex>  gtk/gtkfilechoosersettings.h |   16 ++++++++++
[23:59] <directhex>  5 files changed, 219 insertions(+), 39 deletions(-)