=== mthaddon_ is now known as mthaddon === hyperair1 is now known as hyperair === freeflyi1g is now known as freeflying === pgraner is now known as pgraner-afk [04:55] allo ppl, i'm looking for a package that is apparently supposed to be in a repo, but cannot find it [04:55] gwydion-dylan-dev to be precise [04:56] by supposed to be i mean "was last year" [04:59] We've got nothing like that. In the future, #ubuntu is the support channel. [05:00] oh my bad [05:00] by "we've got nothing like that", you mean, there isn't a package in the ubuntu repositories? [05:01] s/a package/the gwydion dylan package/ [05:02] Searched on qwydion and got nothing. [05:03] See http://packages.ubuntu.com. [05:03] nice, thanks === ssweeny_ is now known as ssweeny [06:14] good morning [07:02] calc: is OO.org 3.1 planned for jaunty? === hyperair1 is now known as hyperair === stefan__ is now known as stefanlsd [07:13] Keybuk: heh, the server keyboard doesn't work in premount phase [07:13] so that didn't work out [07:13] maybe I could use the serial console.. [07:37] Keybuk: ok, so for some reason it doesn't match the "RUN+=kpartx .." rule === tkamppeter_ is now known as tkamppeter [07:48] ara_: would it be a good idea to get the qa tools into Ubuntu proper? WDYT? [07:49] dholbach: yes, I think it should be a good idea. To do so, it needs a lot of cleaning first ;-) [07:50] ara_: we're before feature freeze - I think we can handle a few bugs :-) [07:50] ara_: maybe it makes sense to take a look at ubuntu-dev-tools for the packaging [07:50] dholbach: ok, I'll have a look [07:50] ara_: let me know how it goes :) [07:51] dholbach: are you sending me homework, teacher? ;-) [07:53] 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] Keybuk: think I got it.. the rule has just %N in it, when it should probably be /dev/%k [07:54] dholbach: don't worry; I have been always good at self-learning, Mr. ;-) [07:56] Keybuk: but it still timeouts way too early [08:08] the timeout seems to be around 20s [08:08] when it took ~1min to probe the SAN [08:08] Keybuk: ^^ === bluesmoke_ is now known as bluesmoke === seb128_ is now known as seb128 [08:38] Good morning [08:38] morning [08:42] hey there pitti! [08:45] * pitti hugs Hobbsee and evand [08:45] :) [08:45] 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] tjaalton: feedback appreciated if it works the way you want now [08:45] pitti: great, thanks [08:46] ogra might want to test it now [09:04] 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] nijaba: is there anybody else from the server team who might help out? [09:06] dholbach: sincerely, most of the dev on vmbuilder was done by soren and I [09:07] 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] nijaba: blogging about vmbuilder would be a good thing anyway ;-) [09:08] dholbach: ok, sounds like a plan [09:08] rock on [09:08] nijaba: thanks a lot for taking care of it [09:09] 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] dholbach: so that just mostly do cut and paste during the session [09:09] (apart for Q&A) [09:09] nijaba: I usually do it ad-hoc, but I know that a lot of people prepare text in advance [09:09] dholbach: ok, thanks [09:10] I think it makes sense to prepare stuff, especially if it's complicated stuff [09:10] dholbach: preparing in general is not an option, agreed [09:10] dholbach: I just wanted to know best practice for actual pre made text [09:11] it's definitely fine to paste in stuff [09:11] dholbach: then I think that's what I'll start with. thanks [09:11] thanks Nick [09:11] np [10:06] Keybuk: There's this warning / error when upgrading dbus: [10:06] * Reloading system message bus config... Error org.freedesktop.DBus.Error.Failed: Element not allowed inside in configuration file [10:06] Or any service doing a dbus reload actually [10:07] hi all [10:07] Keybuk: My understanding is that the running daemon doesn't know about this new mechanism [10:07] Is there a reason why the CD bootloader doesn't show the current Ubuntu version? [10:09] I guess it would make sense. The release name would be fine too. === asac_ is now known as asac [10:33] Unggnu: no particular reason; file a bug against gfxboot-theme-ubuntu, please [10:34] Keybuk: is there a way to cope with this udev stuff without using Break: by any chance? [10:35] cjwatson: thx [10:35] Keybuk: maybe a clever "postinst" that will create the rule file in the right place? [10:36] Keybuk: it makes it very hard to do backport of the cluster stack to a stable release for testing basically.. [10:40] Hi all, I'm thinking about how to get devs back into ubuntu-devel-discuss. [10:40] Would there be any value in making a Thunderbird plugin that only showed messages that have been replied to with "+1"? [10:41] not sure the people you try to bring back there use thunderbird ;-) [10:41] and having +1 replies on lists doesn't seem something to encourage [10:42] I don't know how to hack evolution, and it's easier to play around with ideas in Javascript than Procmail :) [10:42] 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] why do you want to bring extra people to this list? [10:43] what is the issue you are trying to solve? [10:43] seb128: because it's the list that users are pointed to to communicate with developers [10:44] 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] however, the S/N ratio has gotten so bad that most developers either a) never read it, or b) unsubscribe. [10:44] andrew_sayers: do you have any idea how many of them are left, compared to one year ago? [10:44] Hobbsee: that's why we had the -discuss split no? [10:44] BUGabundo: no, sorry. [10:44] seb128: precisely [10:44] Hobbsee: you are trying to get a -discuss-discuss now? [10:45] The thing is, I suspect there's going to be a constant chase unless we get some form of moderation. [10:45] cjwatson: consider done Bug #319545 [10:45] Launchpad bug 319545 in gfxboot-theme-ubuntu "ISO boot loader should show the Ubuntu version or relase name" [Undecided,New] https://launchpad.net/bugs/319545 [10:45] seb128: I thought you were asking about the issue that he was trying to solve, and I thought I answered that... [10:45] andrew_sayers: there is already a moderated list and there is -discuss [10:45] 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] seb128: Yes, and the moderated list is too restrictive, and the unmoderated list is not restrictive enough. [10:46] 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] 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] Hobbsee: you want to moderate that list and create a discuss-discuss not moderated next? [10:47] seb128: halfway there. Ditch the rest of the traffic to the forums or brainstorm or something. [10:47] or just plain /dev/null it with an explanation. [10:47] there is already a moderated list, what would be the point to have an another one? [10:48] -discuss is for open discussion [10:48] 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] if something should be escalated get somebody to cc the other list? [10:48] One problem with moderation is that it gives the wrong impression, like people aren't invited. [10:49] Hobbsee: well, there is no DTRT there [10:49] andrew_sayers: well, that's why -discuss is where people are pointed and it's not a moderated list [10:49] I'm not sure what you consider the issue there [10:49] Maybe I should have pointed that comment at Hobbsee :) [10:49] Unggnu: thanks [10:49] 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] 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] 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] there is a charter for -devel-discuss [10:50] 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] cjwatson: beyond "this is the way for users to contact developers?" I'll have to go check that [10:51] Not really - also, I'd like to point out that one dev's signal is another dev's noise. [10:51] 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] andrew_sayers: I think that's relatively rare actually [10:51] Hobbsee: https://wiki.ubuntu.com/UbuntuDevelModeration [10:52] or https://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-December/000227.html is a better link [10:52] that has the charters for -devel and -devel-discuss both [10:53] hrm, i thought that's what it said. [10:54] 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] andrew_sayers: do you have specific examples of problems there? [10:55] cjwatson: TBH, I don't subscribe to -devel, I'm put off by the moderation and general reputation of it. [10:55] 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] general reputation? [10:57] 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] 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] 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] BTW, the information from the link earlier is at https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss too [10:58] 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] james_w: ping [10:59] 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] hi emgent [11:00] james_w: good morning [11:00] james_w: cane you explaine to me this ACK https://bugs.launchpad.net/ubuntu/+source/drupal6/+bug/317337 ? [11:00] Launchpad bug 317337 in drupal6 "Please sync drupal6 6.6-2 (universe) from Debian unstable (main)." [Wishlist,Confirmed] [11:00] 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] Ideas and suggestions about future development of Ubuntu <-- should probably be for brainstorm [11:00] s/cane/can/ [11:00] Hobbsee: Good point, how about changing "+1" to "" or something that sounded less judgemental and more like signalling that devs should be interested. [11:00] Hobbsee: not exclusively [11:01] cjwatson: I disagree. You do it by having people with said background flag up posts that devs would be interested in. [11:01] emgent: I think you're mistaking drupal6 with drupal5 there [11:01] andrew_sayers: why wouldn't such people just move the thread to -devel? [11:01] Hobbsee: the same problem.. [11:02] cjwatson: so it should be in multiple places? I wasn't aware of that, but OK [11:02] much simpler than a complex flagging system (remember, please, that developers generally have a favourite mail client and are uninterested in changing) [11:02] emgent: what's the issue with it? [11:02] cjwatson: aside from the reasons I specified above, they would have to port the whole thread and act as a go-between. [11:02] emgent: then pull the debian version, and make additional changes after that. There are no ubuntu changes on it currently. [11:03] james_w: ubuntu use postfix in default not exim4 [11:03] 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] 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] cjwatson: right. [11:03] andrew_sayers: surely not, all that's necessary is to call the attention of developers to it [11:03] andrew_sayers: yes, that's why cross-posting between -devel and -devel-discuss doesn't work [11:03] andrew_sayers: excluding the recent fiasco with the desktop screenshots, the u-d list gets moderated pretty quickly, most of the time. [11:04] james_w: can you invalidate bug please ? [11:04] 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] cjwatson: I agree about calling dev's attention, I just disagree about the best mechanism. [11:05] james_w: last drupal version use postifx and IMHO is good to continue this road [11:05] ubuntu decided a standard road with postifx [11:06] so.. why ack wrong sync ? [11:06] emgent: then why not fix the bug, and mark the syncs invalid? [11:06] 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] emgent: no it didn't: http://packages.ubuntu.com/jaunty/drupal6 [11:06] andrew_sayers: nothing that depends on a specific mail client will be viable [11:06] Would a questionnaire sent to both lists work at all? [11:06] 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] cjwatson: which client(s) do most devs use? [11:06] varies [11:07] Hobbsee: ya correct, i mean explaine the problem to bhavani shankar and tel him to make the correct merge [11:07] emgent: where is this policy actually documented. [11:07] s/./?/ [11:07] 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] dont remember now, i'm not at home.. but anyway there are a doc in wiki if i remember well [11:08] hrm. brainstorm got updated. [11:08] 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] *mailserver* [11:09] emgent: then why wasn't it done months ago? [11:09] emgent: but the drupal6 in the archive won't change [11:09] last 1000 User-Agent headers in -devel have alpine, gnus, icedove, IMP, kmail, mutt, pan, squirrelmail, thunderbird [11:10] Hobbsee: someone acked it.. and someone uploaded sync.. [11:10] but IMHO it's a big error. [11:10] cjwatson: Looking on the bright side, that's only one web-based client. [11:10] emgent: then make your changes, rather than complaining about it? [11:10] andrew_sayers: I repeat, hacking the mail client won't work [11:11] 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] 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] huh? no, that's not what I mean [11:12] filing a well-documented bug is a way to bring something to the attention of developers [11:13] and surely that's the right way to deal with many things on -devel-discuss [11:13] Ah right. Many interesting points don't fit neatly into a bug report though. [11:13] 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] Hobbsee: correct, i'm olny asking.. [11:14] errare humanum est [11:14] s/olny/only/ [11:14] 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] 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] 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] 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] 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] 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] james_w: i only asked why, because for me it`s an error.. dont worry [11:16] E.g. to what degree this is a problem of education, reputation, ease-of-use, etc. [11:17] andrew_sayers: I'm not sure I have any thoughts on a questionnaire [11:17] fwiw, there don't seem to be many bugs on that list now. [11:17] except for "please make sure replies don't go to the list" ;-) [11:17] 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] it's more random discussion about stuff in ubuntu, and new things [11:17] Hobbsee: you're referring to -devel-discuss there? [11:17] or at least, that's what my looking at the archives tell me. [11:17] 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] andrew_sayers: yes [11:18] 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] (or similar) [11:18] james_w: me too. ;) [11:19] cjwatson: true. I think everyone that's ever written a program has experienced that :) [11:19] cjwatson: Where do you get your best tips then? [11:20] andrew_sayers: I cannot give you a single answer to that [11:20] 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] 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] I can vouch for that last one [11:22] andrew_sayers: busy people tend to be extremely reluctant to participate in what they see as "market research" [11:23] 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] it may well not be statistically significant, of course [11:25] 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] 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] emgent: as a bonus I just fixed the other two packages in the archive that still preferred exim [11:43] james_w: thanks for this [11:44] and at the same time making a mistake :-) [11:48] james_w: heheh :-) [11:54] ta seb128 [12:01] does the script used to sync pick up the requested version from the bug, or does it take the latest in the requested [12:03] the latest [12:03] lool: correct, just ignore it [12:03] if you want a specific version, flag it in the subject line [12:16] directhex: you're welcome [12:26] 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] directhex: ok [12:55] keybuk, hi [12:56] hi [12:56] Keybuk, it is about bug 318262, you have moved it to HPLIP without giving any comment. [12:56] Launchpad bug 318262 in hplip "/dev/bus/usb/*/* files (device nodes for libusb) of printers must be readble and writable for user "lp"" [High,New] https://launchpad.net/bugs/318262 [12:56] that's because I just did an upload [12:56] has to be on hplip for lp to close it [12:57] What did you upload? [12:57] hplip, obviously [13:00] Keybuk, you uploaded it only some minutes ago? [13:00] yes [13:01] This second it came through. Thanks. [13:02] that rule should be suitable for upstream [13:02] and eventually for inclusion in udev-extras [13:02] 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] Keybuk, you mean HPLIP upstream or UDEV upstream? [13:03] HPLIP upstream at first [13:03] but a little later on, udev-extras upstream [13:03] (which is where we think such "device catalogue" rules will go) [13:13] 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] Keybuk, the problem is that soon CUPS 1.4 will get released and its USB backend is libusb-based. [13:15] how do you know whether or not the device is a printer? [13:15] it's not as if USB has any kind of class information :-/ [13:15] (well, not one that anyone bothers with anyway) [13:18] Why did I get both rejected and accepted mails for all of my syncs that were processed today? [13:19] "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] Laney: not sure, I did the syncs the normal way and they seemed to have been synced correctly [13:28] yeah, happened to me too [13:28] didn't wanna bring it up in case i seemed ungrateful [13:28] :O [13:28] I was just raising it incase something went wrong [13:29] seems to have appeared fine though [13:35] 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] yes, BUT [13:35] the usblp module is a driver that operates on USB *interfaces* [13:35] USB interfaces to indeed have a class as you describe [13:36] and the interface is exposed as /dev/usblpN [13:36] you're telling me that CUPS plans not to use USB interfaces at all [13:36] but access the USB device in a raw fashion through the raw device access node /dev/bus/usb/XXX/YYY [13:36] since that raw device is *one* per USB device, the interface class does not apply [13:37] indeed, since it's a raw device, there's no requirement for you to even acknowledge the usb interface specification [13:37] 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] So one has to look into the CUPS 1.4 sopurce code to see what the new backend actually does. [13:38] 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] Keybuk, could UDEV do such things or would we need HAL then. [13:40] HAL is going away [13:40] HAL is going obsolete? What will replace it? [13:40] james_w: http://paste.ubuntu.com/107768/ ... bzr-builddeb version confusion? [13:40] udev and DeviceKit [13:40] devicekit [13:41] james_w: nevermind [13:41] ;) [13:42] 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. === pgraner-afk is now known as pgraner [13:46] same reason that scanner stuff stays in a largely broken state [13:46] geeks don't use paper :p [13:46] :-) [13:47] * pitti hugs his ebook reader [13:49] * directhex rolls up an ebook & beats Keybuk with it [13:50] doko_: jflex was now promoted. do you have the comments lool made on your radar still? [13:50] directhex: don't forget to call me "bitch" [13:51] lol [13:51] ooo err [13:56] 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] cjwatson: http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=5f03ed8a56d308af72db8a48ab66ed68667af2c6 [14:27] this should solve the installer case ;) [14:35] Keybuk: perfect, thanks [14:36] when is resolve_names == 0? === ogra_ is now known as ogra [15:04] cjwatson: see the next patch ;) [15:04] libudev supports ==0 to mean "resolve names for each event" [15:05] so I added --resolve-names=late as well [15:05] but did that separately in case Kay decided that he wanted to drop the support for the other [15:05] * cjwatson nods [15:13] glatzor: watch out for future packagekit releases [15:13] it's possible that hughsie may port to the new policykit [15:15] Keybuk, Thanks for notifying. Which new policykit? I plan to to stick at 0.3.x in jaunty. [15:16] 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] glatzor: davidkit released 0.90 pre today [15:17] Keybuk, the later release of Fedora already lead to some late feature additions in previous cycles. [15:19] hrm, sounds seems busted.. alsamixer can't find libasound_module_conf_pulse.so [15:19] cjwatson: got a moment to be a teddybear? [15:24] Keybuk: teddybear? (I have to go out now to take B to his cello lesson, back for the meeting ...) === smarter_ is now known as smarter [15:32] Is there a rough feature list for Jaunty somewhere? [15:32] 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] https://wiki.ubuntu.com/UbuntuDeveloperWeek Day 3 to kick off in #ubuntu-classroom in 23 minutes! :-) [15:42] go dholbach go [15:42] * mvo cheers [15:42] mvo: no... seb128 go! :) [15:42] no seb128 here .) [15:42] he ran away! [15:43] he's up first in 17 minutes [15:56] \o/ I now have iPhone reminders for my work calendar [15:57] tjaalton: no [16:19] tkamppeter: err, why did you change the priority of the hplip rules? [16:19] package rules should be 40, see /lib/udev/rules.d/README [16:19] Keybuk, I have overtaken it from upstream, the original rules file had 55. [16:20] right, but 55 is wrong ;) [16:22] Keybuk, does 40-xx not say 40 and higher? [16:22] no [16:22] 40-xx means 40 [16:22] Keynuk and rules coming with packages seem to be all < 60 in this file. [16:22] basically 40 for everything unless you have a good reason not to [16:25] Keybuk, the last line of the hplip.udev file has a RUN+="". Is it still 40 then or is it now 85 due to running a program? [16:26] you're reading the old REAMDE [16:26] the current one has no clause about running programs needing to happen later [16:27] unless you need information from the udev db [16:27] your file seems pretty self-contained, so it can basically go anywhere [16:27] thus 40 ;) [16:27] btw, can I just point out that the RUN rule won't work anyway ;) [16:27] so it's kinda irrelevant [16:28] Keybuk why does RUN not work? Deprecated? How to replace it? === stigi is now known as Sprut1 [16:33] tkamppeter: read your rule [16:33] what does it do? [16:33] keybuk: Want to bounce the idea off me? :-) [16:35] tkamppeter: shall I just tell you ? :p [16:36] the filesystem is read-only when udev runs [16:36] you can't edit config files [16:36] and why isn't that support just built-in to sane-backends in the first place ?! [16:37] Keybuk, ugh, no more RUN ? ltspfs kinda relies on that [16:37] ogra: does it edit files from a RUN rule? [16:38] 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] tkamppeter: won't work on boot [16:38] also *PLEASE* do NOT set OWNER [16:38] really, don't [16:39] that's reserved for other rules, just set GROUP [16:40] 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] then upstream is wrong [16:40] we can patch it in Ubuntu [16:40] bug #319660 [16:40] Launchpad bug 319660 in hplip "Cannot edit configuration from udev rules" [Undecided,New] https://launchpad.net/bugs/319660 [16:41] bug #319661 [16:41] Launchpad bug 319661 in hplip "Must not set OWNER in udev rules" [High,New] https://launchpad.net/bugs/319661 [16:42] bug #319662 [16:42] Launchpad bug 319662 in hplip "udev rules should be 40-*.rules unless there's a good reason" [High,New] https://launchpad.net/bugs/319662 [16:42] tkamppeter: assigned them to you [16:42] cjwatson, it runs scripts that create files [16:42] note that Ubuntu's udev is completely pristine [16:43] we have no patches to upstream udev [16:43] and we only ship the upstream udev rules [16:43] without modification [16:43] therefore your upstream is also wrong, they should match the default udev upstream [16:43] 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] not the strange configuration of other distributions [16:43] tkamppeter: then please drop the RUN rule [16:47] tkamppeter: oh, I have yet more bugs [16:47] you use SYSFS{...} [16:47] that should be ATTR{...} [16:48] bug #319665 [16:48] Launchpad bug 319665 in hplip "Uses deprecated SYSFS instead of ATTR" [Undecided,New] https://launchpad.net/bugs/319665 [16:50] 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] Keybuk, I will add an upstream task then and ask them to use the new UDEV rules file. [16:52] tkamppeter: if you hadn't had deleted the file I uploaded, you wouldn't need to [16:52] I'm sure you can retrieve it from Launchpad [16:52] old source packages and builds are made available from there [16:52] you probably even have the .dsc and .diff.gz in your working directory [16:53] Keybuk, sorry, I simply followed the policy of taking as much as possible from upstream ... [16:53] since assumedly you downloaded it, then deleted the correct file out of it to replace it with your incorrect one [16:53] we don't have a policy [16:53]