[00:06] Laney: OK. I'm game. Accepted. Please keep an eye on it and make sure it builds. === yofel_ is now known as yofel === tuantub_ is now known as tuantub === james_w` is now known as james_w [01:18] ScottK, ping bug #460779 #460720, if you need anything else leave a comment on the bug, going to bed :) [01:18] Launchpad bug 460779 in libpam-blue "Sync libpam-blue 0.9.0-2.3 (universe) from Debian unstable (main)." [Wishlist,New] https://launchpad.net/bugs/460779 === porthose is now known as porthose|afk [01:28] porthose|afk: Nice. Thanks. [01:28] .away [01:45] hello anyone at home? [01:45] I'm just putting a package together for revu [01:45] and so do I need to write an installation bit in the makefile? [01:45] dh_make is saying something along those lines [01:46] $DESTDIR not ./ [01:46] hedkandi: Those of us who are here are pretty much focused on last minute bug fixing, so don't be suprised if you don't get an answer today. Next week will be better. [01:46] indeed. [01:46] when is the big day then? [01:46] Thursday is the release. Last day for non-emergency uploads is tomorrow. [01:46] Are you guys in your offices in the usa? [01:46] working for canonical? [01:48] All of us here are mainly volunteers, scattered across both Europe and the USA [01:49] I see. Which magazine will publish intrepid ibex first then? [01:53] Intrepid was released a year ago. [01:53] koala [01:53] kola koala [01:54] karmic kocaine [01:54] is what I mean [02:06] porthose|afk: Nice job. Two for two uploaded and accepted. Thank you for your contribution to Ubuntu. [02:28] * ScottK notes he is fresh out of stuff to review for acceptance. [04:01] Folks: what are the commands to fetch the source, patch it, and build it in the same way that ubuntu builds it? [04:01] I'm narrowing down a segfault in a crypto lib on Karmic. [04:02] zooko: apt-get source to get the source [04:02] Right. Adding sources to my sources.list now... [04:02] Patching depends on what patch system, if any, the package uses. [04:03] To build it, you'll want to build in a clean environment, such as pbuilder [04:05] So running apt-get source has a step where it says it applied a diff. I think that's the "patching" that I meant. [04:07] OK. [04:14] all of a sudden im getting an error saying that libc.so.1 is not found.. even while compiling for 32bit ..anyone know why? [04:14] it was working fine all the wile. [04:16] ScottK: do you read the NM Reports ? [04:16] AnAnt: Yes. [04:17] AnAnt: Did you see I uploaded your sabily artwork changes? [04:17] ScottK: yes and bitlbee too I think, thanks a lot [04:17] Yes, that's right. [04:17] You're welcome and thank you for contributing to Ubuntu. [04:18] ScottK: so, you stopped working on debian ? [04:18] AnAnt: No, took a break. Working on it again now, but it hasn't gotten to the front desk to change my status yet. [04:18] I see [04:20] YokoZar: Where is this pk7zip-full that spring-engine needs? [04:21] p7zip-full package? [04:22] There isn't one, but his package build-depends on it. That's the problem. [04:22] Can I figure out exactly what version of g++ was used to build the libcrypto++-8 in karmic? [04:23] Not pk7zip-full [04:23] p7zip-full [04:23] zooko: It'll be 4.4, probably 4.4.1. [04:23] zooko: Thanks. [04:23] Now lets see if it was his typo or mine. [04:24] So, I can't reproduce this segfault with the libcrypto++-8 from karmic, but I can reproduce it by building the upstream Crypto++ with the current karmic g++ 4.4.1-4ubuntu8. [04:24] So I'd like to know more exactly what g++ was used to build the one that is currently in karmic. [04:24] Look at when it was built and what version of gcc-4.4 was current at the time. [04:25] Okay thanks. It is named p7zip-full btw [04:25] Thanks [04:28] can anyone look into this weird issue pls [04:29] Hm, how do I learn when libcrypto++-8 was built and how do I learn what version of gcc 4.4 was in use at that time? [04:30] I know when it was changed from the changelog: http://changelogs.ubuntu.com/changelogs/pool/universe/libc/libcrypto++/libcrypto++_5.6.0-3/changelog [04:30] btw, good news, we can sync (instead of merge) texlive from now on, they have the same changes now [04:30] But I don't know when it was built. [04:38] zooko: Launchpad's down for maintenance for 3 1/2 hours, but when it comes back you can find it there. [04:39] Aha! The pbuild automatically runs the test suite! Great! [04:39] *and* it fails in the same way that I've been seeing. [04:40] So there is a regression in the toolchain, maybe, since it was built. [04:40] I *think* this isn't really critical, as long as it doesn't get rebuilt before karmic goes gold. [04:40] But it would, of course, be good to know what's going on. [04:40] To reprodce: just rebuild libcrypto++-8. [04:41] I thought it was only supposed to be down for a half hour [04:41] (I did using pbuilder) [04:41] N.B. I've been saying "segfault" all this time, but Crypto++'s own self-tests don't seg fault, but instead they go into an infinite loop in the SHA or SHA-256 validation tets. [04:42] Well I need to get to sleep, but I guess I'll open a bug... launchpad's down? [04:42] Okay, I need to get some shuteye. By for now. [04:43] ScottK: It's a build dep (the build system makes a few .7z archives of its content and renames them) [04:43] ScottK: oh god I misspelled it it's p7zip-full lol [04:46] I have no idea why dpkg-buildpackage didn't complain when I test built that [04:46] ScottK: reject it, I'll reupload [04:52] ScottK: any advice for me on pursuing this issue in libcrypto++8 and/or g++ tomorrow? [04:52] I would like to draw it to the attention of the relevant devs, perhaps after generating a minimal test case. [04:53] I'm concerned because Tahoe-LAFS depends on libcrypto++8 [04:53] I think I might fall sleep soon... [04:58] YokoZar: You need to do an ubuntu2 as it's already accepted when you uploaded it. [04:58] zooko: Let's chat tomorrow. [05:38] ScottK: apparently, the new prism prevents usage of old files created with prism [05:38] I have an idea for a fix [05:39] when's the cutoff for non-emergency fixes? === YDdraigGoch is now known as Guest72665 [06:23] while building for 64bit im getting this error. http://pastie.org/669680 [06:23] im very sure im running on a 64bit machine... [06:24] but the checking host-- and target systems are defined as i386 so its causing errros.. [06:24] would like to know how i can change it? [06:24] the machine may be 64bit, but is the OS? [06:25] solaris? [06:26] maco: its nexenta [06:26] and yes the OS is 64bit [06:26] sol kernel + ubu userspace? [06:26] yes [06:26] since it was a pkging que im asking.. [06:26] a total newbie here .. pls help [06:26] sounds like solaris kernel's reporting wrong... [06:27] isainfo --> amd64 i386 [06:27] is there a way I can override it? [06:27] dunno [06:28] but the surprising thing is.. on this machine i've already compiled it for 64bit a lot of times [06:28] its now that its cribbing!! [06:50] maco: if i chaange anything in anyother file apart from the rules file.. I get this http://pastie.org/669690 [06:51] but i do not know how to refresh it .. [06:51] could you please help me [06:51] how to refresh that patch [06:52] i dont see what change [06:53] i went into the configure script and added --enable-64bit. [06:53] then when i try building i get this. [06:53] Are bug fix uploads still allowed in universe? [06:59] slytherin, according to last ScottK email, yes, with the ack of a motu-release "Bug fixes that are minimally risky or fix serious bugs (such as FTBFS) are still welcomed" [07:00] Ok. Mine is minimally risky and probably also fixes serious bug in the package. :-) [07:02] got it.. it was a bloody mistake of not including clean while configuring for 64 [07:10] good morning [07:12] good morning dholbach ! [07:12] hi fabrice_sp [07:22] maco: i kinda got upto the stage where a copy is made of the genearted 32bit .so files and ran the configure for 64 bit also successfully.. But now i got toatally confused in linking up the rules so that the same is created for 64bit as well.. [07:23] Could you please help. [07:23] maco: http://pastie.org/669690 [07:30] anyone who can help me? [07:54] wrapster: what are ou trying to do exactly? [07:55] slytherin: im trying to generate 32/64 bit version of libnspr(and others).so from the same pkg... [07:55] I have gotten this far.. One moment.. i'll do a latest pastie [07:56] wrapster: why, don't existing packages work for you? [07:57] slytherin: long story cut short, its actually a prerequisite for something else that we are doing.. I cannot discuss that unfortunately. [07:57] Ok. So where are you stuck now? [07:58] slytherin: http://pastie.org/669690 [07:58] thats the entire pastie... [07:59] wrapster: I have seen that, what I am asking is at what stage are you stuck? [08:00] slytherin: http://pastie.org/669680 [08:00] thats where Im stuck. [08:01] the pkg build comes along cleanly but I dont see the staging dir being created or any of the *.so files within it ,in 64bit versions. [08:01] I must be missing the logic that it directly goes to shlibdeps, after make, without running the cc -m64 [08:03] slytherin: this will give you a better picture http://pastie.org/669723 [08:03] its the complete log for 64bit build [08:06] wrapster: I believe the prefix (in configure command) is wrong [08:06] It should be debian/ IIRC. [08:09] IIRC ? [08:09] slytherin: for the 46 bit configure u mean? === dholbach_ is now known as dholbach [08:11] slytherin: could you please explain? [08:13] IIRC is - If I remember correctly. I was referring to line 37 http://pastie.org/669690 [08:15] slytherin: no thats correct only. if your talking about indentation then it was messed up with the pastie... thats all === Sikon is now known as LucidFox [08:17] I was talking about the value. Shouldn't it be debian/usr instead of /usr? I haven't packaged any C app/lib in a while so I may be wrong. [08:18] slytherin: no, the --prefix must be /usr [08:19] line 88 makes sure the package is properly installed in debian/tmp [08:19] that didnt make a change... as i already said.. When i compiled it as an individual pkg(only as a 64bit pkg) it all worked fine. [08:20] this i386+amd64 thing all in one is causing issues.. Im doubting my logic here.. but got really confused looking around .. so pls help [08:20] line 4 in the second paste might be wrong; AFAIK dh_shlibdeps takes -l arguments relative to $(CURDIR) [08:20] or at least expects them === highvolt2ge is now known as highvoltage [08:23] azeem: i dont think so, coz it worked fine for 32 bit when i had written it the same way, and also while compiling the 64bit individually. [08:24] if you look at http://pastie.org/669723 as soon as the ./configure has done its job its jumping to dh_shlibdeps without running the cc - thats why i said my logic could be worng but now im confused totally [08:24] I don't know what the issue is anyway, I arrived here mid-conversation [08:26] what is the thing after line 139 in http://pastie.org/669690 anyway? [08:28] wrapster: and why do you think it should run some "cc -"? I don't see a build_64 rule or anything like that [08:31] azeem: thats a sad pastie.. something went wrong.. one moment...pls [08:32] azeem: i dont know from wher its coming... before pastie it is nto there ...after i hit submit this pops up [08:32] 09:28 < azeem> wrapster: and why do you think it should run some "cc -"? I don't see a build_64 rule or anything like that [08:36] azeem: buil_64 is not there coz im directly calilng build-stamp [08:36] tahs the one right [08:36] the one right? [08:37] yeah... [08:37] install-stamp calls the buil-stamp twice [08:37] I didn't understand what you mean with "the one right" [08:37] no [08:37] it has the build-stamp rule as requirement [08:38] if the "build-stamp" file already exists at the second time, the requirement is fulfilled and the rule will not be run [08:38] oh sorry [08:38] didnt think of that. [08:39] the clean way to do this would be to have two build directories, and build/install in both, each as a requirement for build-stamp [08:39] like (mkdir build-32; cd build-32; $(CFLAGS32) ../configure; make) [08:40] (mkdir build-64; cd build-64; $(CFLAGS64) ../configure; make) === Guest72665 is now known as YDdraigGoch [09:19] azeem: all of these that you said can be written as a single rule right.. instead of making more and more dependencies? [09:20] if you prefer [09:20] that makes it harder to just build one or other other, though [09:21] ok from what i've already written could you help me make it clean.pls [09:21] no, I don't have time right now [09:22] ok === Tonio__ is now known as Tonio_ [10:23] slytherin: could i take your help pls? [10:23] wrapster: regarding what? [10:24] slytherin: the build comes through successfully, i can create a backup of the 32bit files ,i can also see that the staging dir has 64bit files but its not being put under /usr/lib [10:24] under the same rules file. [10:25] hmm, can't help much. I usually work on java packages. :-( [10:25] hmm [10:25] ok thanks anyway. [10:25] geser: are you around :) [10:34] yes [10:39] geser: one moment pls.. [10:39] i'll finish the build [10:43] geser: ok so here is the update .. individually i can build the 64bit versions but im not suppose to do so.. So i tried integrating both and this is what i could come up with http://pastie.org/669815 [10:44] geser: I have a backup that will be created of the 32bit ones but when the rules file builds for 64bit , the 64bit (*.so) files are created in the staging dir no doubt(debian/tmp) but they are not transferred to the debian/libnspr4-0d [10:44] where they should actually reiside... [10:46] essentially what i want to say is debian/libnspr4-0d is missing most of the contents of the staging dir (debian/tmp) when the 64bit version is built.. for the 32bit one tehre is no problem... Again im guessing my logic could be worng.. or the way im placing the dependecies could be worng.. Could you pls help... [10:48] can you pastebin debian/libnspr4-0d.install (if it exists and I guess the filename right)? [10:52] yeah [10:52] geser: here is a pastie that will explain my problem very well..http://pastie.org/669823 [10:53] geser: the file exists and it only had 2 contents... [10:53] usr/lib/*.so.0d [10:53] usr/lib/*.so [10:54] wrapster: how do you make sure the 32bit and 64bit *.so are differently named? [10:54] do you put them in different directories? [10:54] yes. [10:54] which are? [10:54] wrapster: like I assumed. The .install files controll which files get moved over from debian/tmp to debian/$pkgname (from where the deb is build) [10:54] pls look at this http://pastie.org/669815 line no 75 [10:55] the copy_32 rule, will actually copy out all the *.so files to a named dir for future replacement.. [10:55] wrapster: and then those get copied back to debian/libnspr4-0d/usr/lib in line 103 [10:55] probably overwriting the 64bit files [10:56] azeem: no [10:56] they are acutally not being copied for some reason. [10:57] wrapster: so debian/tmp contains both the 32bit libs and 64bit ones correctly? the first ones in debian/tmp/usr/lib and the second ones in debian/tmp/usr/lib/amd64? [10:57] wrapster: did you check the content of bkup_32? [10:57] cp debian/tmp/usr/lib/*.0d bkup_32 [10:57] this might just copy over a symlink [10:57] azeem: yes the bkup_32 only has 32bit files [10:58] and within the debian/tmp dir [10:58] ok [10:58] azeem: I assume it's just the install file telling to move the 32bit libs into the package [10:58] there is no lib/amd64 being created .. (coz ive not mentioned it...) [10:58] however the files will be created in debian/tmp/usr/lib only but these will be 64bit [10:58] im very sure and i ran a check on this to clarify... [10:59] so the summary being... I have the 32bits in bkup_32 and 64bits in debain/tmp/usr/lib at the end of my build. [10:59] but there is nothing in debian/libnspr4-0d dir :( [11:02] sorry, but I'm not interested in debugging your rules [11:02] azeem: / geser : http://pastie.org/669829 this is the o/p at the end of my build. [11:02] azeem: ok np.. thanks for you help [11:02] geser: could you pls help me.. [11:03] wrapster: also note that people will probably mock Nexenta if you push this into a release like this [11:03] it's really ugly [11:06] hey motu peeps [11:06] anyone using the bluetooth networking in karmic? [11:08] gah [11:09] wrapster: I assume that "install-stamp-64" installs the libs also to debian/tmp/usr/lib and overwriting your backup from line 103. Try moving the 64bit libs to the correct location (after you installed them) and only then copy back the 32bit libs [11:09] dh_haskell_configure doesn't support passing arbitrary flags through [11:12] I fear I'll have to leave hsh for karmic [11:18] geser: ok [11:27] geser: i want it to overwrite the 64bit libs coz by the time the 64bit processing will start I already have taken the backup of 32bit files...(in bkup_32) so i will definitely have it in tmp/usr/lib/ but if i can somehow reflect it in libnspr4-0d then i can do further copy and so on... but thats not happening.. thats my worry [11:30] geser: this is how the makefile logic i created works... build everything for 32bit until you reach dh_installdep -a (coz thats when the tmp dir having 32bit is created)--> then copy all these to bkup_32--->clean-->configure_64-->build64-->install [11:36] did you verify that the build is actually going like this? [11:39] yes [11:39] azeem: and i think i resolved the issue one moment let me see.. [11:47] azeem: no... :( [11:47] not working [11:48] azeem: / geser: yay yay [11:48] working. [12:25] sigh [12:26] huhu Laney [12:26] hi there [12:26] Laney: anything wrong? [12:26] yeah [12:26] I need armel to test a fix [12:26] :(! [12:27] (or sparc) [12:29] Laney: qemu? [12:29] Laney: NCommander not around? [12:30] hyperair: dunno how [12:30] Laney: manpage =0 [12:31] its unhelpful [12:31] looks like hassle too [12:32] I would very much like one of those PPAs that builds for everything [12:34] me too, armel, sparc, powerpc needed here:*( [12:35] well powerpc emulatable [12:35] but you can't debootstrap a powerpc chroot >_> [12:36] rather, even if you did, you'd end up having to figure out a way to install the powerpc kernel and bootloader [12:39] I'm sure I needed this before and did something, if only I could remember what.. old age === rmcbride_ is now known as rmcbride === mtrudel_ is now known as cyphermox [13:05] Laney: IIRC, revu is on sparc. So may be you can bribe revu admins for access to a chroot. :-P [13:22] all i need is a build check in pbuilder rather than anything more [13:25] Laney: Another solution is to bribe the MOTUs who are also DDs to test the fix bug for you. :-) [13:27] slytherin: I thought of that one ;) [13:27] * Laney looks at directhex [13:36] morning folks [13:43] Would someone that knows C please review https://code.edge.launchpad.net/~simono/ubuntu/karmic/gnoemoe/fixes-bug-459164/+merge/13854 [13:53] ScottK, gint count = (strlen(no_ansi) - written); it could use just "len" no need to call strlen() again [13:54] joaopinto: Could you fix it and make a proper debbdiff? [13:55] well, it's a very small improvement, doesn't worth a debdiff at this time, the code looks sane [13:56] ScottK: something looks wrong to me. [13:57] Suppose strlen(no_ansi) is 20 at the start. written gets initialized to 0. First pass of the loop, count = 20 [13:57] suppose partial write, written = 5, then [13:57] second pass of the loop, count = 15 [13:57] so far so good -- it invokes write(fd, no_ansi+5, 15) [13:58] but if there is a second partial write, let's say this time written = 6 [13:58] so 3rd pass of the loop, count = 14 [13:58] oh written is not cumulative :\ [14:02] OK. Sounds like we should give it a pass for Karmic. Maybe an SRU. [14:02] * Laney is going to upload another armel/sparc fix, this time for darcs [14:02] same caveats as before [14:03] OK. [14:12] I need a sync from Debian to fix a security bug #457709. Who should I poke? [14:12] Launchpad bug 457709 in mandos "mandos-client adds unnecessary files to initrd" [Undecided,In progress] https://launchpad.net/bugs/457709 [14:22] Teddy_: You've come to the right place. [14:26] ScottK: so, should we do anything about the fact that, on my machine at least, "pbuilder build libcrypto++_5.6.0-3.dsc" when it gets to the SHA validation suite and enters an infinite loop? [14:27] I'm glad to see that the tests get run automatically as part of pbuilder, since that means if it fails then it will *not* be uploaded to ubuntu, right? [14:28] It should fail to build, yes. [14:28] the patch for gnoemoe should probably replace the first do-loop with http://paste.ubuntu.com/302087/ [14:28] Oh yeah, I was going to figure out which version of gcc was used to build it. [14:28] Althought pbuilder and the buildd's are not identical. [14:28] ScottK: Right then. [14:28] * Teddy_ pokes the channel about bug #457709 [14:28] sistpoty|work: simon-o is online, so maybe you could discuss it with him [14:28] Launchpad bug 457709 in mandos "mandos-client adds unnecessary files to initrd" [Undecided,In progress] https://launchpad.net/bugs/457709 [14:28] Teddy_: I'm looking at it. [14:29] ScottK: Cool, thanks! [14:29] simon-o: ^^? [14:29] sistpoty|work: yes [14:29] simon-o: read the above discussion about your patch for gnomeoe? [14:30] gnoemoe even [14:30] sistpoty|work: yes, ScottK attached it to the merge proposal [14:30] Where is there a history of when packages were built and/or uploaded? [14:30] simon-o: sistpoty|work had an additional suggestion [14:30] I'd like to understand if the difference between my pbuilt libcrypto++8 and the one in karmic is due to a slightly different version of g++. [14:30] zooko: In launchpad. What's the source package name? [14:31] ScottK, sistpoty|work: Ok I see, you mean http://paste.ubuntu.com/302087/ [14:31] ? [14:31] yes, boils down to the same as in the compileflags wiki [14:31] simon-o: of course it'd also be worthwhile to check if the file descriptor in question is opened non-blocking. if so EAGAIN is also a vaild error [14:31] Source: libcrypto++ [14:32] and Source: gcc-4.4 [14:32] zooko: https://launchpad.net/ubuntu/+source/libcrypto++/+publishinghistory [14:32] Similar for gcc-4.4 [14:33] sistpoty|work: Is your patch for the updated version of my patch? [14:33] hm. [14:34] simon-o: yes it should replace the first do-loop === warp10_ is now known as warp10 [14:34] simon-o: the recipe in the compilerflags wiki would also work though [14:34] ok, how can i fetch the version of gcc that was used to build and see if building with that version yields a working libcrypto++? [14:35] 4.4.1-3ubuntu3 [14:36] zooko: What architecture? [14:36] Heya gang [14:36] sistpoty|work: I don't really get what you mean with ret. Where is that defined? [14:37] ScottK: amd64 [14:37] zooko: https://launchpad.net/ubuntu/+source/gcc-4.4/4.4.1-3ubuntu3/+build/1195506 [14:38] Heya bddebian. [14:38] Hi ScottK [14:40] Teddy_: mandos sync'ed for Karmic. [14:40] ScottK: Wonderful! [14:40] ScottK: Thanks a lot. [14:44] simon-o: oh, should be same as written... forgot to add that variable [14:44] Teddy_: The binaries are failing to upload due to a known launchpad bug. I'll do a direct upload to work around it, so don't worry. [14:45] ScottK: I was just wondering about that, thanks! [14:45] (same type as written [14:45] sistpoty|work: ok, this makes sense. I don't really see a benefit of using a for loop (I personally like for more, but I tried to keep this as close to the recipe as possible to make it easier for reviewing) [14:45] +) [14:46] simon-o: I only learnt that the recipe exists after I pastebin'd my solution ;) [14:46] ScottK (or some m-r) : python-poppler-dbg is uninstallable, I'd like to upload a fixed revision. [14:46] simon-o: either one should be fine [14:46] gaspa: Pastebin the diff please. [14:46] sistpoty|work: Ok, so would it be ok with you if I fix the my patch and use that one? [14:47] ScottK: yup, just a minute. [14:47] simon-o: sure [14:47] sistpoty|work: ok, thanks for your help. I'll post a new diff soon. [14:47] yw [14:49] sistpoty|work: Do we care about 302003? [14:49] * sistpoty|work looks [14:50] Thanks [14:53] * sistpoty|work looks closer at mxml [15:00] ScottK: http://paste.ubuntu.com/302105/ [15:00] gaspa: Go for it. [15:01] thank you [15:01] ScottK, joaopinto, zooko, sistpoty|work: I updated the merge proposal at https://code.launchpad.net/~simono/ubuntu/karmic/gnoemoe/fixes-bug-459164/+merge/13854 based on your feedback. Here is the proposed patch http://paste.ubuntu.com/302107/ (LP seems to has some problems) [15:02] ScottK: no, we don't care for bug #302003, as the shared object is already linked against the pthread library, and hence will draw it in when getting loaded (the only thing to fix here would be to add @PTHREAD...@ to Libs.private) [15:02] Launchpad bug 302003 in mxml "PTHREAD typo in .pc file" [Low,Confirmed] https://launchpad.net/bugs/302003 [15:02] sistpoty|work: Thanks. [15:02] * sistpoty|work adds a comment to the bug [15:03] simon-o, it's still faulty, you can't use the cumulative value to exit the loop, that one needs to be based on the last write( return value [15:03] you want to use "total_written" for the pointer, and "written" to break the loop due to a negative write( return [15:04] joaopinto: argh, sorry. I'll try it again. Thanks [15:06] simon-o, the fix for those unhandled writes( is not as simple as it looks ;) [15:06] joaopinto: yeah, that's true. [15:06] good to have someone who reviews it :) [15:06] * sistpoty|work wonders why it uses write there in the first place, and not just the much simpler stdio counterparts [15:13] gaspa: Accepted. Thanks. [15:13] ScottK: cool, thank _you_ :P [15:16] joaopinto: next try: https://code.edge.launchpad.net/~simono/ubuntu/karmic/gnoemoe/fixes-bug-459164/+merge/13854 I now use the total written bytes to decrease the counter and move forward in the buffer [15:18] simon-o, 2 errors [15:18] ops, wait, let me look again :P [15:19] :P [15:19] simon-o, well, there is a broken code path, but it get's discated on loop exit condition [15:20] total_written += written; [15:20] on error, written is negative, and you are decreasing total_* :P [15:21] I hope no one decides to re-use total_written out of the loop :P [15:21] joaopinto: that's right, but then the loop discontinues [15:22] joaopinto: ok, that's a good point I'll move total_written += written two lines up [15:22] then it should be ok [15:22] no, if a signal is delivered during the write, written is negative and errno is EINTR [15:22] but the loop continues [15:24] sistpoty|work: I thought errno is only EINTR before any bytes are written [15:24] ok I see, forget about it [15:25] sistpoty|work, joaopinto: I'll add a check if written > 0 and increase total_written only in that case [15:25] that should be safe [15:25] that looks good [15:26] * sistpoty|work has the suspicion that the code slowly migrates to what I pasted :P [15:26] :D [15:33] joaopinto, sistpoty|work: https://code.launchpad.net/~simono/ubuntu/karmic/gnoemoe/fixes-bug-459164/+merge/13854 updated again [15:37] didrocks: Any luck on a quickly fix? [15:37] How do I search for a package that might be a child of some metapackage? [15:37] ScottK: I didn't have the time to work on it, but currently doing it. It seems to be almost good [15:37] didrocks: Excellent. [15:37] quidnunc, a child ? you mean a dependency ? [15:39] joaopinto: I thought that sometimes that a dependency might be listed but that dependency was not actually a package but was provided by the "real" package [15:39] Specifically I want to know what provides "X11", if anything [15:41] ah ok :| [15:42] simon-o: almost good: for the second part, you don't clear errno, but have the write done in a loop that loops on errno==EINTR. iirc a write will not clear errno (only set it if things go wrong) [15:42]