[00:00] <sistpoty> c_korn: well, whatever the result from sum_strings is must be allocated with "new" then ;)
[00:29] <mezgani> Zhenech, yep
[00:29] <mezgani> i was watching a movie, are you there
[00:41] <c_korn> sistpoty: omg, your hack worked actually. casts are the root of all evil :)
[00:42] <sistpoty> c_korn: hehe
[00:43] <sistpoty> c_korn: but only apply such a patch, if you're really sure that there's no string constant ever returned... otherwise it'll haunt you at run time ;)
[00:45] <c_korn> sistpoty: well, I have no idea what gtk_entry_get_text returns actually. but as long as it worked before this hack does not hurt.
[00:46] <sistpoty> c_korn: no idea myself about gtk internals... I could only guess that it eventually returns the actual passed pointer to get_entry_set_text (or whatever this function might be called)
[00:47] <sistpoty> c_korn: and that it eventually doesn't rely internally on the string not being changed :) otherwise that calls for trouble *g*
[00:51] <c_korn> sistpoty: hm, sure. I first try to constify the char* if appropriate. else your hack is the easiest solution. does not break anything which was broken anyhow before.
[00:52] <sistpoty> heh... maybe I should state that my hack is really a hack is a hack is a hack. Don't use it evar, unless you know what you're doing :P
[00:53] <c_korn> sistpoty: I will make a runtime test once I fixed/hacked ALL of them: http://pastebin.com/d354469a8 grrr
[00:55] <sistpoty> c_korn: excellent, and please subscribe to bugs (and especially watch out for crashes due to it being really a crude hack
[00:55] <sistpoty> +)
[01:19] <c_korn> hm, (nt:28303): Gtk-WARNING **: cannot open display: :0.0
[01:22] <c_korn> fails only in the schroot actually.
[01:23] <sistpoty> c_korn: bind-mounted /tmp?
[01:23] <sistpoty> (iirc the X socket is there)
[01:23] <c_korn> sistpoty: yes, it is mounted.
[01:24] <sistpoty> hm... maybe I'm not up to date about the X socket then *g*
[01:24] <sistpoty> or DISPLAY is unset?
[01:25] <sistpoty> (which wouldn't cause :0.0 then, I guess)
[01:28] <c_korn> sistpoty: yes, DISPLAY is set.
[01:28] <sistpoty> *shrug*
[01:28] <c_korn> actually d4x runs fine outside the schroot in my "real" (virtualbox) karmic
[01:28] <c_korn> so it is ready for upload
[01:29] <sistpoty> c_korn: then upload it? (or do you need a sponsor?)
[01:31] <c_korn> sistpoty: I think I need a sponsor (I am not even a motu acutally)
[01:32] <sistpoty> c_korn: I always thought you were... ;)... link to debdiff?
[01:34] <c_korn> sistpoty: sorry for disappointing you :) http://pastebin.com/f3bef079c
[01:37] <sistpoty> c_korn: looks good at first glimpse :)... just as a hint, you could mention the files you touched explicitely in debian/changelog, that helps looking these up in the future
[01:37] <c_korn> sistpoty: should I do so now ?
[01:38] <sistpoty> c_korn: it's ok for now
[01:39] <c_korn> if you like: http://pastebin.com/fc17c143
[01:39] <sistpoty> c_korn: you'll find out once you're doing merges that you once did :P (at least that's where I learnt to write good changelog entries)
[01:39] <c_korn> oops...
[01:40] <sistpoty> (and my initial changelog entries where somewhat cracky... I couldn't figure out what I did half a year ago)
[01:41] <c_korn> there you go: http://pastebin.com/f1aebd02f
[01:41] <c_korn> sistpoty: :)
[01:45] <c_korn> I need a FFE a assume
[01:48] <sistpoty> c_korn: hm?
[01:48] <sistpoty> c_korn: bug fixes don't need a FFe
[01:48] <c_korn> oh, ok.
[01:49] <sistpoty> c_korn: unless after final freeze... but even then you'd hit the right person :P
[01:52] <sistpoty> c_korn: tried to forward the patch yet?
[01:53] <c_korn> I opened a bug in lp: https://bugs.launchpad.net/ubuntu/+source/d4x/+bug/428207
[01:53] <ubottu> Launchpad bug 428207 in d4x "[Update package] 2.5.7.1-6ubuntu1" [Undecided,New]
[01:54] <c_korn> I will forward the patch to debian with submittodebian now.
[01:55] <sistpoty> c_korn: oh, you should have closed the bug with a LP: #428207 stanza in debian/changelog
[01:55] <sistpoty> c_korn: otherwise you'll have to close the bug yourselves in a few seconds ;)
[01:55] <c_korn> sistpoty: I have this stanza in the debdiff which is attached to the bug.
[01:56] <sistpoty> c_korn: but not in the debdiff you pasted me :/
[01:56] <sistpoty> (which I just uploaded btw.)
[01:56] <c_korn> sistpoty: I did not know the number at that time. sorry. will do it then manually.
[01:57] <sistpoty> c_korn: well, no problem, thanks for your contribution!
[01:57] <sistpoty> c_korn: anyways, I'd suggest to forward it to debian as wishlist bug (it's maintained by debian-qa so it should get in over time)
[01:58] <sistpoty> c_korn: even better would be if you could check if there's still an upstream caring, and forward the patch there (to relieve debian-qa of the need)
[02:00] <c_korn> hm, latest upstream changelog entry is from 2005-09-16 11:09
[02:00] <sistpoty> yeah, I failed to find a valid link to an upstream page in the first place (but I didn't look really close though)
[02:00] <c_korn> http://en.wikipedia.org/wiki/Downloader_for_X (website is down)
[02:06] <c_korn> hm, I wanted to send the patch to debian but I have no mail sending program (except of thunderbird) configured.
[02:11] <c_korn> yay, http://launchpadlibrarian.net/31692700/buildlog_ubuntu-karmic-amd64.d4x_2.5.7.1-6ubuntu1_FULLYBUILT.txt.gz
[02:11] <c_korn> only thousand of warnings
[02:11] <sistpoty> c_korn: you can use reportbug -B debian <package>
[02:11] <c_korn> but no error :P
[02:12] <sistpoty> c_korn: and then if it asks if you want to submit the bug report, type "?"
[02:12] <sistpoty> (there should be an option to write the message to stdout, which you can adjust in tb then)
[02:13] <sistpoty> c_korn: congrats :)
[02:15]  * sistpoty must go to bed now
[02:15] <sistpoty> gn8 everyone
[02:16] <c_korn> sistpoty: good night and thanks
[02:27] <c_korn> does anyone know how I can tell reportbug/submittodebian to use thunderbird ?
[02:53] <mruiz> hi all
[02:54] <mruiz> I'm working on a new patch for a package, and I got "unknown patch system" with what-patch ... Suggestions?
[02:54] <Flannel> mruiz: Try #ubuntu-motu
[02:54] <LaserJock> heh
[02:54] <Flannel> Oh
[02:54] <mruiz> lol
[02:55] <LaserJock> mruiz: it might not have a patch system?
[02:55] <Flannel> sorry, 11 is right under 2 in irssi
[02:55] <mruiz> Flannel, np
[02:55]  * Flannel was wondering why it got so quiet.
[02:56] <mruiz> LaserJock, there are many patches under debian/patches . Some of them are .diff and .patch
[02:56] <jmarsden> mruiz: Read the debian/rules file to check whether it already uses a patch system (how do those patches get applied?)
[02:56] <LaserJock> mruiz: so look in debian/control
[02:57] <mruiz> jmarsden, thanks
=== keylocker is now known as leleobhz
=== zooko is now known as zookox
[03:41] <mruiz> I'm getting an error during the building (pbuilder) process of a package: pbuilder-satisfydepends-dummy: Depends: mesa-swx11-source (> 6.4.1) which is a virtual package.
[03:44] <zooko> Folks: are there any Ubuntu platforms where sizeof(int) != sizeof(size_t) ?
[03:45] <zooko> Because I just got a package I wrote accepted into Ubuntu in order to go into Karmic, and now we've discovered a bug in it when that inequality holds.
=== keylocker is now known as leleobhz
[03:55] <mpontillo> zooko: on x86_64 I believe sizeof(size_t)=8 and sizeof(int)=4, so I would think yes, but I don't have a 64-bit Ubuntu system handy to verify
[04:26] <zooko> I do.
[04:26] <zooko> Thanks.
[05:52] <mruiz> hi all
[06:27] <LucidFox> Do I need to file a freeze exception to request a package to be removed?
[06:28] <Hobbsee> LucidFox: don't think so
[06:28] <Hobbsee> it's not like it's introducing anything new.  but do do regression tests as appropriate and list them in the bug, if you can
[06:31] <ScottK> LucidFox: No.
[07:53] <AnAnt> Hello, I'm working on a package that installs its system-wide config file in /usr/share/covered/.covered (ie. a hidden file in /usr/share/covered) , so I suggested to upstream to rather install it as /etc/covered, so his response was that he doesn't think that application specific configuration files should be located in /etc , any comments ?
[07:53] <AnAnt> isn't there some FHS standard regarding this ?
[08:16] <jmarsden> AnAnt: http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE6
[08:18] <quentusrex> If I'm building a package for multiple releases, should I put the highest release I support, or the lowest?
[08:18] <jmarsden> AnAnt: Note also in the section about /usr/share that data there must not need modification... so config files are not allowed in there if the user is expected to edit them :)
[08:20] <quentusrex> jmarsden: do you have any idea about the release tagging for a package? if I want a package to be installable on both Intrepid and Jaunty, in the changelog do I say intrepid, or jaunty?
[08:20] <jmarsden> quentusrex: The one you want that package to actually build on is what you put in the first line of debian/changelog ...
[08:21] <quentusrex> so I need to release a separate package for each release?
[08:21] <jmarsden> The changelog doesn't affect installability, just what it gets built on by the buildds ... I don't think you can automate "build this exact same source package on N different releases
[08:22] <quentusrex> and the manual way is to specify which release it gets built on...
[08:22] <quentusrex> ok
[08:22] <quentusrex> thanks.
[08:22] <jmarsden> Bear in mind I am not a MOTU... but that's my understanding of how it works.
[08:23] <quentusrex> that's fine.
[08:23] <quentusrex> I'm rather new to packaging...
[08:23] <quentusrex> as long as I get an opinion that will probably work, I'm happy enough
[08:23] <quentusrex> I'll refine my process later...
[08:23] <jmarsden> OK.  That works for me, I build some packages for Hardy/Intrepid/Jaunty/karmic in a team PPA...
[08:26] <quentusrex> and you release an incremented package for each release?
[08:26] <jmarsden> Yes. I end up naming them whatever-x.y-1~hardy1 and then ~inrepid1 and so forth.
[08:28] <jmarsden> Look at the bibletime packages in https://launchpad.net/~pkgcrosswire/+archive/ppa if you want an example :)
[08:41] <quentusrex> jmarsden: lucky you...
[08:41] <quentusrex> my builds are 170MB+
[08:41] <quentusrex> since I have tons of sound files for the telephony package...
[08:42] <jmarsden> All ending up in a separate -data binary package, I would hope :)  But yes, that would make uploading the source package multiple times not much fun.
[08:43] <quentusrex> yeah....
[08:44] <jmarsden> quentusrex: You may be able to do debuild -S and just upload those, so the orig.gz does not get uploaded N times... might be worth some experimenting with.
[08:45] <quentusrex> do you know if it's possible to do a dpkg-buildpackage, and only say one of the packages to build?
[08:45] <quentusrex> jmarsden: that is what I do...
[08:46] <quentusrex> hmm
[08:46] <quentusrex> actually it seems I don't have an orig
[08:46] <jmarsden> quentusrex: You mean ask dpkg-build-ackage to only build one *binary* package when the source package normally would build multiple binary packages?  I don't think so, man dpkg-buildpackage might find you some option for that.
[08:46] <quentusrex> what's the quick command to build an orig?
[08:47] <jmarsden> quentusrex: You don't?  Are you building a native package??
[08:48] <jmarsden> If you have foo-1.2.3.tar.gz then you can do  ln -s foo-1.2.3.tar.gz foo_1.2.3.orig.tar.gz      if that is what you mean?
[08:52] <quentusrex> now, in packaging terms, how long does an orig last?
[08:53] <quentusrex> if I'm building package: foo_1.0.4.15968-1ubuntu1.....
[08:53] <quentusrex> I'm using the 4th number as the svn revision, and the first 3 numbers as the most recent tagged release...
[08:54] <quentusrex> is there a better way to number it so that the tagged releases get a new orig, but the svn version can get updated?
[08:55] <zakame> hi hi
[08:56] <jmarsden> quentusrex: Until the upstream project releases a new version.
[08:57] <jmarsden> if you are new to packaging, it is far easier to stick to packaging released software, IMO.  Deal with creating tarballs from svn later once you have packaging itself well understood and working.
[08:58] <jmarsden> quentusrex: Bit wait... if it us -1ubuntu1 you already have Debian/Ubuntu packages for an older version to use as a basis for your work.
[08:59] <jmarsden> s/Bit/But/ :)
[09:01] <quentusrex> jmarsden: I'm part of a project and I'm the only one to deals with ubuntu
[09:01] <quentusrex> I want a package for myself, and it'd be easiest if I learn to package, and get others using it on ubuntu
[09:02] <jmarsden> Then you can persuade your colleagues to release at nice appropriate intervals, and release those as Ubuntu packages.
[09:03] <jmarsden> Do those creating packages for Fedora, or SuSe or FreeBSd just package from svn too?
[09:04] <quentusrex> they have two different sets of packages,
[09:04] <quentusrex> release packages, and nightlies...
[09:04] <quentusrex> I'm learning on the nightlies to build the releases properly..
[09:06] <jmarsden> First use a real, released tarball that you know has been tested and works.  Just my sugggestion :)
[09:08] <quentusrex> jmarsden: for most projects that is correct, but this one never has svn in unbuildable state...
[09:08] <quentusrex> anyone who breaks a build loses commit rights for a couple weeks
[09:09] <jmarsden> It's your choice.     But ... -1ubuntu1 means there is already a Debian foo-x.y-1 package, so why are you not using that?
[09:09] <quentusrex> so those with commit rights are cautious about committing... I'm not saying there aren't bugs, but they don't break stuff.
[09:09] <quentusrex> because there isn't one...
[09:09] <quentusrex> most packages seem to use that naming, so I used it.
[09:09] <jmarsden> Then you did not read the Packaging Guide carefully enough!
[09:09] <geser> for most package exists a version -1 in Debian
[09:10] <quentusrex> :)
[09:10] <jmarsden> https://wiki.ubuntu.com/PackagingGuide/Complete#changelog   says "If a package for the application does not exist in Debian, then the Debian revision is 0 (e.g., 2.4-0ubuntu1)."
=== yofel_ is now known as yofel
[09:17] <quentusrex> aah, I'll fix that..
[09:17] <quentusrex> now, is there a good way to do: foo-1.0.4-15432-0ubuntu1.....
[09:17] <quentusrex> or will that not work?
[09:18] <binarymutant> is this for a ppa?
[09:20] <quentusrex> yes
[09:20] <quentusrex> it's for the development testing builds, aka nightlies...
[09:21] <quentusrex> where the svn revision should over ride the 0ubuntu5 part...
[09:21] <jmarsden> quentusrex: Don't use the - before the svn number, use a . instead.  - has a specific meaning .
[09:22] <binarymutant> quentusrex, ah thank you, I was just asking for my own future information on how ppa naming works (or doesn't work)
[09:22] <quentusrex> there seem to be a bunch of us that are new and trying to figure it out.. :)
[09:24] <binarymutant> I thought it didn't matter what you named it :/
[09:24] <binarymutant> err versioned it*
[09:24] <jmarsden> You will probably end up with foo-1.0.4.20090912-1~ppa~jaunty1 or similar.
[09:25] <jmarsden> binarymutant: Please do read https://wiki.ubuntu.com/PackagingGuide/Complete#changelog  (and in fact, read the whole Guide, for good info on packaging!)
[09:28] <binarymutant> jmarsden, ah does this also apply to ppa's ? for instance I was thinking about hosting some debs from another distro :/
[09:29] <jmarsden> PPAs are for Ubuntu, only, at the moment.  There have been requests to allow Debian packages there too, and DEbian buildds, but AFAIK that is not yet available or even promised.
[09:29] <quentusrex> will a foo-1.0.4~15234..... still be able to use foo-1.0.4.orig.tar.gz?
[09:29] <binarymutant> jmarsden, ah, ty for that info :D
[09:31] <quentusrex> what's the proper way to do orig directories and files?
[09:31] <jmarsden> quentusrex: Well... the version of the .orig (not the package version, the upstream version) needs to match.  That second - separates the upstream version part from the package version part.
[09:31] <jmarsden> softwarename-upstreamversion-packageversion~ppa~whatever
[09:32] <jmarsden> I repeat: by trying to work from svn you are adding unnecessary complexity to this... build a stable release and get a lintian clean package of it, *then* go after the svn code if you have to.
[09:33] <quentusrex> I hear you jmarsden, but the only point to packaging it is for the nightlies...
[09:33] <quentusrex> they have the release upgrade fully automated...
[09:34] <quentusrex> just not the nightlies...
[09:34] <jmarsden> No, the point is so you learn how to package, first!
[09:36] <randomaction> quentusrex: do you use svn-buildpackage? it's a tool that looks suited to your situation
[09:41] <diwic> What status should a bug have when it is waiting for a universe sponsor?
[09:42]  * hyperair usually puts either confirmed or in progress
[09:42] <randomaction> diwic: see https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue
[09:43] <diwic> randomaction: so it can be "confirmed" although I shouldn't confirm my own bugs?
[09:44] <randomaction> it should be "confirmed" if you have uploaded a debdiff for review
[09:44] <diwic> Okay. Should I manually remove config.sub & config.guess changes?
[09:49] <diwic> Well, I'll keep them then.
[09:50] <diwic> one FTBFS bug fixed \o/
[09:52] <randomaction> one out of hundreds...
[10:07] <diwic> randomaction: Or you could be optimistic and think of all the thousands of packages that actually build :-)
[10:07] <randomaction> :)
[10:20] <tilgovi> Newbie packaging question: if a `make install` creates directories that do not match the preferred layout of ubuntu packages (of this type), should I modify the Makefile or is there a file in the ./debian directory that can remap these locations?
[10:21] <jmarsden> debian/install
[10:21] <jmarsden> tilgovi: man dh_install
[10:21] <tilgovi> jmarsden: thanks :) I knew it had to be easy.
[10:32] <azeem> tilgovi: however, it is recommended to fix the upstream Makefile as well if possible
[10:33] <tilgovi> azeem: what if it's not debian...I mean to say...what standard layout should I attempt to impose?
[10:37] <tilgovi> azeem: that's a silly question...I can sort that out.
[10:37] <tilgovi> sorry.
[10:44] <azeem> tilgovi: the FHS
=== ripps_ is now known as ripps
[10:57] <tilgovi> azeem: Ahh...I see. Great. Thanks a bunch.
[10:57] <tilgovi> now to start filling my ppa
[11:28] <Hosein-mec> hi
[11:28] <Hosein-mec> launchpad Accepted my package. and i received some email
[11:28] <Hosein-mec> [Build #1240247] i386 build of smooth-tasks 20090910-1 in ubuntu jaunty RELEASE (hoseinhz63 PPA)
[11:28] <Hosein-mec> ...
[11:28] <Hosein-mec> but there is no package yet
[11:28] <Hosein-mec> https://launchpad.net/~hoseinhz63/+archive/ppa
[11:29] <Hosein-mec> anyone told me about build-dependencies for package
[11:30] <Hosein-mec> how do that ?
[11:31] <geser> check why the build of your package failed and fix it
[11:31] <geser> have you read the packaging guide?
[11:32] <geser> !packaging guide
[11:32] <ubottu> The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports
[11:39] <jcfp> Anybody know which python versions will be available in karmic?
[11:48] <DktrKranz> likely 2.5, 2.6 and 3.1
[11:52] <jcfp> DktrKranz: thanks
[12:24] <Hosein-mec> launchpad cant build
[12:24] <Hosein-mec> https://launchpad.net/~hoseinhz63/+archive/ppa/+build/1240247/+files/buildlog_ubuntu-jaunty-i386.smooth-tasks_20090910-1_FAILEDTOBUILD.txt.gz
[12:24] <Hosein-mec> anyone can help ?
[12:26] <Lutin> Hosein-mec: looks like the pacage is missing a build-dependency on cmake
[12:28] <Hosein-mec> Lutin: i need set it in debian/control file ? if yes how to find dependency need to build ?
[12:29] <Lutin> yes, you need to set it in debian/control − like all build-dependencies
[12:31] <Hosein-mec> Lutin: this line ? Build-Depends: debhelper (>= 7)
[12:31] <Lutin> yes
[12:31] <Hosein-mec> how find other dependensy needed for source ?
[12:31] <Lutin> you should probably read the debian new maintainer's guide, I guess
[12:32] <Hosein-mec> i read it but i dont understand this section
[12:47] <Lutin> Hosein-mec: I guess you can find at least the required libs by looking at CMakeFiles/*.dir/depend.internel , but I'm no cmake expert so there might be a better way
[12:49] <Lutin> (ah, there is. CMakeFiles/CMakeDirectoryInformation.cmake, at least)
[12:50] <Hosein-mec> Lutin: thanks
=== IVBela1 is now known as IVBela
=== asac_ is now known as asac
=== xnox`` is now known as xnox
[15:16] <AnAnt> !logs
[15:16] <ubottu> Official channel logs can be found at http://irclogs.ubuntu.com/ - For LoCo channels, http://logs.ubuntu-eu.org/freenode/
[15:20] <AnAnt> jmarsden: thanks
[17:45] <toobaz1> Hello. Denemo is a package full of bugs, with a version which upstream explicitly suggests to avoid. The last version, repackaged from scratch, just touched debian unstable. To work under karmic (and jaunty too, for that matter), the dependencies should be tweaked (only minimal versions, which are too exigent), and I can provide the patch for that. Do you think it is worth the effort or is it just too late?
[17:50] <ScottK> toobaz1: It's worth looking into.  I'd say (from what you've described) yes.
[17:50] <toobaz1> so I just ask a sync attaching the debdiff?
[18:01] <ScottK> And subscribe motu-release since it'll need a Feature Freeze exception at this point.
[18:01] <ScottK> !FFe
[18:01] <ubottu> uvf is Upstream Version Freeze.  For an exception, see https://wiki.ubuntu.com/FreezeExceptionProcess
[18:01] <ScottK> toobaz1: See the extra information asked for ^^
=== xnox`` is now known as xnox
[18:02] <lamalex> Can I apt-get source a package from a different release?
[18:02] <lamalex> for instance I'm on karmic and want to get the source package from jaunty for someting
[18:02] <lamalex> possible?
[18:02] <lamalex> I tried apt-get source gnome-power-manager/jaunty but that's not it
[18:02] <xnox> well you need deb-src lines for jaunty in your sources =)
[18:03] <lamalex> ah :)
[18:03] <lamalex> will that work then? was my syntax correct?
[18:03] <xnox> and I think there was a script in devscripts or ubuntu-devtools which would pull sources from launchpad which is more uptodate then any mirror
[18:04] <xnox> not sure about syntax but something like that should work =) check the manpage or just trial and error ;-)
[18:04]  * xnox is a beginner in ubuntu packaging
[18:05] <ScottK> pull-lp-source is, I think the script you meant
[18:06] <xnox> ScottK: thanks ;-)
[18:08] <RainCT> lamalex: once you have the deb-src line, apt-get source <package>=<version>
[18:08] <lamalex> RainCT: yah, i just rtfm'd
[18:09] <RainCT> lamalex: but if you write a patch for apt-get to accept a -t argument when doing 'apt-get source' you'd rock :P
[18:10] <lamalex> that would be convenient
[18:10] <lamalex> i'll put it on my 'todo'
[18:11] <RainCT> cool (unless your "todo" is like mine, ie. saying "I'll do it some day" and forget about it :D)
[18:11] <RainCT> somehow my English sucks today xD
[18:12] <lamalex> RainCT: yes, mine is like that
[18:13] <lamalex> it's about 10k items longs..
[18:13] <lamalex> many of which are quite large and actually need done
[18:14] <RainCT> btw, someone knows how to fix this? http://paste.ubuntu.com/269890/  (I get that trying to use cowbuilder-dist on Squeeze)
[19:10] <ScottK> Just submitted the "It's time for the gtk1.2 rdpends to die" bug.
=== ksymoops is now known as _09226082168
=== _09226082168 is now known as dous
=== lukjad007 is now known as lukjadOO7
=== lukjadOO7 is now known as lukjad007
[20:20] <ScottK> geser (or any other C proficient person) could I have a hand with http://revu.ubuntuwire.com/p/searchandrescue
[20:23] <jmarsden> ScottK: The function strcasestr is apparently being declared twice, slightly differently... which is not good.  Either declare it once, or make sure the two declarations are 100% identical?
[20:23] <ScottK> jmarsden: I'm not a C programmer, so I need "give me a patch" kind of help.
[20:23] <ScottK> Missing headers I can do (already fixed on in that package), this stuff, not me.
[20:24] <jmarsden> Ah... I'm not up for that right now, about to go out for lunch...
[20:26] <ScottK> Thanks anyway
[20:26] <ScottK> Odds are I'll be here when you get back.
[20:38] <geser> ScottK: you need someone with more C++ knowledge than me. This looks like the package implements some of the same C functions itself (in a C++ context)
[20:39] <ScottK> Yuck.
[20:39]  * ScottK looks around some more.
[20:39] <geser> I'd probably check if the description of the mentioned function in string.cpp matches the manpage and use the one from libc6 (i.e. comment the declaration and definition out)
[20:41] <geser> I'm currently not on my Ubuntu so can't check myself right now
[20:41] <geser> but will do it later
[20:41] <ScottK> Thanks.
[20:41] <geser> you can also ask sistpoty when he comes around
[20:43] <ScottK> I will.
[20:44] <sebner> geser: would you mind taking a look if this is correct: http://paste.ubuntu.com/269955/  <-- at least it builds for me now
[20:46] <geser> sebner: for this kind of error, this the correct fix (g++ would complain if some later code tried to write to the const pointer)
[20:47] <sebner> geser: thx :) seems to be qualified for an inline patch to me, no patchsystem :P
[20:54]  * RoAkSoAx should have swapped courses earlier. Lots to read and so little time to finish the homework :(
[20:55] <sebner> RoAkSoAx: school already started for you?
[20:56] <RoAkSoAx> sebner, yeah like 3 weeks ago, but I just swapped a course two days ago... and I already have like 7 chapters to read and a huge homework
[20:57] <sebner> geser: would you mind also taking a look at http://paste.ubuntu.com/269961/ ?
[20:57] <sebner> RoAkSoAx: what kind of school is that?
[20:58] <RoAkSoAx> sebner, Grad School (Masters Degree)
[21:00] <sebner> RoAkSoAx: heh, I wish you good luck then
[21:00] <RoAkSoAx> sebner, thanks :)
[21:02] <sebner> RoAkSoAx: and congrats to MOTUship btw :D
[21:03] <RoAkSoAx> sebner, thank you :) xD
=== boshhead_ is now known as boshhead
[21:10] <geser> sebner: can you paste the function?
[21:11] <geser> sebner: and I guess kees would be happy if you also fixed the warning about the missing format string
[21:11] <sebner> geser: me might be you because my C knowledge = 0 :P
[21:13] <sebner> geser: http://paste.ubuntu.com/269971/
[21:17] <kees> those two just need to be  LOG_WARN("%s", err.c_str());
[21:18] <sebner> kees: I'm wondering what's the difference. I know this form other languages. %s shows err.c_str() so what speaks against lonely err.c_str()?
[21:19] <kees> sebner: because if err.c_str() itself contains format characters, they will be processed.
[21:19] <kees> i.e.  the first function takes a filename.  what if the filename is %x%x%n%n.blah ?
[21:20] <sebner> urgh
[21:20] <sebner> I understand
[21:20] <kees> cool :)  yeah, it's a subtle gotcha
[21:21] <sebner> kees: see that works. mighty guys you can propose solutions and worker bees (like me) uploading the fixes :D
[21:21] <kees> heh, well, I upload fixes too, but it sure helps if everyone is watching out for it.  :)
[21:22] <geser> sebner: I need to look later at it as I need to know what Qcall, Qlname, Q... and recbuffer is
[21:23] <sebner> geser: sure, go on. kees already told the solution to fix the warnings :)
=== roaksoax_ is now known as RoAk
[21:58] <sebner> geser: any progress? Btw, how can we improve the FTBFS fixing? The rebuild page is nice but can't be updated what's already fixed so it's pretty annoying (I suppose everybody checks if something has been done already though)
[22:00] <geser> sebner: I'm currently gaming (under Windows)
[22:00] <sebner> geser: heh, np :)
[22:00] <geser> sebner: wgrant knows about this wish for the the rebuild page and plans to work on it once he has some free time
[22:01] <sebner> cool, thx for the information :D
[22:01] <geser> sebner: as uploads to the main archive don't propagate to the rebuild archive, the script needs to check if there is a new upload to the main archive
[22:02] <geser> if you know python you can grab the code for the FTBFS page from my LP account
[22:02] <geser> (the rebuild page uses only a slight modified version of it)
[22:04] <sebner> geser: I'm more on the java/C# side :P (I hate java though)
[22:05] <binarymutant> how long should I wait to upload to revu after karmic+ ? It's a new version from upstream. I was thinking ~a month (?)
[22:09] <sebner> binarymutant: you can upload any time but won't get sponsoring until the archiv for karmic +1 is open
[22:15] <binarymutant> ty
[22:18] <RainCT> mok0: So you're a Wave fan too? :)
[22:30] <sebner> geser: fixing const char FTBFS is somehow funny, at least when they are easy to fix what's mostly the case