[01:53] <frojasg> hi guys
[01:54] <bdmurray> hello frojasg
[01:54] <frojasg> i have a question
[01:55] <bdmurray> okay
[01:57] <frojasg> recently i following  this guide for install cyrus imap in hardy
[01:57] <frojasg> https://help.ubuntu.com/community/Cyrus
[01:57] <frojasg> and don't work .... i can't make a connection with the server
[01:59] <frojasg> i thinks maybe be a bug for hardy .... because in gutsy work without problem
[02:00] <frojasg> but i don't know very well, what it's the problem
[02:02] <bdmurray> hmm
[02:03] <bdmurray> so you can't telnet to the local host?
[02:04] <frojasg> no ... throw this error "BYE Fatal error: can't write proc file"
[02:08] <bdmurray> hmm, I'll try and recreate it in a bit
[02:11] <frojasg> thanks a lot bdmurray
[02:38] <frojasg> bdmurray: i fix the problem
[02:44] <frojasg> anyway ... the package have a bug ... have the wrong privilege  in /var/spool/cyrus and /var/lib/cyrus
[03:38] <danage> hey, can someone fix the firefox-crash-on-flash bug please?
[03:47] <crimsun> danage: 192888?
[03:49] <danage> yes!
[03:49] <crimsun> danage: for hardy, about as much as can be done already has been.
[03:50] <danage> oww
[03:50] <danage> deinstalling pulseaudio doesn't help though i read?
[03:50] <crimsun> danage: you need to tell me more about your specific configuration.
[03:50] <danage> i have ff3 b5 plus libflashsupport
[03:51] <crimsun> that bug has way too many responses; most of them are completely irrelevant to the issue at hand (which is the symptom described in the subject of the bug report)
[03:51] <crimsun> and is your install amd64 or i386?
[03:51] <danage> i386
[03:51] <crimsun> you have several options, then.
[03:52] <danage> yes i agree and that's why i never started to try solving is, because a lot of the solutions seemed to contradict each others
[03:52] <crimsun> 1) remove libflashsupport and change pulseaudio's /etc/pulse/default.pa config.
[03:52] <crimsun> 2) use the modified nspluginwrapper deb with support for i386.
[03:52] <crimsun> 3) remove flashplugin-nonfree altogether.
[03:53] <danage> what would you recommend?
[03:53] <danage> i do want flash
[03:53] <danage> doesn't have to be nonfree
[03:53] <danage> if you say the oss flash is ok, i can use that
[03:53] <crimsun> um, well, I'm a bit biased, since I've spent a tremendous amount of time triaging that bug and making workarounds.
[03:53] <danage> not biased, but the best person to ask i would say
[03:54] <crimsun> the one with the least amount of fallout is likely (2).
[03:54] <danage> ok to you have url with instructions?
[03:54] <crimsun> no, but there's bound to be one in that bug report
[03:55] <crimsun> frankly I think that the instability is unfortunate and that we should work around it by adapting pulseaudio's /etc/pulse/default.pa config.
[03:56] <danage> i can't find it
[03:56] <crimsun> a great many applications broke by way of our having PA grab raw hw:
[03:56] <danage> i saw a blueprint "solve linux sound woes altogether once and for all"
[03:56] <danage> i would TOTALLY support that :)
[03:56] <crimsun> yeah, that's utter bunk, because no one can do that.
[03:56] <danage> why not?
[03:57] <crimsun> we already have to support legacy systems - both OSS/Free, and ALSA, and OSSv4.x - and regardless how one considers it, any approach will break someone's install.
[03:57] <danage> well, we all have to make sacrifices
[03:58] <danage> people with "legacy" install will have to adapt
[03:58] <crimsun> it's very simple to say that when one doesn't have to make the choice or triage the bugs.
[03:58] <danage> haha, yes
[03:59] <crimsun> I'll be committing backend packaging changes to bzr pretty soon that make it possible to drop in any one of OSSv4.x and ALSA and have things work fairly well (i.e., some stuff will break, but I'll try to clean up the mess as much as possible)
[04:00] <danage> cool
[04:00] <danage> sounds like a good solution
[04:00] <crimsun> no, it sounds like a PITA.
[04:00] <crimsun> unfortunately, there will never be One True Way.
[04:01] <danage> compromise, then
[04:01] <danage> btw, can you enlighten me on backports? is that the way to keep hardy updating?
[04:01] <bdmurray> frojasg: it'd be good to report that then if it hasn't been reported already
[04:01] <crimsun> danage: "the" way?  I don't know.
[04:02] <crimsun> danage: I don't know your use cases or requirements, for starters.
[04:02] <danage> for the average user that wants to benefit from continuing bugfixes and development
[04:02] <danage> (=my case) :)
[04:02] <frojasg> bdmurray: ok, now i going to report it ... ﻿again  thanks a lot :D
[04:04] <crimsun> danage: i.e., you plan to retain 8.04 but wish to have newer versions of packages from what-will-become-8.10?  Then yes, backports is probably your best bet.
[04:05] <danage> or can i do distro upgrade already?
[04:05] <crimsun> I really, strongly recommend that you do not dist-upgrade to intrepid currently.
[04:06] <danage> :) ok
[04:06] <danage> then, backports it is for now
[04:09] <gravemind> hey, this bug is keeping me from upgrading to hardy, what should I do? https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/222278
[04:09] <danage> thanks crimsun
[06:12] <tbielawa> does bughelper work for anyone running hardy?
[08:47] <iulian> G'morning
[10:19] <nikolaj> Hi, I'm total new... So is this forum too add the bug you find in Ubuntu?
[10:21] <jpatrick> nikolaj: you can file one at https://bugs.launchpad.net/ubuntu/+filebug
 Thanks I will read it now
 it say's that you must be loged on
