[00:23] <Bluefoxicy> tar xzf ale.tar.gz
[00:23] <Bluefoxicy> cd ale
[00:23] <Bluefoxicy> make beer
[04:05] <xnox> recompression finished.
[04:06] <xnox> one data result got lost in hdfs
[04:06] <xnox> results here: http://people.canonical.com/~xnox/hadoopresults/
[04:06] <xnox> will analyse later
[12:25] <pcarrier> he
[12:26] <pcarrier> it might be obvious, but I'm new to launchpad. I'd like to try to add my patch on top of precise's php5, and I cannot find the precise maintenance branch for a package
[12:27] <pcarrier> not sure if there's a generic way to do that at all actually, but I hop so
[12:27] <pcarrier> it happens to be for php5 ( https://launchpad.net/ubuntu/precise/+source/php5 ), but that's a one-off
[12:28] <pcarrier> does somebody know where I can find such bzr branch (or git repo, or whatever is used?)
[12:28] <pcarrier> I'm more interested in how to find it, rather than being given the URI
[12:44] <arand> pcarrier: It tends to be lp:ubuntu/packagename for the development branch (currently quantal) and lp:ubuntu/distroseries/packagename for stable Ubuntu versions, though if there have been updates or security fixes there will be lp:ubuntu/distroseries-security/packagename branches which may be the latest.
[12:51] <pcarrier> arand++ thanks a lot
[12:51] <pcarrier> I need to note that down somewhere :)
[12:52] <pcarrier> oh, the classical debian mess. this package uses quilt.
[12:53] <arand> php5 has most of them, you can look at it from https://code.launchpad.net/ubuntu/+source/php5
[12:53] <arand> Um, isn't 3.0 (quilt) the standard format in Ubuntu as well?
[12:57]  * pcarrier has an issue with the mix of upstream git, distro bzr storing packaging quilt
[12:58]  * pcarrier dreams of a world where everything is just git, and everybody just uses branches and tags
[12:59] <pcarrier> you end up using bzr branch, git format-patch, quilt import, quilt refresh, dch -l, just to try out a simple change to a package
[13:50] <melodie_> hi
[16:01] <JoseeAntonioR> /mode #ubuntu-ops +b *!*@@ubuntu/member/jbicha$##fix_your_connection if you want to copy-paste
[16:01] <JoseeAntonioR> oops
[16:02] <JoseeAntonioR> wrong channel, guys, ignore that please
[16:19] <mneptok> err
[16:21] <JoseeAntonioR> mneptok: I think it should be a forwardban, to make sure once the connection prob is solved
[16:35] <mneptok> JoseeAntonioR: unable to set one. hence my "err"
[16:35] <JoseeAntonioR> :P
[16:36] <mneptok> ah, and now i know why
[18:39] <Debolaz> http://ihaveapc.com/2011/05/how-to-fix-problem-with-mergelist-varlibaptlists-error-in-ubuntu-11-04/ <- Stuff like this really shouldn't be an issue imho, is there any particular reason why it's not dealt with automatically by the system?
[18:44] <infinity> Debolaz: Errors like that only happen if your apt lists are replaced by junk (can sometimes happen behind a captive portal, for instance).  We have open bugs about it, and a variety of proposed solutions, if I recall.
[18:45] <Debolaz> infinity: It just happened to me and I'm not behind a captive portal.
[18:45] <infinity> Debolaz: What was the exact error?  And did you save the contents of /var/lib/apt/lists before blowing it away?
[18:45] <infinity> Debolaz: Not all bugs that look "similar" are actually the same, so having real data instead of pointing at a third-party blog post is kinda helpful. :/
[18:47] <Debolaz> infinity: No, it wiped and I've just rebooted the system. The problem was some translation thing from the official ubuntu repositiory (I say official, because I have some nonofficial repositories as well, just to clarify that it wasnt those causing it). It was that exact error though, just a different file. Wiping and redownloading solved the problem.
[18:48] <infinity> Knowing the contents of the file would be somewhat helpful, that's all.
[18:48] <infinity> To perhaps determine HOW this happened.
[18:49] <infinity> I won't disagree that perhaps apt could deal more gracefully with file corruption in some cases, but we really shouldn't be landing corrupted/broken files on disk in the first place.
[18:49] <Debolaz> infinity: If redownloading solved the issue, it seems to me that the problem wasn't serverside. The solution also seems easy: Have a file with hashes of the various other files downloaded, if a hash doesn't match, try to redownload it once.
[18:49] <infinity> (And the suggestion that apt should "just delete it and try again" is obviously a non-starter, because the original could actually be broken at the source, causing you to just loop through trying to "fix" it infinitely)
[18:50] <Debolaz> infinity: You don't have to loop, just try once, and if it doesn't work, report the error. This fixes the problem and avoids any issues.
[18:50] <infinity> Debolaz: That doesn't actually fix it for 99% of the use-cases where this breaks. :)
[18:50] <Debolaz> infinity: In the case of captive portals, it doesn't fix it no. But it doesn't make things worse, and it solves it for the rest of us.
[18:53] <Debolaz> infinity: I agree that it's relatively rare that it happens without someone intentionally messing with the data transferred like a captive portal would. But the solution to dealing with the non-intentional cases is very simple and doesn't do any damage.
[18:53] <infinity> Debolaz: It doesn't help in the case of broken transparent proxies of any sort, which is generally how the content gets "corrupt".
[18:53] <infinity> Debolaz: I think forcing the large majority of people who see this error to re-transmit, on the off chance that they're the tiny minority that would benefit from it, is entirely the wrong answer.
[18:54] <infinity> (We do, however, need to do a better job with invalidating broken content in general, though, which isn't about forcing a re-download, but just not using it at all)
[18:55] <Debolaz> infinity: Ok, let me ask you this question: Do you understand that no matter if the cause is a captive portal, or just a bad network, leaving the system in a state where it cannot update unless the user goes in and does something exceedingly technical from a newbie point of view, is a very bad thing?
[18:56] <infinity> Debolaz: No need to be condescending.  I acknowledge that it's something we need to fix, and we're looking into it.  I disagree with the proposed solution, that's all.
[18:57] <Debolaz> It just seems you are being intentionally dense about this, and that frustrates me a bit.
[18:57] <infinity> And now you're being insulting, along with the condescension.  Thanks.
[18:58] <Debolaz> Followup question of curiosity then: If this happens, lets say due to a captive portal or something similar, which is the likely cause of this error, will the system eventually recover over time without user interaction?
[18:59] <infinity> Probably not and, yes, we could look at a stop-gap to sort that out.
[19:01] <infinity> There are lots of nasty bugs out there.  This is one we're looking at.  Being insulting and condescending about it assumes that this is the *only* important bug, and we're clearly irresponsible for not having dedicated our lives to fixing it.
[19:02] <Debolaz> Hmmm…. This wouldn't really be a permanent solution to the problem, but at least it provides a simpler one than what seems to currently be the case: Have a program that removes all the files from the apt cache that aren't required to make it run. Possibly also calls other commands to repair things, basically just tries to reset the update system as much as possible.
[19:02] <Debolaz> Does this seem like something worthwhile to implement if someone was to volunteer?
[19:03] <infinity> If one was to try to do an automated tidy thing, I'd just piggyback it on the cron job that apt already has, and test for the known error conditions, wipe, retry, and give up after one retry, assuming the world is broke and it'll fix itself tomorrow.
[19:04] <infinity> But yeah, a hideous hack, and has nothing to do with fixing the bug, just an attempt to deal with the symptoms.  I certainly have no issues with reviewing a proposed patch to do that sort of thing, mind you.
[19:05] <mdeslaur> Debolaz: out of curiosity, that version of ubuntu was that on?
[19:06] <Debolaz> The specific error I got today was the first time I've ever gotten that specific error in Ubuntu. But I have had similar problems with the update system before that has required manual intervention. A program that attempts to fix everything that can be fixed automatically would had been convenient to have, since almost all of these errors does seem to be of the trivial kind to fix if you just know how.
[19:06] <Debolaz> mdeslaur: 12.04
[19:07] <mdeslaur> hrm, that was LP: #346386...and I thought it had been fixed already
[19:08] <mdeslaur> ah, yes, there's a new fix in #80 in that bug
[19:09] <mdeslaur> I've added an rls-q-incoming to that bug so foundations will take a look at mvo's proposed patch
[19:10] <mdeslaur> if it's the exact issue, mind you
[19:12] <Debolaz> infinity: I agree that it's not a solution in the same sense we were talking about above. Just a "less ugly" way to deal with symptoms, because I think it's going to be difficult to really deal with all the possible causes of these symptoms.
[19:29] <infinity> Debolaz: Well, no, we can't fix the root *cause*, as that's asking us to control teh internets, but we should be able to make sure corrupt data never hits disk at all.  The fact that it is hitting disk is the real bug here.
[20:35] <vitaly> Hello guys, does anyone know how does 12.04 LiveCD boot on Apple Macbooks? I noticed that same ISO dd-ed to the USB stick can boot both on PC and Mac. How is that possible? I haven't seen that in previous versions of LiveCD. Any ideas?
[20:39] <vitaly> ping anyone
[20:40] <vitalylook> Ii #ubuntu-iso chan alive?
[20:41] <penguin42> I don't know the way Ubuntu's boot setup does it; there's a scary post at http://mjg59.dreamwidth.org/#entry-12037   on the way Fedora does it
[20:50] <vitalylook> Well, it looks really scary. some more details here: http://mjg59.dreamwidth.org/11285.html
[20:51] <vitalylook> has anyone played with isohybrid tool?