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