[01:04] <lamont> gah
[01:06] <wgrant> Oh?
[01:11] <hallyn> (that didn't sound encouraging)
[01:46] <psusi> anyone got any advice on where to start debugging ubiquity hanging while detecting disks?
[01:47] <psusi> hrm... or better yet, how to revert to the previous version... was changed yesterday for a new partman... sounds like a good candidate
[02:02] <skaet_> all, known affected packages have been rebuilt now,  and the buildds have been turned on.
[02:08] <skaet_> For those interested,  the list of packages can be found at: http://paste.ubuntu.com/572428/ .
[02:09] <Chipzz> skaet_: what exactly was the cause?
[02:49] <skaet_> Chipzz,  sudo on the builders was updated earlier today, and it had different default behaviour, so some of the packages created had the wrong permissions.
[03:10] <hallyn> skaet_: thx for the heads-up
[03:10] <skaet_> hallyn, you're welcome.
[03:47] <psusi> ev, yesterday you enabled reuse/* in partmant-auto.  This seems to cause it to hang when detecting partitions in ubiquity on the daily live cd.  filed bug #725408
[05:49] <microcai> gtk-window-decorator sigfault at /usr/lib/libdecoration.so.0
[05:51]  * microcai emerald also segfault at /usr/lib/libdecoration.so.0 
[07:01] <ohsix> is there anything that can be done by the kernel to keep harddrive temperatures down, or really by anything? i've had 2 drives basically get the bits annealed right out of them in my ubuntu laptop
[07:03] <hyperair> try airing them out a bit
[07:03] <hyperair> what's their temperatures like?
[07:03] <cdbs> jdstrand: ping
[07:03] <cdbs> jdstrand: according to DDs the info on repacks of tarballs should go to the Comment: field in DEP-5 debian/copyright
[07:04] <cdbs> jdstrand: and you rejected dmedia, even though it contained the info:
[07:04] <cdbs> Comment: Upstream's sources was repacked to remove unnecessary test files dmedia/tests/data/* from the tarball.
[07:04] <ohsix> hyperair: well iv'e done everything that could be done about airflow, right now i have to monitor it and inject emergency air with something if it gets over 55c
[07:04] <cdbs> ^^ taken from debian/copyright
[07:05] <hyperair> ohsix: but i've never had any hard disk overheating issues before. what machine is that?
[07:05] <ohsix> the drive sez it can do 60c but i've already lost some stuff from random stuff becoming unreadable, on a drive that's only been on for 200 hours; one that replaced a drive doing the same thing
[07:05] <ohsix> compaq cq60
[07:05] <hyperair> that sucks =\
[07:06] <hyperair> i'd take the laptop back to the manufacturer, and complain really
[07:06] <ohsix> try smartctl -l scttemp on your harddrive
[07:06] <hyperair> around 43
[07:07] <hyperair> doesn't get higher than that
[07:07] <hyperair> and there's no airflow around my hard disk
[07:09] <ohsix> what model?
[07:09] <ohsix> and does smartctl -t long make the temperature go up
[07:11] <hyperair> lenovo y410
[07:12] <ohsix> nah, of the harddrive
[07:12] <hyperair> this is a two year laptop that has gone through some serious I/O thrashing before without overheating the hard drive
[07:12] <hyperair> the first was a scorpio blue
[07:12] <hyperair> the second was a hitachi something or other
[07:12] <hyperair> and this one is another wd hard drive
[07:13] <ohsix> k
[07:13] <hyperair> it seems the compaq cq60 is prone to frying hard drives
[07:13] <ohsix> heard wd 2.5 drives were cool drives
[07:13] <hyperair> well i didn't notice any difference between that and the hitachi
[07:14] <hyperair> and i've got the sensors-applet stuck on my panel, so i see my hard disk temp all the time
[07:15] <MTecknology> I wish I could get output from acpi -t
[07:15] <ohsix> the drive i have now keeps going up in temp, if slowly; but that doesn't bode well if it's doing nothing
[07:15] <MTecknology> it just returns nothing on this laptop :(
[07:16] <cdbs> Hello all, this is my scenario:
[07:16] <ohsix> where did you see that the cq60 has harddrive problems?
[07:16] <cdbs> I uploaded a new package before FF, and it got reviewed yesterday
[07:16] <cdbs> and it got rejected, saying there was no documentation on why the package was repacked
[07:17] <cdbs> infact, there WAS clear documentation, which I guess the AA mistakenly missed
[07:17] <cdbs> so, I need to re-upload, do I need an FFe (I guess yes)
[07:17] <cdbs> ?
[07:17] <ohsix> the awesome part is the previous overheated drive bricked the whole thing during a bios update
[07:23] <ohsix> hyperair: but anyways; i'm looking for stuff to do that can be automated, like having the drive accessed less when the temperature is too high; so i don't have to do it manually
[07:25] <ohsix> hyperair: this is the type of stuff i'm looking at http://paste.ubuntu.com/572512/
[09:18] <ohsix> UGH haha, hddtemp returns "drive is sleeping" when it's spun down
[09:18] <ohsix> reading the temp doesn't wake it up; and the point of me letting it spin down is to moderate the temperature, ufhg
[09:33] <ohsix> ugh apparently hitachi has a vendor specific command to read the temperature without a spinup; but generally reading smart data means the drive accessing the task file, so a spinup; can't have both
[09:38] <ohsix> hyperair: are you still here? what do you get for hdparm -M and -B?
[09:39] <ohsix> hyperair: apparently the bios can set it, or it can be left entirely alone
[09:40] <ohsix> but with both of them set to default even an idling disk will get very hot
[10:04] <ohsix> heh hdparm.conf can only use /dev/sd? and /dev/hd? paths; the device order changes though so you either have global settings or none
[10:08] <ohsix> hyperair: gotta go,  but if you could check -B & -M i'd be interested, they should be set to fast & no spindown, since its' set by a script in the hdparm package, and it's a dep of ubuntu-standard
[10:51] <YokoZar> why is libgnomevfs2-0 in libs but libgnomevfs2-bin in universe/libs when they come from the same source package?  (Maverick)
[11:41] <wgrant> I've taken most of the distro build farm down again, since it seems the problems of 12 hours ago are not entirely resolved.
[11:41] <wgrant> Normal PPAs are unaffected, but distro and non-virtual PPA builds will be queued until this is sorted out.
[13:09] <artfwo> I fixed a bug in libappindicator in my own bazaar branch. what's the procedure for review and inclusion? should I set the status to "fix committed", unassing myself or whever else?
[13:10] <artfwo> is there a wiki page about submitting code patches?
[13:10] <artfwo> bug 724917
[13:34] <cjwatson> artfwo: https://wiki.ubuntu.com/SponsorshipProcess
[13:39] <artfwo> cjwatson, I've already proposed a branch merge according to the guide. Now I'd like to know if there's anything like MOTU bug workflow in the upstream projects (changing the bug status to "confirmed" and unassigning yourself, when ready for sponsoring)
[13:42] <cjwatson> I don't know how much it matters.  I wouldn't recommend using Fix Committed though - to me, that means that it's committed in the branch that developers upload from.
[14:18] <gaurav_pawaskar> Hi guys, has anyone written MD5 algorithm?
[14:19] <m4n1sh> gaurav_pawaskar: which language?
[14:19] <m4n1sh> framework etc?
[14:20] <gaurav_pawaskar> m4n1sh: not language as such. I just need a little clarification
[14:20] <m4n1sh> gaurav_pawaskar: I don't think everyone writes their own MD5 implementation
[14:20] <cjwatson> I would recommend against reimplementing basic algorithms like MD5.  You're better off using a standard implementation
[14:20] <m4n1sh> libcrypt contains it's implementation AFAIK
[14:20] <gaurav_pawaskar> Actually I do not need final output of MD5
[14:21] <gaurav_pawaskar> i need some intermediate data.
[14:21] <m4n1sh> gaurav_pawaskar: #openssl people can help better
[14:21] <m4n1sh> I think
[14:21] <gaurav_pawaskar> okey I will try there. Thanks alot m4n1sh
[14:22] <m4n1sh> gaurav_pawaskar: just ask them that you need to get the intermediate results
[14:22] <m4n1sh> so how to do it
[14:22] <m4n1sh> instead of asking "has anyone re-implemented it"?
[14:22] <gaurav_pawaskar> yes sure.
[15:15] <jdstrand> cdbs: no, you don't need an FFe. I responded in the email
[15:15] <jdstrand> cdbs: I apologize for missing the info. odd, cause I looked for it...
[15:17] <hjd> Hi. I stumbled across bug 709633, which is a package request for a package which was in Ubuntu earlier, but was removed from Debian (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=547514). Should this be handled like normal package requests?
[15:24] <ari-tczew> hjd: what do you want to achieve? re-pack into Ubuntu?
[15:30] <hjd> ari-tczew: I'm not sure. Sorry. I just stumbled across the bug report (not familiar with the software) and noticed it had been in Ubuntu earlier. So I wondered if that means if it should be treated like regular needs-packaging bugs or not. I first asked in #ubuntu-bugs, but it was suggested I could try to ask here.
[15:32] <hjd> Basically I thought about adding "needs-packaging" to the title and tag it, but I wasn't sure if it should be treated differently as it has been included before...
[15:39] <cdbs> jdstrand: re-uploaded
[15:39] <cdbs> no problem
[15:41] <jdstrand> thanks
[15:42] <ari-tczew> hjd: it was removed parallel from Debian and Ubuntu
[15:42] <ari-tczew> RM: luxrender -- RoM; RC-buggy; NPOASR
[15:44] <ari-tczew> hjd: if you want bring bag this package, you have to open a new bug against Debian and Ubuntu. however, if luxrender was removed in the past due to RC bugs, we preffer to get it from Debian, so if you want to maintain this package, feel free to do it in Debian.
[16:07] <hjd> ari-tczew: I see. I left a comment on the bugreport in case anyone else stumbles across it.
[16:17] <gaurav_pawaskar> Is there any channel for c++ help?
[18:18] <GunnarHj> SkottK: Ping?
[18:19] <GunnarHj> ScottK: Ping?
[18:25] <ScottK> GunnarHj: Pong.
[18:27] <GunnarHj> ScottK: Hello! Do you have a minute to talk about bug 719815?
[18:28] <ScottK> GunnarHj: Sure.
[18:28] <GunnarHj> ScottK: Have you read the latest comments on the bug?
[18:28] <ScottK> Looking now.
[18:30] <ScottK> GunnarHj: I'm still looking for someone like pitti or seb128 to review and say the changes are appropriate.  pitti is correct that we prefer unchanged backports, but things can be adjusted if they need to be.
[18:31] <ScottK> Personally I'm concerned that we want to be very careful with something as central as gmd.
[18:31] <ScottK> gmd/gdm.
[18:32] <GunnarHj> Scott: I have checked, and using the Natty packages without adjustments is not possible due to dependency issues etc.
[18:33] <ScottK> Right.  Adjustments when needed are fine.
[18:33] <GunnarHj> Scott: What I did so far is that I started with the last Lucid respective Maverick package and added some of the Natty revisions. To me it that appears to be the most convenient way in this case.
[18:35] <ScottK> OK.
[18:36] <ScottK> Why is this not suitable for SRU (since that's where you started)?
[18:37] <GunnarHj> ScottK: Well, you can see Martin's comment at the bottom of bug 553162.
[18:37] <ScottK> Looking
[18:38] <GunnarHj> ScottK: It appears to me that the SRU policy is very restrictive.
[18:38] <ScottK> It is, by design.
[18:39] <ScottK> GunnarHj: What's the confusion when using ssh?
[18:40] <GunnarHj> ScottK: If LC_MESSAGES is set, without that variable is set to the same value on the remote machine, translations don't work as expected.
[18:41] <ScottK> And we didn't set it before?
[18:42] <GunnarHj> ScottK: No. Which is one of the reasons that caused bug 553162.
[18:42] <ScottK> OK.
[18:43] <ScottK> I think that what you propose is reasonable for a backport, but because this is essentially updating the Lucid/Maverick pacakges and not a normal backport, I want someone from ubuntu-desktop to review and concur with the changes.
[18:43] <ScottK> GunnarHj: These changes are in Natty already?
[18:44] <ScottK> (that's also a requirement)
[18:45] <GunnarHj> ScottK: Yes, it's all in Natty already. I'm confident that Martin is ready to approve it as soon as he gets the time needed.
[18:45] <ScottK> OK.  Ping me again when he does.
[18:47] <GunnarHj> ScottK: I'll do. But, as I wrote on the bug, I will add some more of the Natty revisions first. No reason to limit it to "bug fixes" when we are talking about backports, right?
[18:58] <ricotz> ScottK, hello
[18:58] <ScottK> Hello ricotz.
[18:58] <ricotz> ScottK, do you have time to review a new package in the natty queue?
[18:59] <ScottK> Unlikely today.
[18:59] <ricotz> ScottK, it was reviewed by 3 motus already
[18:59] <ricotz> ScottK, ok
[20:49] <Renfield> Is this an appropriate channel in which to ask questions about creating a package?
[20:50] <penguin42> Renfield: I think there is a #ubuntu-packaging
[20:51] <Renfield> Yes there is. Thanks!
[23:28] <Ampelbein> is by chance anyone from ubuntu-sru here and willing to look at bug 709194 to see if everything is ok?
[23:59] <ari-tczew> Ampelbein: subscribe ubuntu-sponsors. now sponsors handle SRUs first, upload it and pitti looks on it in queue