[10:24] <jpatrick> nikolaj: yes, register on Launchpad first
[10:56] <nikolaj> The bug I found Bug #226073
[11:20] <qense> hello
[11:21] <iulian> Hey qense
[11:27] <qense> are there already many new important bugs reported in hardy after the release?
[13:28] <qense> do you think bug 225326 contains enough information? I can't find that much in kern.log Maybe it would be good to try the debuggin mode
[15:38] <mrooney> bdmurray: around, by any chance?
[17:04] <Salumu> hi persia, could you make any comments about how gdb works when attached on a running process?
[17:05] <persia> Salumu: I'm not deeply familiar with that, but I'm haoppy to answer questions.
[17:07] <Salumu> persia, right, I was attending the OpenWeek session you made, and I wanted to know more about how to prevent a program from being debugged
[17:07] <persia> Preventing a program from being debugged?  Why would you want to do that?
[17:08] <Salumu> In case I'd like to prevent people from reverse engineering it for instance
[17:09] <Salumu> I heard that some people use debuggers to learn more about how a program works
[17:09] <awalton__> Salumu, anything they could learn from a debugger they could learn from the code itself.
[17:09] <awalton__> code armoring/obfuscation is completely a different issue.
[17:09] <pochu> unless he doesn't intend to release the code...
[17:10] <Salumu> pochu is right, I assume that I didn't intend to release the code indeed
[17:11] <Salumu> awalton__, do you have any hints on code armoring?
[17:11] <awalton__> other than google is your friend, not really.
[17:12] <awalton__> it's not a very widely practiced thing I don't think.
[17:12] <awalton__> you see it more in .net/java/byte-code interpreted languages though
[17:14] <Salumu> awalton__, thanks for the hints :)
[17:14] <afflux> morning
[17:26] <afflux> waaaaaaaaaaaaaah. I gotta end my life :(. I just lost my old home partition by backing it up on an encrypted partition and formatting the partition that contained the keyfile. That's the price for working while actually sleeping.
[17:30] <persia> afflux: Are you sure you're encryption is that annoying?  You might be able to recover your data with about six months of brute-force analysis (unless you picked a truly huge key size), and you might get lucky.
[17:31]  * persia is guessing that your current life expectancy > 6 months, as part of the relative cost/benefit analysis
[17:31] <afflux> hehe
[17:31] <afflux> persia: not sure. It's aes-lrw-benbi using a password longer than 20 chars and all kind of special chars (in the ASCII range though)
[17:33] <afflux> note that I have a password in it, but didn't use it since about 2 years (because of the keyfile) so I just can't recall it
[17:33] <persia> That's likely less than 160 bits.  About 10^16 permutations.  Depends on how many permutations your hardware can do a second: there's about 6/7 of 10^5 seconds in a day, so if you can get 10^10 permutations, you ought get in within a week or so.
[17:33] <persia> (errr...  10^10 permutations/sec)
[17:34] <afflux> could be worth a try
[17:34] <persia> Umm.  Sorry, 10^19.  You want to get at last 10^12 permutations/second to get back in a reasonable timeframe.
[17:35] <persia> (or maybe it's late for me, and I can't do math: ask a calculator how long it will take once you find out how fast you can hack it)
[17:35] <afflux> will do
[17:40] <afflux> persia: ugh. did 50 test runs, took ~90secs :(
[17:40] <persia> afflux: That's not fast enough :(
[17:41] <afflux> not really
[17:41] <persia> (unless you get really lucky)
[17:42] <persia> You might get more speed by digging out the handler, and using that as a code base, rather than scripting something.  Feed the challenge-response directly, and pull any timeout or delay code.
[19:04] <nealmcb> bdmurray: re: https://wiki.ubuntu.com/MeetingLogs/openweekhardy/ReportBugs2 - there is  link there to https://bugs.edge.launchpad.net/ubuntu/+source/reportbug-ng/+bug/175508 - perhaps the wiki writer thought the session would be about the tool, which I guess was not the case, but can someone change the importance of that bug?  As several have pointed out, it isn't a wishlist item
[19:07] <bdmurray> nealmcb: interesting, thanks
[19:08] <nealmcb> bdmurray: thanks for your talk!
[19:09] <bdmurray> nealmcb: thanks, I hope it was useful