[00:01] <calc> Mirv: if you can please file a bug (if it doesn't exist) targeted to 8.04.1 to update voikko
[00:02] <slangasek> s/targeted to 8.04.1/targeted to the hardy release/
[00:02] <calc> slangasek: oh ok
[00:03] <slangasek> well - in this case, probably both
[00:03] <slangasek> but target it to the hardy release first :)
[00:31] <wgrant> Uh, why is there a private bug referenced in the -intel changelog?
[00:32] <cjwatson> nothing wrong with referencing private bugs from changelogs as such - what use are private bugs if you can never fix them? :-)
[00:32] <wgrant> cjwatson: What use is referencing bugs in changelogs if people can't look at them?
[00:32] <cjwatson> I assume it relates to hardware whose existence or codename or whatever isn't public yet
[00:33] <cjwatson> it's useful for those people who do have access to the bugs to have a record of when they were fixed
[00:33] <cjwatson> bug references are as much for archaeology as anything else
[00:33] <wgrant> 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] <cjwatson> for an SRU, I think there ought to be a public counterpart bug
[00:34] <cjwatson> with whatever information can be disclosed
[00:34] <wgrant> Right, people might actually want to see what this change is doing to all of their systems.
[00:34] <cjwatson> 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] <wgrant> If there was a public one as well, that would be OK.
[00:35] <cjwatson> though the changelog is fairly descriptive otherwise
[00:35] <cjwatson> bryce: ^- just to draw your attention to the above conversation
[00:36] <bryce> cjwatson: thanks
[00:37] <cjwatson> in fact looking at it the changelog is almost more descriptive than the bug report in most ways ;-)
[00:37] <cjwatson> (though there is legitimately private stuff in the report)
[00:37] <bryce> yeah
[00:37] <wgrant> But we're not to know that.
[00:37] <cjwatson> indeed
[00:38] <bryce> yeah I've been rather torn on how to handle these kinds of bugs
[00:38] <bryce> so would welcome advice
[00:38] <cjwatson> for intrepid, I'm not sure it's a big deal
[00:38] <cjwatson> for SRUs, I think a public counterpart bug is probably a good compromise
[00:38] <wgrant> For Intrepid, sure, people won't be wanting to watch every bug for every update.
[00:39] <cjwatson> we used to do that for SRUs much more commonly - we'd file a new bug just for the SRU request
[00:39] <cjwatson> nowadays we tend to reuse the original bug
[00:39] <cjwatson> but for this case, we could go back to the older fashion
[00:39] <bryce> 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] <cjwatson> it's generally a waste of bug numbers :-)
[00:39] <wgrant> bryce: This is a rather different case.
[00:39] <bryce> (and time)
[00:39] <wgrant> cjwatson: And it splits the useful information away from the SRU bug where users would look.
[00:40] <cjwatson> indeed
[00:40] <cjwatson> 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] <cjwatson> note that not all the sru-verification members are Canonical staff and so they are not subject to NDAs
[00:41] <bryce> 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] <bryce> so they finally did... but marked it private and a security issue (which I removed)
[00:42] <slangasek> heh, win
[00:42] <slangasek> :-)
[00:42] <wgrant> bryce: One cannot file a private non-security bug.
[00:42] <kees> much to my sadness
[00:42] <wgrant> Poor security team :(
[00:43] <kees> and one can't unsub ubuntu-security unless you're a member of it.
[00:43] <bryce> eesh
[00:43] <kees> but I'm used to identifying them and unsub'ing myself
[00:43] <bryce> and if you file a public bug and then mark it private, it auto-subs two dozen people
[00:43] <kees> yup
[00:43] <bryce> ah, well at least now I've learned how to file private bugs from the start
[00:44] <wgrant> bryce: It doesn't autosub anybody...
[00:44] <cjwatson> bryce: auto-sub is sort of irrelevant there though, if you file public and then mark as private
[00:44] <sistpoty> wgrant: hm? what about apport bugs? aren't these private by default?
[00:44] <cjwatson> (or "also notified" or whatever)
[00:44] <cjwatson> bryce: if you file a public bug, it sends bugmail out to a public mailing list :-)
[00:44] <wgrant> bryce: Only explicit subscriptions are used in a private bug - implicit subscriptions are excluded.
[00:44] <wgrant> sistpoty: I'm not sure how it does that. Not through the main web UI, at any rate.
[00:44] <bryce> cjwatson: well I couldn't see any other mechanism for filing private bugs
[00:44] <sistpoty> wgrant: heh, k
[00:45] <cjwatson> bryce: right, I'm just explaining why making the subscription behave differently wouldn't help
[00:45] <cjwatson> can't unsend the mail when you mark it private ;-)
[00:46] <cjwatson> (and yeah, I'd seen the earlier conversation along the same lines)
[00:46] <wgrant> cjwatson: LP normally batches bugmail 5-minutely. Does marking it private in the first 5 minutes not do it?
[00:46] <cjwatson> 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] <bryce> 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] <cjwatson> plus what if your ADSL line decides to die at that point?
[00:47] <cjwatson> bryce: I agree; kiko seemed amenable to doing something about that
[00:47] <cjwatson> but I have it on my list to raise for Launchpad planning purposes anyway
[00:47] <bryce> at least I know the workaround though (not that I file many private bugs - first one ever was just the other day)
[00:48] <wgrant> Bug #121859
[00:51] <bryce> cjwatson: so for future reference with private sru's, I should post a new public bug with the private info redacted?
[00:52] <bryce> 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] <cjwatson> 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] <cjwatson> public> but of course not demanding that they post private information in public :-)
[00:53] <bryce> yeah, also because I may not be a good judge of what info exactly is to be considered private
[00:56] <slangasek> kirkland: looks like grub FTBFS now in intrepid, on amd64 only; could you try to reproduce this when you have a chance?
[01:01] <calc> isn't google calendar supposed to be read/write in hardy now?
[01:01] <calc> er inside evolution
[01:16] <Daviey> calc: works in with opensync
[01:17] <Daviey> calc: Bug #197972 was the problem before
[01:18] <Daviey> or _a_ problem at least
[01:20] <slangasek> well, evolution also knows about 'google' as a calendar type, not using opensync; I guess that's what calc refers to
[01:23] <Daviey> my bad.. I don't use evo very often.
[01:58] <Amaranth> http://www.ubuntu.com/getubuntu/download is broken, not sure where to report this
[02:02] <wgrant> Amaranth: Bug on ubuntu-website in general, but this is probably a bit too important.
[02:03] <Amaranth> i mean, it'll still download, but only from releases.ubuntu.com
[02:03] <Amaranth> which can mess with people's quotas and generally cause slow downs
[02:04] <wgrant> And it looks awful.
[02:04] <Amaranth> that too
[08:06] <Erick> anyone in here?
[08:06] <Hobbsee> Erick: no
[08:07] <Erick> 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] <Erick> I am a translater
[08:07] <Hobbsee> Erick: #launchpad knows the details on translations, i think.
[08:07] <Hobbsee> but it is a weekend, so i'm not sure who's around
[08:22] <arthur-> pitti: I will have a look, thanks
[08:23] <andrew_sayers> 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] <andrew_sayers> i.e. making password authentication contingent on an educated user choice, independent of administrators.
[08:25] <Hobbsee> andrew_sayers: ask cjwatson sometime during european working hours.
[08:26] <andrew_sayers> Yeah, I guess I should have dreamed the idea up yesterday :)
[09:11] <cjwatson> 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] <andrew_sayers> cjwatson: Couldn't they put something in /etc/skel then?
[09:12] <cjwatson> 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] <cjwatson> I just don't think it's an appropriate default
[09:13] <andrew_sayers> Hmm, fair enough.  So should I submit a feature request, and if so, where?
[09:14] <cjwatson> 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] <andrew_sayers> Okay, will do.
[09:14] <andrew_sayers> Incidentally, is there any way of making one username an alias for another in sshd_config?
[09:14] <cjwatson> and presumably you mean without disabling *local* password auth?
[09:15] <cjwatson> because if you want that too, just give the account no password
[09:15] <cjwatson> (a locked password, I mean)
[09:15] <andrew_sayers> Yeah, I'm thinking about clueless users installing SSHD then getting dictionary-attacked.
[09:16] <andrew_sayers> Basically a way for users to enable/disable PasswordAuthentication for their own account.
[09:17] <cjwatson> I don't think there's a way to alias users, no. Feels like something you should use PAM for
[09:17] <andrew_sayers> Hmm, okay.
[09:20] <andrew_sayers> 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] <andrew_sayers> Right, last suggestion on the topic: when installing openssh-server after installation-time, how about asking whether to allow password auth?
[09:21] <andrew_sayers> (which I assume it doesn't right now)
[09:52] <kestaz> ReschedulingInterrupts.. any success to fix ?
[09:54] <Mirv> calc: done, bug #236248 , I guess I don't have other rights besides nominating for hardy
[09:55] <Mirv> (I should probably join the bugs team)
[10:13] <asac> Mirv: could you please test and comment on 219655 ... thanks!
[10:25] <Mirv> asac: yep, tested on two machines and seems to be great now
[10:30] <asac> Mirv: thanks. please keep using it ;)
[10:30] <asac> Mirv: there was another bug about finish URLs not working properly. you remember that?
[10:31] <asac> finnish
[10:31] <asac> ;)
[10:31] <asac> Mirv: its 221376
[10:31] <asac> do you still see that?
[10:37] <Mirv> 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] <Mirv> 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] <asac> wierd
[10:41] <Mirv> disabling xulrunner translation doesn't change anything, but apparently something in the firefox translation disables google search from location bar
[10:42] <asac> Mirv: could you post your thoughts to the bug? they sound promissing and might help to find the real problem
[10:43] <Mirv> yeah, I posted already something
[10:45] <Mirv> changed now also the description
[10:52] <asac> Mirv: ok i reassigned it to new (non-gnome) package as well.
[12:22] <renegade444> 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] <jpds> !packguide | renegade444
[12:25] <jpds> gah, bot down
[12:25] <bimberi> renegade444: https://wiki.ubuntu.com/PackagingGuide/Complete
[12:25]  * bimberi is not a bot btw ;)
[12:25] <renegade444> ahh, perfect, thank you very much!
[12:47] <RicardoPerez> pitti: has you received my email about firefox problems in proposed langpacks?
[13:04] <math_b> Hi, I'm trying to package something which provide a python library, should I use pycentral or pysupport ?
[13:10] <Festor> math_b, #ubuntu-motu
[13:11] <math_b> Festor: thanls
[13:50] <garnm> hi
[13:50] <garnm> does ubuntu have a recovery option?
[13:50] <garnm> its not universe and multiverse deb is it
[13:51] <Festor> recovery option = recovery mode?
[13:51] <garnm> yes
[13:52] <Festor> then yes
[13:52] <jpds> garnm: it's in grub when you boot
[13:52] <garnm> oh thanks a bunch
[13:53] <garnm> is it in grub?
[13:53] <garnm> ok you guys cant be wrong here
[13:54] <jpds> garnm: when you boot, press "Esc" and it's in the menu
[13:55] <garnm> gotcha
[13:55] <garnm> thanks, sorry
[17:45] <sistpoty> 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
[18:31] <qaws> hi, do you know LTS has broken dependencies? (at least for my language)
[18:35] <persia> 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.
[22:49] <emgent> heya
[23:28] <jelmer> info
[23:33] <calc> anyone know what happened to cinepaint? it seemed to be removed from hardy?
[23:33] <calc> was it replaced by something else?
[23:43]  * danshearer is away: Zzzz
[23:52] <wgrant> calc: IIRC there is no replacement, and it was removed for being a dead, buggy thing.
[23:52]  * wgrant checks.
[23:52] <wgrant> '(From Debian) RoM ; obsolete, buggy, unmaintained, being abandoned upstream'
[23:53] <ion_> danshearer: Thanks a lot for the information!
[23:54] <ion_> A future version of Gimp will use GEGL and thus support >8-bit colorspace.
[23:54] <wgrant> 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] <wgrant> ion_: That's happening RSN, isn't it?
[23:55] <ion_> wgrant: AFAIK they’re been hacking the development branch of Gimp to use it for a while now.
[23:55] <ion_> So, the next major Gimp release probably has it.
[23:56] <Lightkey> 2.5 has been released already
[23:56] <Lightkey> err, 2.5.0
[23:57] <ion_> Oh, neat.
[23:58] <wgrant> ion_: That's what I thought.