[00:03] <chrisccoulson> ScottK - do you know why meta-gnome2 has a comment "no need to sync" on https://merges.ubuntu.com/universe.html ?
[00:04] <chrisccoulson> i noticed you just sponsored an upload to fix a broken dependency. some of the existing dependencies it still has are very old and things that it really shouldn't depend on
[00:45] <soren> ScottK: Thanks for the ack on python-mhash. I used python-support so that Debian would like it. :)
[00:45] <soren> ScottK: It's in the queue, ready for review. Thanks!
[00:46] <soren> ScottK: And yes, it will turn out to be server related, so you have are acting within your authority :)
[00:47]  * soren goes to bed
[00:55] <LaserJock> ScottK: good grief, this latest rebuild test is concerning. So many FTBFS
[01:22] <micahg1> how do I know what's wrong with a quilt .rej file?
[01:31] <hyperair> micahg: it's a patch reject file. it just dumps out rejected hunks.
[01:31] <hyperair> micahg: just manually merge in the changes
[01:31] <hyperair> the changes specified in the *.rej file i mean
[01:32] <micahg> what do you mean by manually merge?
[01:32] <micahg> copy in vi?
[01:33] <hyperair> patches basically represent changes.
[01:33] <hyperair> and applying a patch is basically making said changes automatically.
[01:33] <hyperair> but sometimes, a patch cannot be applied due to changes in the source hunk.
[01:34] <hyperair> in this case, you have to look at the block that was supposed to be changed, and make the changes manually.
[01:34] <micahg> in the source file?
[01:34] <hyperair> yes
[01:34] <micahg> ah, then I can refresh?
[01:34] <hyperair> yes
[01:34] <micahg> hyperair: thank you...that's what I was missing
[01:34] <hyperair> =)
[01:36] <micahg> hyperair: that did it...
[03:21] <stooj> Does anyone know of a python programme that uses policy kit?
[04:14] <ScottK> jbernard_: OK.  Then maybe it's OK.  Thanks for looking.
[04:17] <rgreening> hey ScottK
[04:18] <ScottK> Who, me?
[04:19] <rgreening> lol
[04:38] <mdeslaur> Does UI freeze also apply to universe?
[04:39] <ScottK> mdeslaur: Only if there is stuff the doc team touches (there may be for mobile stuff, Ubuntu Studio, Mythbuntu, or Xubuntu).  Otherwise, no.
[04:41] <mdeslaur> thanks ScottK
[04:57] <mdeslaur> so, if I change a string in a universe package...do I need to update the po files?
[05:01] <mdeslaur> oh, I guess not
[05:51] <porthose> ScottK, if you have the time, would you mind looking at bug #426677 :)
[05:54] <ScottK> porthose: Just going to bed, but from reading your comment, you don't want to symlink it from pyshared.  Move it to dist-packages.
[05:54]  * ScottK goes to bed.
[05:56]  * porthose goes to bed also
[06:04] <fabrice_sp> LucidFox, here?
[06:09]  * virtuald ponders getting out of bed
[06:09] <fabrice_sp> LucidFox, you're upstream of qink, right? it's about qink FTBFS with libinklevel 0.8. In case you didn't noticed it, libinklevel 0.8.0 version string is "libinklevel 0.8.0" and not "libinklevel v0.8.0", so qink does not recognise it...
[06:10] <fabrice_sp> (configure script, I mean)
[06:18] <fabrice_sp> Anyway, I've reported it in the upstream bug tracker
[06:28] <dholbach> good morning
[06:35] <fabrice_sp> hey dholbach!
[06:36] <dholbach> hey fabrice_sp! :)
[06:36] <fabrice_sp> how are you doing this morning?
[11:26] <segler> please comment on my small rhythmbox plugin: http://revu.ubuntuwire.com/p/rhythmbox-radio-browser
[11:27] <slytherin> segler: how is this different from the already available internet radio functionality in rhythmbox?
[11:28] <segler> it makes the lists of dir.xiph.org and shoutcast.com searchable directly from rhythmbox, screenshot on http://programmierecke.net/programmed/rhythmbox-radio-browser.html
[11:29] <segler> iradio in rhythmbox is a minimal plugin, that radio stations can be played
[11:29] <segler> at all
[11:30] <slytherin> segler: looks good. but at this point we are past feature freeze, so new packages won't go in (unless there is very strong reason for it). And hence you will find MOTUs busy with fixing existing bugs.
[11:30] <segler> thanks, but maybe for the next version then
[11:32] <ScottK> segler: Of if you work on getting it into Debian now, more users will benifit and it will automatically come into Ubuntu for the next release.
[11:33] <slytherin> segler: As I said, it is hard to find people not already busy with other things at this stage of development cycle. New packages get best reviewed at the early stage of development cycle.
[11:33] <segler> is there also good documentation on archiving this for debian
[11:35] <segler> ?
[11:35] <directhex> mentors.debian.net i think
[11:35] <directhex> but i'd talk to pkg-multimedia
[11:35] <directhex> or maybe pkg-gnome
[11:35] <segler> thanks
[11:35] <slytherin> I guess pkg-gnome is right group.
[11:36] <slytherin> rhythmbox is official gnome module.
[11:36] <directhex> there's some overlap anyway
[11:36] <directhex> isn't that right, slomo
[14:07]  * RainCT thanks bdrung for fixing audacity! :)
[14:07] <bdrung> RainCT: np
[14:37] <jdong> *tries to remember the bzr shorthand for pushing to the pull URL*
[14:39] <jdong> unfair; totally undocumented AFAICT!
[14:39] <ScottK> jdong: bzr push :parent
[14:39] <jdong> ScottK: ah! thanks
[14:39] <RoAkSoAx> morning
[14:40] <ScottK> I suspect you're right.  I found out about it asking on #bzr.
[14:40] <RoAkSoAx> dholbach, Heya. I'll have the interview ready by the end of this weekend
[14:40] <dholbach> RoAkSoAx: ŝuper!
[14:40] <jdong> ScottK: yeah I overheard something like that before, so I knew it existed just not where.
[14:41] <Ryan52> what does MIR stand for?
[14:41] <jdong> Main Inclusion Report (Request?)
[14:41] <ScottK> Report
[14:42] <Ryan52> ah, cool.
[14:42] <Pici> !mir
[14:47] <Ryan52> asac, lool: once you guys get gnome-web-photo using the glue correctly, please let me know, I've been wanting to package it for Debian but that was what was holding me back. and of course I'm curious what I was doing wrong when I tried doing it myself :)
[14:48] <lool> Ryan52: Eh ok
[14:48] <asac> Ryan52: libxul.m4 is bogus
[14:48] <asac> i am not sure where all those m4 files come from
[14:49] <asac> the glue code is at least in place
[14:49] <asac> its just a matter of build system from what i can see
[14:49] <asac> is gnome-web-photo in gnome git?
[14:50] <asac> found it
[14:53] <ScottK> FYI, http://qa.ubuntuwire.com/bugs/rcbugs/ is updated and working.  Plenty of opportunity there for fixing stuff.
[14:53] <Laney> woop woop
[14:53] <bddebian> Heya gang
[14:56] <ScottK> Heya bddebian.
[14:57] <ScottK> bddebian: I thought you all removed all the gtk1.2 stuff already?
[14:58] <bddebian> Heya ScottK
[14:58] <ScottK> I've noticed a couple like dillo that are still there.
[14:58] <bddebian> ScottK: I've tried, see:  http://wiki.debian.org/Gtk1.2ImlibGnome1Removals
[14:59] <slytherin> any rsync experts here?
[15:07] <kimus> hi, ubuntu does not provide a xserver-xorg-video-ast (ASPEED). how can be created?
[15:12] <directhex> kimus, poke the ubuntu x11 guys
[15:12] <kimus> directhex: ok... I'll try to do that thanx
[15:32] <quadrispro> hi folks
[15:32] <quadrispro> any release manager here?
[15:32] <quadrispro> sistpoty|work: ping
[15:32] <sistpoty|work> quadrispro: what's up?
[15:35] <asac> Ryan52: http://people.canonical.com/~asac/tmp/0001-use-libxul-embedding-unstable.pc-.-plain-and-simple..patch
[15:35] <asac> Ryan52: thats the right approach
[15:35] <asac> now it fails to build because gnome-web-photo uses internal symbols directly
[15:35] <asac> namely: in Writer.cpp ... it uses gfxSurface etc.
[15:35] <asac> that should be done by using canvas.writeDocument
[15:36] <asac> rather than directly stabbing in the inner guts of gecko ;)
[15:36] <asac> i will do a second patch for that most likely removing almost everyhting that is in Writer.cpp
[15:36] <asac> anyway. off for the weekend
[15:51] <jbernard_> ScottK: im working on updating ksplice, is there something i should do to mark that as in-progress?
[15:52] <ScottK> jbernard_: Is this an updated merge?
[15:53] <jbernard_> ScottK: you're asking if there's a newer debian version?
[15:53] <ScottK> jbernard_: Yes.  Are you updating from Debian?
[15:53] <jbernard_> ScottK: yes
[15:53] <ScottK> jbernard_: You can leave a comment on merges.ubuntu.com that you are working on it.
[15:53] <jbernard_> ScottK: awesome, im on it
[15:55] <jbernard_> ScottK: im not able to find it in the list, am i missing something?
[15:57] <ScottK> jbernard_: I agree it's not there.  Not sure why.
[15:57] <ScottK> Maybe Adri2000 knows.
[15:57] <jbernard_> ScottK: the new debian version (0.9.9-1) hit sid about two weeks ago
[15:58] <jbernard_> ScottK: ill prepare a debdiff in any case
[15:58] <geser> why should it appear on MoM when the ubuntu version doesn't has an Ubuntu delta?
[15:58] <ScottK> Oh.  Right
[15:59] <ScottK> geser: Thanks.
[15:59] <ScottK> jbernard_: hopefully there is no debdiff, just a sync request.
[15:59]  * ScottK wonders off in search of more coffee
[15:59] <jbernard_> ahh, ok, no i follow
[15:59] <jbernard_> /s/no/now
[15:59]  * jbernard_ reaches for more coffee as well
[16:08] <RoAkSoAx> hey guys is there any wikipage  that shows the process to apply debdiff and upload the packages (for MOTUs)?
[16:09] <james_w> hey RoAkSoAx
[16:09] <james_w> congratulations
[16:09] <RoAkSoAx> james_w, thanks :)
[16:09] <james_w> apt-get source package
[16:09] <james_w> cd package-*
[16:10] <james_w> wget -O- <debdiff> | patch -p1
[16:10] <james_w> I think that's right
[16:10] <james_w> new upstream versions are different
[16:10] <james_w> or
[16:10] <james_w> bzr branch lp:ubuntu/package
[16:11] <james_w> bzr patch --strip 1 <debdiff>
[16:11] <ode> hi
[16:11] <james_w> merges require different arguments to debuild as well
[16:11] <ode> i uploaded an updated version of a package to revu but it is not showing up
[16:11] <RoAkSoAx> james_w, awesome, thanks. But isn't there a wikipage that explains everything?
[16:12] <james_w> RoAkSoAx: I've not seen one. Write one!
[16:13] <RoAkSoAx> james_w, yeah!! will do that. I'll just gather the information needed and will setup a wikipage :)
[16:13] <james_w> nice
[16:20] <ode> if i update a package to fix some problems that revu reports should I bump the version number i.e. ubuntu1 to ubuntu2, and then upload again. Or leave it as it is?
[16:21] <geser> for REVU you can keep (and should) it at -0ubuntu1
[16:22] <ode> thanks
[16:30] <slytherin> ode: did you use -f option for dput?
[16:31] <ScottK> RoAkSoAx: There is one.  I don't remember where it is. (wiki page)
[16:31] <RoAkSoAx> ScottK, I've been trying to search for it with no luck :S :(
[16:32] <ScottK> RoAkSoAx: OK.  As james_w said, it's just like applying a patch.  Then debuild -S -k(yourkeyid/email...).  The dput like you would to a PPA, but to ubuntu.
[16:33] <ode> slytherin: yeah I did but I think I made an error with the version number
[16:33] <ode> i'll fix and try again
[16:34] <RoAkSoAx> ScottK, that's the same process for any kind of debdiff (which can be a merge debdiff or a bugfix debdiff)?
[16:34] <ScottK> RoAkSoAx: Yes, unless there is a new upstream release involved.
[16:34] <RoAkSoAx> ScottK, and how are new upstream releases dealt?
[16:34] <ScottK> Then if you have the tarball, you need to add -sa to debuild.
[16:35] <RoAkSoAx> I see, I always build my packages both ways so it's ok
[16:35] <ScottK> You should fetch the tarball from upstream yourself and then take the sponsoree's diff.gz and apply it (decompress and apply as a patch)
[16:36] <ScottK> One of the key security principles is that we 'trust' upstream code, so you need to take the upstream code from upstream and not assume a non-developer has given it to you untampered.
[16:36] <ScottK> RoAkSoAx: ^^
[16:38] <RoAkSoAx> ScottK, awesome! Thanks :)!
[16:39] <ScottK> RoAkSoAx: I also recall having approximately the same questions when I made MOTU two years ago.
[16:40] <RoAkSoAx> ScottK, haha. Yeah, these are exciting moments :)
[16:53] <iulian> RoAkSoAx: You might find https://wiki.ubuntu.com/MOTU/New useful.
[16:53] <RoAkSoAx> thanks iulian :)
[16:54] <ScottK> iulian: That's the page I was thinking of.  Thanks.
[16:57] <iulian> No problem.
[16:58] <iulian> So, new MOTUs, eh?  Congratulations to them.
[16:58] <ScottK> Someone who cares about latex might want to look into syncing vim-latexsuite.
[17:01] <iulian> Hm, it seems that http://vim-latex.sourceforge.net/ is not responding.
[17:02] <iulian> Ah.  It worked.
[17:06] <ScottK> iulian: What's in Debian represents a considerable update.
[17:24] <fabrice_sp> Hi. If a lib appears in the NBS page, and it's normal (changed from lib1 to lib2), should we fill a remove request for the binary package (lib1 in my example)?
[17:24] <ScottK> fabrice_sp: No.  Once it has no rdends left it'll get cleared up
[17:25] <fabrice_sp> ok
[17:25] <fabrice_sp> thanks
[17:30] <iulian> ScottK: Yea.  I couldn't find a ChangeLog or a NEWS file.  It will need a FFe.
[17:31] <iulian> ScottK: There is a debian/RELEASE-1.5.txt file. I found out that 1.5 was released in 2003.
[17:33] <iulian> I'm definitely looking in the wrong direction.
[17:33] <ScottK> iulian: Yes.  I think it's enough of an update we ought to take it if someone can verify it works.
[17:33] <iulian> ScottK: That's what I was planning.
[17:36] <ScottK> RoAkSoAx: If you want something to work on, http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-4.4;users=debian-gcc@lists.debian.org probably has some patches we could do with.
[17:37] <ScottK> If you find packages that FTBFS on http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20090909.html that have patches there, it's a good chance we need the patch
[17:38] <diwic> ScottK: Is it just a coincidence that all packages on that list start with the letters a - f ?
[17:39] <ScottK> diwic: The rebuild gets done in alphabetical order.  That's as far as it is.
[17:39] <RoAkSoAx> ScottK, awesome! I'll work on it. Thanks :)
[17:39] <ScottK> Also that page only updates every two hours.
[17:39] <ScottK> RoAkSoAx: Feel free to invite new contributors to help you and sponsor them.
[17:40] <diwic> scottk: somebody needs a faster build machine ;-)
[17:40] <ScottK> diwic: It's done on the PPA builders whenever one is not otherwise in use.
[17:40] <RoAkSoAx> ScottK, will do :)
[17:43] <geser> RoAkSoAx: don't forget to check if there isn't a fixed package in the archive already. I'm going through this list and trying to fix all those "invalid conversions" errors.
[17:47] <RoAkSoAx> geser, ok :)
[17:50] <ScottK> geser: At the release team meeting today slangasek and sistpoty discussed trying to get a training session together to teach MOTU/hopefuls how to work on solving these FTBFS.
[17:53] <geser> ScottK: the "invalid conversion" ones are pretty easy to fix (mostly add a "const", but some C/C++ knowledge is still useful), so they would be a good candidates for new contributors
[17:54] <slangasek> geser: eh, *don't* add const for the invalid conversion ones
[17:54] <slangasek> that's a bug in the toolchain, not in the packages that are FTBFS
[17:54] <slangasek> and when the toolchain is fixed, they'll FTBFS again if changed
[17:55] <geser> slangasek: oh
[17:56] <slangasek> perhaps I should fix that in eglibc and ask for another rebuild test
[17:56] <geser> slangasek: the declaration for strchr() on a const char* seemed pretty logic to return a const char *
[17:56] <slangasek> geser: but that's not how the function is defined
[17:57] <slangasek> (cf. the manpage)
[17:58] <geser> in that case it would be perhaps good to stop the rebuild till it's fixed as there are many of these in the FTBFS list for the rebuild
[17:59] <geser> so it's hard to find the real ones
[18:05] <oussama> hi everybody
[19:20] <randomaction> I have packaged a new upstream version, do I have to upload to LP anything besides .diff.gz? (I assume that .tar.gz should be taken from upstream anyway, and .dsc generated from it)
[19:22] <sistpoty> hi folks
[19:22] <geser> randomaction: only the .diff.gz is necessary
[19:23] <randomaction> great, thanks
[19:25] <geser> if the package doesn't have a watch file which makes it easy to fetch the new .orig.tar.gz, perhaps a link to the new upstream tarball would be helpful to save your sponsor the time to go hunting for it
[19:30] <randomaction> Yep, I have added both.
[19:46] <sistpoty> is anyone interested in an instant fix ftbfs session?
[19:46] <sistpoty> (as we've got lot's of ftbfs, see http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20090909.html)
[19:48] <diwic> sistpoty: there was a discussion two hours ago whether to fix them or not
[19:48] <diwic> sistpoty: seems like an error in the toolchain was causing at least some of them
[19:48] <ScottK> diwic: It was decided that was not the case.
[19:49] <diwic> ok
[19:49] <geser> diwic: they should be fixed again (see the log for #ubuntu-devel)
[20:11] <sistpoty> so anyone interested in a fix ftbfs session here? I'd help with c/c++ issues
[20:12] <sebner> sistpoty: I'd attend for sure :)
[20:12] <sistpoty> :)
[20:13] <sebner> sistpoty: what do you mean with "instant", right now?
[20:13] <sistpoty> sebner: yes
[20:13] <sebner> sistpoty: I have to fix something first :P
[20:13] <sistpoty> hehe
[20:14]  * porthose has notpad and pen ready
[20:14] <sebner> porthose: good you didn't write "notepad" :P
[20:14] <sistpoty> excellent!
[20:14] <porthose> god I can't type today :)
[20:15] <sistpoty> slangasek: got some time to jump in as well, if tough questions arise?
[20:15]  * slangasek waves wildly
[20:15] <sistpoty> wohoo, cool, so let's get started.
[20:16] <sistpoty> so first off, the list we'll deal with is http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20090909.html, which is the current rebuild test (still going on, so the list will increase as buildds come to it)
[20:16] <sistpoty> let's grab a nice one
[20:17] <sistpoty> how about adanaxisgpl
[20:17] <sistpoty> the (F) link goes straight to the build log, so let's take a look at it
[20:17] <sistpoty> and also let's grab the source while looking at the build log
[20:18] <sistpoty> (crack, why did I pick a large package :/)
[20:18] <sistpoty> while the source downloads, it's a good idea to also look at debian's BTS, maybe there's a bug there open already, or a new version which we can pick up
[20:19] <sistpoty> with the "PTS" link, you can see the package tracking system, and see if there's a newer version in unstable
[20:19] <sistpoty> the "BTS" link is straight to debian's bug tracking system
[20:20] <geser> I would help out in the session as I'm currently fixing FTBFS anyway :)
[20:20] <sistpoty> geser: excellent, so feel free to chime in :)
[20:21] <sistpoty> so we can see, that a) there's no new version in unstable, b) there is no build failure bug open in unstable... which means that we need to tackle it ourselves
[20:22] <diwic> there is one in mentors.debian.net though
[20:22] <sistpoty> diwic: oh, nice, excellent!
[20:22] <diwic> wait
[20:22] <diwic> that one's an older version?
[20:23] <sistpoty> diwic: got a link? (can't see it on mentors right now)
[20:24] <diwic> sistpoty: http://packages.qa.debian.org/a/adanaxisgpl.html lists it, but when I click on the link I just get an error. That version was older anyway
[20:24] <sebner> diwic: it's not on mentors --> http://mentors.debian.net/debian/pool/main/a/
[20:25] <sistpoty> diwic: yep, that's an older version, which got purged from mentors after the upload
[20:25] <geser> sistpoty: you should have picked avifile, it's a nice case that upstream got lucky that it worked till now
[20:25] <ScottK> sistpoty: You should just make bddebian fix this one himself.
[20:26] <sistpoty> ScottK: haha
[20:26] <sistpoty> geser: I'll leave avifile for you to explain how to fix it ;)
[20:27] <sistpoty> ok, so on PTS however there's also a link to svn, let's see if there's something that helps fixing it: http://svn.debian.org/wsvn/pkg-games/packages/trunk/adanaxisgpl/?op=log
[20:28] <sistpoty> which somehow doesn't look like it's working... maybe it was moved to git, *shrug*
[20:28] <sistpoty> so at this point, it's get interesting, we'll have to fix it ourselves (so I guess I picked a good package *g+)
[20:28] <sistpoty> let's look at the first error in the build log
[20:29] <sistpoty> to make it clearer, I've pastebin'd it: http://paste.ubuntu.com/269361/
[20:30] <sistpoty> and forgot the interesting line, d'oh
[20:30] <sebner> sistpoty: websvn is working for me but nothing helpful there
[20:30] <sistpoty> sebner: ah, k, then I clicked on something wrong *g*
[20:30] <sebner> heh
[20:30] <sistpoty> so here's the interesting bit included: http://paste.ubuntu.com/269362/
[20:31] <sistpoty> it says invalid conversion from const char * to char *
[20:32] <sistpoty> w.o. looking at the code, this looks like a constant string was passed to a function requesting a char *
[20:32] <ScottK> We have approximately a bazillion packages that FTBFS on they type of error.
[20:32] <ScottK> they/this
[20:32] <sistpoty> so let's look at the C side...
[20:32] <sistpoty> in C, if you write "hello world", that will be of the type "const char *"
[20:33] <sistpoty> the content of the pointer is stored somewhere in the data section
[20:33] <geser> sistpoty: in most FTBFS listed on the page this error is caused by assigning a const char* to a const * (e.g. from strchr())
[20:33] <geser> the return value from strchr()
[20:34] <sistpoty> ah, I see
[20:34] <sistpoty> so the content in the data section should really change (i.e. "hello world" shouldn't get overwritten w. something else)
[20:35] <sistpoty> earlier on, gcc was lenient and didn't care too much
[20:35] <sistpoty> so to denote that the content doesn't change, there's the const keyword
[20:35] <sistpoty> so here comes the tricky part:
[20:35] <sistpoty> if a library function returns a pointer which points inside the string, the return value must also be declared const
[20:36] <sistpoty> (because you still mustn't be able to change the contents with the returned pointer)
[20:36] <sistpoty> let's take a look at the code at ./Platform/X11/PlatformMiscUtils.cpp:1245, and see if this is the case here
[20:37] <geser> which is the case now with g++ 4.4 and the reason why this appears now (see man strchr() for the C syntax)
[20:38] <geser> strchr() has in C++ two declarations (one for char* and one for const char*) and g++-4.4 checks it now
[20:38] <sistpoty> so this line is: end = strrchr (path, '/');
[20:38] <geser> the same applies for similar functions
[20:38] <sistpoty> and end is declared as char *
[20:40] <sistpoty> in this function, end is not modified, so we can simply change it to be a const char *
[20:40] <sistpoty> let's try a rebuild
[20:40] <randomaction> ironically, the next line is: if (end == (const char *) NULL)
[20:40] <sistpoty> heh, yes
[20:42] <sistpoty> so while my box is rebuilding, a small side note:
[20:42] <sistpoty> if you have to fix more compile errors, or need several tries, it makes sense to simply install the build dependencies and rebuild with make -f debian/rules binary
[20:43] <sistpoty> that way, usually only the changed files will get rebuilt (given the upstream build system is getting it right)
[20:43] <ScottK> porthose: pysvn uploaded.  Thank you for your contribution to Ubuntu.
[20:43] <porthose> woot thx ScottK :)
[20:43] <sebner> sistpoty: If seen many missing include <cstdio> stuff, what's the magic there?
[20:44] <ScottK> sebner: Google has lots of good answers on that one.
[20:44]  * ScottK needs to run.
[20:44] <RainCT> Laney: did you get your system booting again? :)
[20:45] <sebner> ScottK: isn't that a Q&A session :P
[20:45] <slangasek> "magic"?
[20:45] <slangasek> there's no magic, just include cstdio where it should be included? :)
[20:45] <sistpoty> sebner: earlier on, many c++ headers included other headers
[20:45] <ScottK> Yep
[20:45] <sebner> slangasek: in other words: why does upstream don't do it
[20:45] <sistpoty> sebner: so that <cstdio> was in fact included by a different header
[20:45] <geser> sistpoty: mine rebuild is done (successful)
[20:45] <sistpoty> sebner: so it did built back then
[20:45] <sistpoty> geser: wohoo
[20:45] <slangasek> sebner: because g++ was less strict before and the headers were included by accident, so upstream didn't notice
[20:46] <sebner> grrrr -.-
[20:46] <sebner> sistpoty: do you also have such an example, /me forgot the FTBFS message for this ones
[20:46] <geser> sistpoty: have you an idea how to fix the FTBFS for avifile? http://launchpadlibrarian.net/31591921/buildlog_ubuntu-karmic-i386.avifile_1%3A0.7.47.20070718-1.2ubuntu1_FAILEDTOBUILD.txt.gz
[20:46] <geser> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/karmic/avifile/karmic/annotate/head%3A/lib/aviplay/aviplay.cpp
[20:46] <geser> ^^ that's the source file
[20:47] <sistpoty> sebner: I'd have to look for this... iirc there also was a mail from Martin Michlmayr explaining a few c++ errors wrt the new gcc, but I don't recall right now where that mail is (anyone got a pointer)?
[20:47] <sebner> geser: lol, isn't that the other way round?
[20:48] <sebner> sistpoty: kk, np
[20:48] <diwic> sistpoty: I decided to try another package just to follow, but apt-get build-depends failed, one of the packages got a 404 not found error. :-(
[20:48] <sistpoty> diwic: run apt-get update
[20:50] <sistpoty> geser: hm... should be the same thing actually, though I can't say for sure how strrchr is defined in c++ (or why it would be needed in the first place)
[20:50] <c_korn> p is not used after if(p). so *p=0 can be removed I think
[20:50] <RainCT> sistpoty, geser: yay, the coredump works with gnome-voice-control. Now I need to know wth I can do with this file, though :P
[20:51] <sistpoty> c_korn: no, the "." is removed in the string, should there be any (in a quite hacky way)
[20:51] <geser> c_korn: no, the idea it that the filename (fn) should be terminated at the place with "." (if there is any)
[20:52] <sistpoty> geser: according to http://www.cppreference.com/wiki/string/start, c_str() returns something non-modifiable
[20:52] <geser> the problem here is that fn.c_str() returns a const char *, strrchr(const char*, int) returns also a const char *
[20:52] <geser> so *p should be a const char *
[20:52] <geser> in which case *p = 0 is illegal
[20:53] <sistpoty> yes
[20:54] <geser> this code needs to be modified to work on "string" (C++)
[20:54] <geser> I'm curious why this didn't cause any problems (any crashes)
[20:55] <slangasek> why would it?
[20:55] <sistpoty> geser: how about size_t p = fn.rdin('.', 0)
[20:55] <sistpoty> if (p != std::string::n_pos) { fn.erase(p, 1); }
[20:56] <sistpoty> rfind even
[20:56] <geser> slangasek: I assume it didn't crash because c_str() used modifiable space (even when it returned it as const char *), correct?
[20:57] <sistpoty> bleh, of course not 1, but fn.erase(p, fn.size() - index - 1)
[20:57] <sistpoty> (might still be off by one, /me recalculates)
[20:57] <slangasek> geser: yes, that's almost always the case
[20:58] <sistpoty> fn.erase(p, fn.size() - index)... that should be it
[20:58] <slangasek> all pointers to read-only memory must be const by definition, but most const pointers don't point at read-only mem
[20:59] <sistpoty> slangasek: and iirc even string constants don't reside in read only pages, correct?
[21:01] <sistpoty> geser: anyways, since you were first to have the rebuild finished, maybe you'd like to explain the final steps (like getting the adanaxisgpl patch as a patch, forwarding it to debian and upload it?)
[21:02] <geser> sure
[21:02] <sistpoty> thanks, then I'll go out for a smoke, be back in 5 mins :)
[21:02] <geser> so we know now how to fix it
[21:03] <geser> the first step would be to check if the package uses a patch system
[21:03] <geser> what-patch (from ubuntu-dev-tools) helps with this
[21:03] <slangasek> sistpoty: string constants will usually be in read-only pages
[21:04] <geser> what-patch returns for this package that it uses quilt
[21:04] <geser> (an other way would be to look for debian/patches)
[21:05] <geser> so lets get the change into a quilt patch
[21:06] <geser> as I regularly forget the magic for quilt, I use https://wiki.ubuntu.com/PackagingGuide/Howtos/Quilt as a reminder
[21:07] <Daviey> Hey, if i
[21:07] <Daviey> Hey, if i'm cherry picking a patch from Debian.. should the changelog state "Cherry picked from Debian"?
[21:08] <geser> Daviey: yes, it makes it easier during the next merge to know that the patch is already in Debian
[21:08] <Daviey> geser: they way it's heading it's going to be constantly diverged from Debian :(
[21:09] <geser> can you explain?
[21:10] <sistpoty> slangasek: ah, thanks
[21:10] <geser> back to our quilt patching: "export QUILT_PATCHES=debian/patches" to let quilt know where the existing patches are
[21:10] <Daviey> geser: Debian don't want to adropt dkms at the moment for this package.
[21:12] <geser> Daviey: but it's still good to know that the patch came from Debian and that we don't need to forward it (independent of any Ubuntu delta we need to keep for a longer time)
[21:12] <Daviey> sure, thanks.
[21:13] <geser> the next step is then to apply all existing patches (quilt push -a), create a new one (quilt new 40_fix-invalid-conversion.diff (or similar))
[21:14] <geser> add the file we need to modify to it (quilt add src/Platform/X11/PlatformMiscUtils.cpp)
[21:14] <geser> edit the file with an editor of your choice
[21:15] <sebner> geser: without looking at the patch list, why did you pick 40?
[21:15] <loic-m> jdstrand: thanks for the gmameui upload
[21:15] <diwic> geser: are you actually rewriting the code a second time now?
[21:16] <geser> sorry, missed a step: look at the existing patches to see how they are numbered and named
[21:16] <loic-m> jdstrand: however I can't find a config.log file in the source package
[21:16] <jdstrand> loic-m: did you check the diff.gz?
[21:16] <geser> diwic: perhaps I should mention that I check which patch system is used before I start changing anything
[21:18]  * sistpoty usually modifies directly but adds a new changelog entry and then debdiffs to get a patch
[21:18] <geser> after the look at debian/patches I picked 40 as that looked like the next step in numbering (we don't need to push our patch somewhere in between the existing patches)
[21:18] <loic-m> Ijdstrand: yes, I always check for files not in debian/ . Is it possible the diff.gz sent to you wasn't exactly the one I uploaded to REVU
[21:19] <Daviey> sistpoty: thought about scripting that process?
[21:20] <sistpoty> Daviey: not really... the main point is looking at the debdiff (to catch other maybe build system related changes, that shouldn't be there), and I wouldn't know how to automate this
[21:20] <diwic> sistpoty: If you modify directly, won't you get lintian warnings for having modifications outside debian subdir?
[21:21] <geser> when we are done with any changes, "quilt refresh" to update the quilt patch, and "quilt pop -a" to de-apply all patches
[21:21] <geser> in the case of quilt we don't need to add our patch to debian/series (quilt did it already for us) (for dpatch one has to add it manually to patches/00list)
[21:22] <sistpoty> diwic: well, if there's a patch system, yes... but I change directly and pick the patch then from the debdiff and integrate it into the patch system if everything works for the final upload (of course after rebuilding it again and running lintian *then*)
[21:22] <c_korn> (in karmic quilt now has an option "shell" which makes it behave like cdbs-patch)
[21:22] <geser> the next step would be to add a changelog entry (dch -i)
[21:23] <geser> if our change is the first Ubuntu change to this package don't forget to run "update-maintainer"
[21:24] <geser> if I didn't forget anything we should be able to build the new source package now (debuild -S)
[21:24] <sebner> geser: what would you do if patches are like this: 2_foo, 4_bar,  foobar, barfoo, 30_foobarfoo, 40_barfoobar?
[21:24] <geser> running "debdiff" inside the package dir will gives us the debdiff for our changes
[21:25] <geser> sebner: curse about the maintainer
[21:25] <sebner> geser: heh
[21:25] <sebner> geser: that too
[21:25] <ScottK> Also if you're on Jaunty or earlier, don't forget that the correct Ubuntu maintainer is now Ubuntu Develpers <ubuntu-devel-discuss@lists.ubuntu.com>
[21:26] <sebner> geser: pretty neutral would be to use 99 or? ^^
[21:26] <geser> I had a similar case for an other FTBFS. had to name my patch ubuntu_... go get it sorted last
[21:27] <geser> sebner: IIRC 0-9 sorts before a-z, so I would name it with something larger than foobar
[21:28] <jdstrand> loic-m: I'm not sure how REVU will process the upload, but it certainly should be the same.
[21:28] <randomaction> actually, the order of patches is governed by patches/series, so their names are not really important
[21:28] <geser> if the package uses quilt or dpatch
[21:28] <jdstrand> loic-m: if you unpack the source package, it is in there
[21:28] <sistpoty> jdstrand: revu doesn't fiddle with the files (apart from the .changes file, which imo only gets made non-readable)
[21:28] <ScottK> randomaction: That's true for Quilt
[21:29] <geser> for cdbs-simple-patch no such file exists
[21:29] <jdstrand> loic-m: in the diff.gz: +++ gmameui-0.2.10/config.log
[21:29] <jdstrand> sistpoty: thanks
[21:29] <slangasek> if it uses cdbs-simple-patchsys, petition the Debian maintainer to use something sane instead :-P
[21:29] <sistpoty> jdstrand: np... at least that's true unless RainCT changed it *g*
[21:29] <sebner> geser: kk, thx
[21:30] <geser> once we checked that our debdiff contains only our expected changes we can redirect it into a file which we can use for attaching to LP
[21:30] <randomaction> oh thanks, live and learn
[21:31] <geser> in case a sponsoring is needed I put a "(lp: #xxx)" placeholder into my changelog entry, open a bug on LP, and replace the "xxx" inside the debdiff with the real bugnumber with an editor
[21:31] <RainCT> sistpoty: what have I done? :P
[21:31] <geser> now just the normal sponsorship process follows
[21:32] <sebner> slangasek: quilt quilt quilt is the only choice here ;-P
[21:33] <geser> for submitting the patch to Debian, I edit the debdiff and remove the Ubuntu specific parts (like the changelog entry and the Maintainer change) (is there a tool for it?)
[21:33] <slangasek> geser: submittodebian
[21:33] <slangasek> (removes the changelog entry, not the maintainer change)
[21:33] <geser> slangasek: does it filter out the Ubuntu specific changes?
[21:33] <loic-m> jdstrand: I'm really sorry, I must be blind. To make sure I'm looking at the same diff.gz, I dl it from http://revu.ubuntuwire.com/revu1-incoming/gmameui-0908292321/gmameui_0.2.10-0ubuntu1.diff
[21:33] <loic-m> jdstrand: and I can't find any config.log string
[21:33] <jdstrand> https://launchpad.net/ubuntu/karmic/+source/gmameui/0.2.10-0ubuntu1
[21:34] <jdstrand> loic-m: ^ that is what was in the queue and what I accepted/commented on
[21:34] <geser> in case I needed to change something in debian/control, so that's it not simple to remove it from the debdiff, one needs to prepare a specific debdiff just for debian
[21:34] <loic-m> jdstrand: that's not what I uploaded. I only uploaded to REVU, and it's still there
[21:34] <ScottK> deupdate-maintainer would be a simple enough script.
[21:34] <geser> and finally I use reportbug to open a bug about the problem in Debian and attach my trimmed debdiff to it
[21:35] <diwic> geser: and lesson one; don't pick a package someone else did 4 hours ago. *bangs head against the wall*
[21:35] <jdstrand> loic-m: please bring it up to your reviewer on REVU
[21:35] <geser> diwic: which one did you pick?
[21:35] <diwic> geser: alsaplayer
[21:35] <loic-m> jdstrand: ok, I'll tell him, and ask what he did. Thanks
[21:35] <geser> diwic: at least you can compare if you would have done it the same way
[21:36] <loic-m> RainCT: ping
[21:36] <sistpoty> RainCT: I only implied that I don't know what you have done :P
[21:36] <RainCT> loic-m: yeah, I'm here wondering what's up :P
[21:36] <loic-m> ok, I'm puzzled. I'd never upload a diff like that
[21:37] <RainCT> ohh, nice diff :P
[21:37] <geser> and if I didn't forget anything (like testbuilding before you submit your changes to Ubuntu and Debian) we are done and can pick the next FTBFS
[21:38] <diwic> geser: solution was the same, yes.
[21:38] <sebner> geser: yeah, next FTBFS \o/
[21:39] <RainCT> loic-m: why is there no orig.tar.gz on REVU?
[21:39] <randomaction> geser: is it a good idea to submit the patch to upstream as well?
[21:39] <loic-m> RainCT: probably because the last upload I did, the gmameui page on REVU was already archived
[21:40] <geser> randomaction: yes (but usually I'm too lazy to go looking how to submit it upstream and register in an amount of different bugtracking systems)
[21:41] <RainCT> Shouldn't make a difference. Well, anyway
[21:41] <sebner> geser: mail to DM with the debdiff and the note: Please also submit to upstream :P
[21:41] <loic-m_> RainCT, sorry, got disconnected
[21:42] <loic-m_> I missed everything since my line at [22:39]
[21:42] <sistpoty> loic-m: the 0902292321 changes file was signed by 5E593B80, your key? (keyserver is very slow for me :/)
[21:42] <porthose> sistpoty geser thx that was very informative :)
[21:42] <loic-m_> yes, my key
[21:42] <loic-m_> however, that's not what I uploaded to REVU
[21:43] <geser> note: I've just uploaded our fix for adanaxisgpl
[21:43] <sistpoty> loic-m: can you explain?
[21:43] <sistpoty> geser: thanks a lot!
[21:44] <sistpoty> so for the session, I guess we'll continue now that everyone tries to fix a ftbfs
[21:44] <sistpoty> and if there are any c/c++ related questions, just ask here
[21:44] <sistpoty> ideally providing a) a link to the build log and b) a link to the source file (or pasting the interesting bits of the source file)
[21:45] <loic-m_> RainCT: the config.log isn't the only problem, the .desktop file got processed borked too (encoding of non-English letters), which isn't the case for the diff.gz on REVU
[21:45] <RainCT> loic-m_: uhm I'm trying to reproduce getting a .diff.gz like that but everything shows up clean
[21:45] <RainCT> loic-m_: the encoding is a firefox problem, Edit -> Encoding -> UTF-8
[21:46] <sistpoty> loic-m_, RainCT: oh, interesting, there's a .diff and a .diff.gz in that directory
[21:46] <sistpoty> RainCT: is the .diff generated from debdiff?
[21:46] <RainCT> sistpoty: On REVU? That's a gunzip or something like that
[21:46] <sistpoty> RainCT: yes, look at /srv/archive/revu1-incoming/gmameui-0908292321
[21:47] <bdmurray> How do I request to join the universe sponsor's team?
[21:47] <loic-m_> RainCT: you're right, the encoding in the tar is correct
[21:47] <sistpoty> RainCT, loic-m_: the .changes file only lists the correct files (no .diff referenced)
[21:48] <sistpoty> bdmurray: try contacting the team admins
[21:48] <geser> the next easy "invalid conversion" error is bobcat
[21:48] <RainCT> sistpoty: (the .diff is created by a file in hook.d: http://paste.ubuntu.com/269391/, that's code from you or siretart I guess, but anyway not relevant to the discussion)
[21:49] <geser> I skipped some missing header errors for now, so they are still open
[21:49] <sistpoty> persia, TheMuso: ^^ (bdmurray)
[21:50] <sistpoty> RainCT: interesting snippet, which I'm sure that I didn't write it *g*
[21:50] <loic-m_> RainCT: is theer a way to see where the archive-admins got that diff.gz from?
[21:51] <bdmurray> sistpoty: thanks
[21:51] <sistpoty> bdmurray: thank you for volunteering to sponsor packages ;)
[21:52] <RainCT> loic-m_: iirc I uploaded gmameui from http://revu.ubuntuwire.com/details.py?upid=6555 after fixing debian/copyright
[21:52] <RainCT> I recently clean my ~/tmp/ directory (where I do reviews and stuff) so I can't check how it looked
[21:53] <loic-m_> RainCT: the old diff.gz I uploaded didn't have the config.log file either, because else lintian would have complained
[21:53] <sistpoty> loic-m_: not knowing if the info is on lp somewhere, the karmic-changes list should have the details (though iirc nowadays the .changes file is stripped of the signature :/)
[21:54] <loic-m_> RainCT: for the copyright change, I did it on the August 29 upload
[21:54] <loic-m_> (and emailed you+archive admins)
[21:55] <RainCT> loic-m_: Yeah, I think I uploaded before that fixing it myself, but that was:  dget ..; cd ..; geany debian/copyright; debuild -S -sa -krainct@ubuntu.com, but now I've been trying running debuild and dpkg-buildpackage and the .diff.gz remains clean so I don't know how it can have got in there
[21:56] <RainCT> (maybe because now I'm on Debian and I did that on Karmic)
[21:56] <loic-m_> ok
[21:56] <RainCT> (err Jaunty rather)
[21:56] <sistpoty> bdmurray: btw., regarding #ubuntu-review debate, did you mean it to be intended for upstream having questions about development on ubuntu?
[21:56] <RainCT> loic-m_: anyway, is this just about "omg where did that file come from?" or is there some problem?
[21:57] <sistpoty> bdmurray: because after thinking a while, I think such a channel would indeed be worthwhile to have, if marketed properly
[21:59] <loic-m_> RainCT: I just didn't understand jdstrand comment on the n-p bug report, and was wondering how the file got there in the diff.gz, and if there was anything to check in debian/rules in case something didn't get cleaned up properly
[22:06] <ahe> i'd like to ask two questions about ppa:
[22:06] <ahe> is it normal that my package always ends up in main although the section is universe/sound?
[22:06] <RainCT> ahe: Yes, PPAs only have a "main" section
[22:07] <ahe> can i build jaunty and karmic packages (no differences except for the distribution name) from a single source package?
[22:07] <ahe> RainCT: a thanks, so at least it is not my package :)
[22:08] <RainCT> ahe: Nope, I think you have to upload it twice with different version numbers (I suggest appending ~ppa1 for Karmic and ~ppa1~jaunty1 for Jaunty).
[22:08] <sistpoty> there's a but about that though :)
[22:10] <geser> bug 235064
[22:12] <ahe> is it of any use to upload to revu during the freeze or should i better only maintain my packages in my ppa and wait for the time after the freeze?
[22:13] <loic-m_> ahe: you can still get reviews and work on your package, even if it only makes it for Karmic+1
[22:15] <sistpoty> (though there won't be many motus doing reviews during freeze time, as they'll spend time on fixing bugs or ftbfs instead... at least I hope so *g*)
[22:19] <sistpoty> hm... I'm seeing no further questions regarding ftbfs... is everyone who listened to the session working on one? *g*
[22:23] <randomaction> sistpoty: I fixed boswars
[22:23] <sistpoty> excellent, randomaction!
[22:23] <randomaction> only to find that it was already fixed in Debian (
[22:24] <binarymutant> alright I'm stumped, why is my watchfile not pulling? http://paste.debian.net/46323/
[22:24] <randomaction> so I filed a sync bug LP: #428116
[22:24] <sistpoty> randomaction: if you find anything with maintainer "Debian Games Team", you could also try asking in #debian-games on oftc.net
[22:26] <geser> randomaction: don't forget to subscribe the sponsors team if you want it ACKed
[22:26] <sistpoty> binarymutant: not too sure if uscan can actually deal with references within a page... the real download url for e.g. net-scp-1.0.2.tar.gz seems to be http://rubyforge.org/frs/download.php/51292/net-scp-1.0.2.tar.gz
[22:27] <randomaction> geser: Sure. Usually requestsync did it for me, but it crashed this time.
[22:29] <binarymutant> sistpoty, hmm, this one works and it's from the same project though :/   http://paste.debian.net/46326/
[22:32] <sistpoty> binarymutant: sorry, no clue
[22:33] <binarymutant> ty for trying :D
[22:48] <sebner> sistpoty: I'll try to fix one tomorrow :) I wish a good night and thanks for the "instant" session =)
[22:49] <sistpoty> sebner: thanks and good night
[22:53] <Laney> RainCT: Didn't try yet, that's tomorrow's job
[22:53] <Laney> :(
[23:07] <Ryan52> asac: ah. I will admit that I didn't try that :)
[23:07] <Ryan52> asac: and wouldn't have thought to..
[23:23] <Zhenech> mezgani, hey
[23:37] <phil_ps> hey I am trying to use printk
[23:37] <phil_ps> I tried viewing with klogd
[23:37] <c_korn> I try to fix d4x. the diff.gz makes changes outside the debian/ directory (including configure) should I also move those changes into a patch ?
[23:37] <phil_ps> I restarted it and then did #klogd -c 8
[23:39] <sistpoty> c_korn: rule of thumb: if there's no patch system, don't add one ;)
[23:40] <c_korn> sistpoty: so also my fix about the FTBFS bug should directly go into the sources? without a patch system ?
[23:41] <sistpoty> c_korn: if there isn't one, yes. If there's a patch system, you should use this
[23:41] <c_korn> sistpoty: ok, thanks.
[23:43] <c_korn> ok, I need the same solution as before: http://pastebin.com/d7e8e3a20
[23:43] <c_korn> what was it ?
[23:45] <c_korn> tmp1 in line 3 should be const
[23:45] <sistpoty> c_korn: not 100% sure if it's as easy as declaring one variable from char * to const char *. Got the build log as well?
[23:46] <c_korn> sistpoty: build log is here http://launchpadlibrarian.net/31612667/buildlog_ubuntu-karmic-amd64.d4x_2.5.7.1-6_FAILEDTOBUILD.txt.gz
[23:46] <sistpoty> c_korn: that wouldn't work, then tmp1 couldn't be modified
[23:46] <c_korn> yes, I was about to mention that.
[23:47] <c_korn> line 1453 is line 3 in my paste
[23:47] <sistpoty> wow, that are lots of warnings regarding string constants -> char *.
[23:47] <Hosein-mec_> i uploaded my package to Launchpad successfully but didnt receive email from Launchpad yet. any help ?
[23:49] <c_korn> Hosein-mec_: how long did you wait ? it can take some minutes
[23:49] <c_korn> Hosein-mec_: also #launchpad is the better place for such questions
[23:49] <sistpoty> c_korn: you could be evil and try to force cast it to char *.... char *tmp1=(char *)index(tmp,':');
[23:49] <sistpoty> c_korn: not too sure if that works though
[23:49] <Hosein-mec_> c_korn: more than 45 minutes
[23:50] <c_korn> sistpoty: this evil hack would solve all of those conversions then, wouldn'it ?
[23:52] <sistpoty> c_korn: not necessarily. For one thing, I'm not sure if it does indeed wor
[23:52] <sistpoty> +k
[23:52]  * c_korn doubts it.
[23:52] <sistpoty> c_korn: apart from that, if tk_entry_get_text does indeed return a const pointer which resides in a read-only page, you'd get a segfault at runtime
[23:52]  * c_korn tries to build it.
[23:53] <c_korn> sistpoty: yes, but then it would have segfaulted before,too.
[23:53] <sistpoty> c_korn: i.e. if you try const char *s = "hello"; char *t = (char *)s; *t=NULL; I guess that it would segfault
[23:53] <sistpoty> c_korn: that's right
[23:54] <sistpoty> c_korn: another soltion would be to strcpy the result from gtk_entry_get_text... that's for sure non-const then
[23:54] <sistpoty> (but you'd have to free it afterwards again)
[23:55] <sistpoty> oh, wrong in my example... *t = 0; of course
[23:56] <c_korn> sistpoty: to free it is just ... delete tmp2 ... (tmp2 being the strcpy'd non-const value ?
[23:56] <sistpoty> c_korn: free(tmp2)
[23:56] <sistpoty> c_korn: anything c-related uses malloc, the pendant is free
[23:57] <sistpoty> c_korn: anything allocated with c++ is "new", that would be deleted
[23:57] <sistpoty> (don't mix these two)
[23:58] <c_korn> sistpoty: ok, I just thought because in line 10 of my pastebin is: delete[] ns;