[00:01] Mirv: if you can please file a bug (if it doesn't exist) targeted to 8.04.1 to update voikko [00:02] s/targeted to 8.04.1/targeted to the hardy release/ [00:02] slangasek: oh ok [00:03] well - in this case, probably both [00:03] but target it to the hardy release first :) [00:31] Uh, why is there a private bug referenced in the -intel changelog? [00:32] nothing wrong with referencing private bugs from changelogs as such - what use are private bugs if you can never fix them? :-) [00:32] cjwatson: What use is referencing bugs in changelogs if people can't look at them? [00:32] I assume it relates to hardware whose existence or codename or whatever isn't public yet [00:33] it's useful for those people who do have access to the bugs to have a record of when they were fixed [00:33] bug references are as much for archaeology as anything else [00:33] I guess, but I don't like this idea of SRUs happening completely in secret, with no information even after they occur and break everybody's systems. [00:33] for an SRU, I think there ought to be a public counterpart bug [00:34] with whatever information can be disclosed [00:34] Right, people might actually want to see what this change is doing to all of their systems. [00:34] I still see no reason not to reference the private bug as well - you're no worse off than if the changelog hadn't referred to it at all [00:35] If there was a public one as well, that would be OK. [00:35] though the changelog is fairly descriptive otherwise [00:35] bryce: ^- just to draw your attention to the above conversation [00:36] cjwatson: thanks [00:37] in fact looking at it the changelog is almost more descriptive than the bug report in most ways ;-) [00:37] (though there is legitimately private stuff in the report) [00:37] yeah [00:37] But we're not to know that. [00:37] indeed [00:38] yeah I've been rather torn on how to handle these kinds of bugs [00:38] so would welcome advice [00:38] for intrepid, I'm not sure it's a big deal [00:38] for SRUs, I think a public counterpart bug is probably a good compromise [00:38] For Intrepid, sure, people won't be wanting to watch every bug for every update. [00:39] we used to do that for SRUs much more commonly - we'd file a new bug just for the SRU request [00:39] nowadays we tend to reuse the original bug [00:39] but for this case, we could go back to the older fashion [00:39] I've gotten scolded for filing new bugs just for putting in sru's ... which is why I didn't do it in this case [00:39] it's generally a waste of bug numbers :-) [00:39] bryce: This is a rather different case. [00:39] (and time) [00:39] cjwatson: And it splits the useful information away from the SRU bug where users would look. [00:40] indeed [00:40] another reason to have a separate public report is so that the SRU verification team can see it without having to expose private information to them [00:41] note that not all the sru-verification members are Canonical staff and so they are not subject to NDAs [00:41] in this case it was a bit annoying in that I'd gotten the patch outside launchpad, and specifically asked them to file a bug as a necessary step to getting an sru [00:41] so they finally did... but marked it private and a security issue (which I removed) [00:42] heh, win [00:42] :-) [00:42] bryce: One cannot file a private non-security bug. [00:42] much to my sadness [00:42] Poor security team :( [00:43] and one can't unsub ubuntu-security unless you're a member of it. [00:43] eesh [00:43] but I'm used to identifying them and unsub'ing myself [00:43] and if you file a public bug and then mark it private, it auto-subs two dozen people [00:43] yup [00:43] ah, well at least now I've learned how to file private bugs from the start [00:44] bryce: It doesn't autosub anybody... [00:44] bryce: auto-sub is sort of irrelevant there though, if you file public and then mark as private [00:44] wgrant: hm? what about apport bugs? aren't these private by default? [00:44] (or "also notified" or whatever) [00:44] bryce: if you file a public bug, it sends bugmail out to a public mailing list :-) [00:44] bryce: Only explicit subscriptions are used in a private bug - implicit subscriptions are excluded. [00:44] sistpoty: I'm not sure how it does that. Not through the main web UI, at any rate. [00:44] cjwatson: well I couldn't see any other mechanism for filing private bugs [00:44] wgrant: heh, k [00:45] bryce: right, I'm just explaining why making the subscription behave differently wouldn't help [00:45] can't unsend the mail when you mark it private ;-) [00:46] (and yeah, I'd seen the earlier conversation along the same lines) [00:46] cjwatson: LP normally batches bugmail 5-minutely. Does marking it private in the first 5 minutes not do it? [00:46] wgrant: it might do, I wouldn't like to swear to it. For example is it every five minutes by cron or five minutes from each action? Not something I've ever bothered to verify [00:46] it might be nice for further discussion... but really my complaint is just that it's not obvious how to file a private bug [00:47] plus what if your ADSL line decides to die at that point? [00:47] bryce: I agree; kiko seemed amenable to doing something about that [00:47] but I have it on my list to raise for Launchpad planning purposes anyway [00:47] at least I know the workaround though (not that I file many private bugs - first one ever was just the other day) [00:48] Bug #121859 [00:48] Launchpad bug 121859 in malone "RFE: Url for posting private, non-security bugs" [Undecided,New] https://launchpad.net/bugs/121859 [00:51] cjwatson: so for future reference with private sru's, I should post a new public bug with the private info redacted? [00:52] I've let the reporter know that they should post sru bugs public in the future, since I expect we may be getting more like this from them. [00:52] bryce: I think that's the best option for the time being; maybe remind me on Monday to talk about it with pitti and we'll get the policy adjusted [00:52] public> but of course not demanding that they post private information in public :-) [00:53] yeah, also because I may not be a good judge of what info exactly is to be considered private [00:56] kirkland: looks like grub FTBFS now in intrepid, on amd64 only; could you try to reproduce this when you have a chance? [01:01] isn't google calendar supposed to be read/write in hardy now? [01:01] er inside evolution [01:16] calc: works in with opensync [01:17] calc: Bug #197972 was the problem before [01:17] Launchpad bug 197972 in libopensync-plugin-google-calendar "Doesn't handle recurring events in google cal" [Undecided,Fix released] https://launchpad.net/bugs/197972 [01:18] or _a_ problem at least [01:20] well, evolution also knows about 'google' as a calendar type, not using opensync; I guess that's what calc refers to [01:23] my bad.. I don't use evo very often. [01:58] http://www.ubuntu.com/getubuntu/download is broken, not sure where to report this [02:02] Amaranth: Bug on ubuntu-website in general, but this is probably a bit too important. [02:03] i mean, it'll still download, but only from releases.ubuntu.com [02:03] which can mess with people's quotas and generally cause slow downs [02:04] And it looks awful. [02:04] that too === iceman-away is now known as iceman === asac_ is now known as asac [08:06] anyone in here? [08:06] Erick: no [08:07] Hobbsee hey i have a question i've been actived. on the launchpad.net for ubuntu how do i become part of the Project? [08:07] I am a translater [08:07] Erick: #launchpad knows the details on translations, i think. [08:07] but it is a weekend, so i'm not sure who's around [08:22] pitti: I will have a look, thanks [08:23] Would I get laughed out of launchpad for requesting that by default, openssh-server only allow password logins from users with a ~/.ssh/allow_passwords file? [08:24] i.e. making password authentication contingent on an educated user choice, independent of administrators. [08:25] andrew_sayers: ask cjwatson sometime during european working hours. [08:26] Yeah, I guess I should have dreamed the idea up yesterday :) === elky is now known as elkbuntu [09:11] andrew_sayers: not laughed out as such. I think something like that might be a useful feature, but I don't think it'd be appropriate for a default; too many sysadmins bootstrap new accounts using password auth [09:12] cjwatson: Couldn't they put something in /etc/skel then? [09:12] I'm sure they could but it would be another way in which Debian/Ubuntu deviated from upstream thereby causing confusion and requests for help (which I expect I'd have to field) [09:13] I just don't think it's an appropriate default [09:13] Hmm, fair enough. So should I submit a feature request, and if so, where? [09:14] perhaps file a bug on bugzilla.mindrot.org (upstream) asking for the basic feature of allowing users to turn password auth on or off for their own account [09:14] Okay, will do. [09:14] Incidentally, is there any way of making one username an alias for another in sshd_config? [09:14] and presumably you mean without disabling *local* password auth? [09:15] because if you want that too, just give the account no password [09:15] (a locked password, I mean) [09:15] Yeah, I'm thinking about clueless users installing SSHD then getting dictionary-attacked. [09:16] Basically a way for users to enable/disable PasswordAuthentication for their own account. [09:17] I don't think there's a way to alias users, no. Feels like something you should use PAM for [09:17] Hmm, okay. [09:20] I'm still working on a remote help assistant, and the solution I've come up with seems pretty secure to me, except that it increases the probability that helpers will set up bad ssh servers. [09:21] Right, last suggestion on the topic: when installing openssh-server after installation-time, how about asking whether to allow password auth? [09:21] (which I assume it doesn't right now) === hunger_t is now known as hunger [09:52] ReschedulingInterrupts.. any success to fix ? [09:54] calc: done, bug #236248 , I guess I don't have other rights besides nominating for hardy [09:54] Launchpad bug 236248 in openoffice.org-voikko "Rebuild openoffice.org-voikko for the 2.4.1 upload of openoffice.org" [Undecided,New] https://launchpad.net/bugs/236248 [09:55] (I should probably join the bugs team) === gordon is now known as Guest15137 === gnomefre1k is now known as gnomefreak [10:13] Mirv: could you please test and comment on 219655 ... thanks! [10:25] asac: yep, tested on two machines and seems to be great now [10:30] Mirv: thanks. please keep using it ;) [10:30] Mirv: there was another bug about finish URLs not working properly. you remember that? [10:31] finnish [10:31] ;) [10:31] Mirv: its 221376 [10:31] do you still see that? [10:37] asac: yes, that one is still there. apparently the problem is that with language pack disabled search bar calls google search, but with language pack enabled it just tries to load www.[typedtext].com [10:38] I'm not sure but I don't think there's anything specifically related to scandinavian letters like stated in the bug report, since it does the same (does not google search) for any text I type in the location bar [10:40] wierd [10:41] disabling xulrunner translation doesn't change anything, but apparently something in the firefox translation disables google search from location bar [10:42] Mirv: could you post your thoughts to the bug? they sound promissing and might help to find the real problem [10:43] yeah, I posted already something [10:45] changed now also the description [10:52] Mirv: ok i reassigned it to new (non-gnome) package as well. === fta_ is now known as fta [12:22] Hi, I apologize for asking here, but nobody in #ubuntu was able to give me an answer, and I thought someone here might be more likely to know the answer. I'm trying to find a guide to making ubuntu-specific binary .deb packages from source, but I can only find a guide for 6.10 on help.ubuntu.com. My question is: Does that guide fully apply to 8.04? If not is there an 8.04 guide out there I just can't find? [12:25] !packguide | renegade444 [12:25] gah, bot down [12:25] renegade444: https://wiki.ubuntu.com/PackagingGuide/Complete [12:25] * bimberi is not a bot btw ;) [12:25] ahh, perfect, thank you very much! [12:47] pitti: has you received my email about firefox problems in proposed langpacks? [13:04] Hi, I'm trying to package something which provide a python library, should I use pycentral or pysupport ? [13:10] math_b, #ubuntu-motu [13:11] Festor: thanls [13:50] hi [13:50] does ubuntu have a recovery option? [13:50] its not universe and multiverse deb is it [13:51] recovery option = recovery mode? [13:51] yes [13:52] then yes [13:52] garnm: it's in grub when you boot [13:52] oh thanks a bunch [13:53] is it in grub? [13:53] ok you guys cant be wrong here [13:54] garnm: when you boot, press "Esc" and it's in the menu [13:55] gotcha [13:55] thanks, sorry === [20]_Cent is now known as zwanzigcent [17:45] hm... what build target does LP actually invoke? (as this one puzzles me, since build-depends-indep weren't installed, but only the indep part actually needs them, which gets somehow invoked: http://launchpadlibrarian.net/14622202/buildlog_ubuntu-intrepid-amd64.hs-plugins_1.2-1_FAILEDTOBUILD.txt.gz === Hobbsee is now known as Guest78382 [18:31] hi, do you know LTS has broken dependencies? (at least for my language) [18:35] qaws: There are likely quite a few. These are best encoded as bugs. If you have fixes, that would be welcome. Be sure to nominate for your release as they likely qualify for a stable release update. === blueyed_ is now known as blueyed [22:49] heya === smarter_ is now known as smarter === J-Unit is now known as jdong [23:28] info [23:33] anyone know what happened to cinepaint? it seemed to be removed from hardy? [23:33] was it replaced by something else? [23:43] * danshearer is away: Zzzz [23:52] calc: IIRC there is no replacement, and it was removed for being a dead, buggy thing. [23:52] * wgrant checks. [23:52] '(From Debian) RoM ; obsolete, buggy, unmaintained, being abandoned upstream' [23:53] danshearer: Thanks a lot for the information! [23:54] A future version of Gimp will use GEGL and thus support >8-bit colorspace. [23:54] calc: Seems it was partly because it was a GTK1 rdepend, but there is now a GTK2 version so it may be making a reappearance. [23:54] ion_: That's happening RSN, isn't it? [23:55] wgrant: AFAIK they’re been hacking the development branch of Gimp to use it for a while now. [23:55] So, the next major Gimp release probably has it. [23:56] 2.5 has been released already [23:56] err, 2.5.0 [23:57] Oh, neat. [23:58] ion_: That's what I thought.