[10:12] <azbyin> hi all
[10:12] <azbyin> can someone test something for me? I believe there is a bug in 'du' from coreutils
[10:12] <azbyin> either that or the behaviour was changed for some odd reason after the version available in 11.10
[10:13] <mitya57> azbyin: please describe your problem
[10:14] <azbyin> du -hs * .        in a directory filled with stuff shows a wrong size for .
[10:15] <azbyin> all the sizes reported for stuff matching the * glob is fine. just that the summary for the . dir is some weird number
[10:15] <azbyin> i cannot figure out where this number comes from
[10:15] <azbyin> i noticed the issue here on my laptop when i backed up everything from 11.10 and wiped and installed 12.10 now
[10:15] <azbyin> i also ssh'd into my work machine which runs 12.04 and it has the same issue
[10:16] <azbyin> i will post a sample on pastebin
[10:20] <azbyin> mitya57, http://pastebin.com/hDYGEpAs
[10:20] <azbyin> note that simply running 'du -hs' gets the right size for the directory.
[10:21] <alo21> hi. What is the process to upgrade a package? I mean where should I tell that I am working on it and etc... ?
[10:22] <mitya57> azbyin: du -hs * . shows total size of files in a directory EXCLUDING sub-directories
[10:22] <azbyin> so you reckon i have 291M of files in my home dir?
[10:22] <azbyin> lol
[10:23] <mitya57> azbyin: here is my small test:
[10:23] <azbyin> mitya57, http://pastebin.com/gUXWNJ5s  updated paste
[10:25] <mitya57> azbyin: yes, I think so. also, if you sum everything in "du -hs * .", you'll get 19G
[10:25] <azbyin> see that there are *no* files in the dir and collectively all the .[a-z] files/dirs do *not* add up to 291M
[10:26] <azbyin> mitya57, mind explaining why the output is different then in 11.10?
[10:26] <alo21> I cannot find all the info online. (may be because I am not good on googleing)
[10:26] <azbyin> i have this dir in an external usb partition formatted as ext3.
[10:26] <azbyin> and running du -hs * .  within the dir in 11.10 shows the correct summary size for the entirety of .
[10:27] <mitya57> azbyin: please report a bug
[10:27] <mitya57> or maybe it's bug 1004319
[10:28] <mitya57> alo21: nothing different from usual process
[10:28] <azbyin> exactly this bug!!
[10:28] <mitya57> alo21: clone lp:ubuntu/packagename, upgrade the package, submit a merge proposal
[10:29] <azbyin> i see there was some change in coreutils upstream with respect to du
[10:29] <alo21> mitya57: Have I tell to somebody that I am upgrading it, to avoid double work?
[10:29] <azbyin> http://changelogs.ubuntu.com/changelogs/pool/main/c/coreutils/coreutils_8.13-3.2ubuntu2/changelog    search for du and it shows:     coreutils (8.13-1) unstable; urgency=low
[10:29] <azbyin>   * New upstream version
[10:29] <azbyin>     - du ignores specified dir when part of cycle (Closes: #598438)
[10:30] <mitya57> debian bug 598438
[10:30] <azbyin> sorry for the paste here, but it might have to do with this "fix" that introduced the regression
[10:30] <azbyin> mitya57, please dont be discouraged by the "corrupted" word in the bug report
[10:31] <azbyin> the original report was simply that du reported errors on fs with error and this broke scripts
[10:31] <azbyin> but the fix obviously has changed the way du operates internally. so i assume this is the one that iontroduced the regression
[10:32] <mitya57> alo21: if the package has an Ubuntu maintainer, you may want to contact it first
[10:32] <azbyin> now i want to make a good and simple testcase using dd so i can demonstrate the bug
[10:32] <mitya57> alo21: what's the package, by the way?
[10:32] <mitya57> s/it/him/
[10:33] <alo21> mitya57: no one in particular. I really would be part 13.04's development
[10:33] <azbyin> s/it/him\/her/ :)
[10:33] <mitya57> :)
[10:34] <mitya57> alo21: you can also file a bug and tag it with upgrade-software-version
[10:34] <alo21> mitya57: but in the meantime I am a little bit afraid to make some mistakes.
[10:35] <mitya57> alo21: don't worry, usually there's enough time during the development cycle to find bugs :)
[10:37] <alo21> mitya57: what do you mean with 'find bugs'?
[10:37] <mitya57> I mean, if you break something, someone will notice it.
[10:39] <alo21> ah, ok. Thanks a lot!
[10:40] <alo21> mitya57: can I start now on upgrading package for 13.04?
[10:41] <mitya57> alo21: the archive is not opened yet, but it should open next week
[10:41] <mitya57> alo21: but you can already start working on the branch, of course
[10:43] <alo21> mitya57: for example here (https://bugs.launchpad.net/ubuntu/+source/ibus-chewing/+bug/1069245) if I would upgrade this package
[10:44] <alo21> I have to assigne this bug to me, upgrade it and then create a personal branch?
[10:44] <alo21> assuming that I have spoken with the maintainer yet
[10:44] <mitya57> alo21: that package comes unchanged from debian, it would be good to update it there
[10:45] <mitya57> you can still use bzr, but then export your changes to a patch and submit to debian bug 691076
[10:45] <alo21> mitya57: make a request to debian?
[10:46] <mitya57> alo21: there already is a bug ^^
[10:47] <mitya57> you can just submit a debdiff there
[10:47] <hyperair> great, so quantal's compiz decides to ignore all prior customization and just start afresh? very nice.
[12:01] <alo21> mitya57: to create a debdiff I should have at least two debian packages... One is the source from debian, the other is from Ubuntu. Right?
[12:29] <mitya57> alo21: no, you may create a debdiff between current and new ubuntu versions
[12:29] <mitya57> you can either use "debdiff" command or "bzr diff" if you prefer
[12:41] <arand> Well, debdiffs are between two debian packages, doesn't matter what distribution they are from...
[12:42] <alo21> arand: ok
[12:43] <alo21> arand: when I am working on a package have assigne the bug to me?
[12:48] <arand> I don't know the formalities around assignment, but there's never a *requirement* to assign yourself, afaik.
[12:51] <geser> I usually only assign to myself when it takes some time (days) or when I expect a clash with someone else working on it too (to prevent double work)