=== fta_ is now known as fta
=== RAOF__ is now known as RAOF
[01:11] <james_w> hi serialorder
[01:36] <ryanakca> Could one make a package such that for foobar-a , patch_1.diff is applied, but for foobar-b, patch_1.diff isn't?
[01:38] <serialorder> hi james
[01:39] <james_w> ryanakca: foobar-a and foobar-b are binary packages?
[01:41] <ryanakca> james_w: *nod*
[01:41] <RAOF> It'll need some makefile trickery, and you'll obviously need to build the source twice, but it's possible.
[01:42] <ryanakca> RAOF: thanks
[01:43] <RAOF> The last thing I touched that did something similar was making libasound2-plugins build 32 & 64
[01:43] <RAOF> bit binary packages on the appropriate archs.  That's not a good example, though, because there's all sorts of madness that's specific to biarch builds.
[01:44] <ryanakca> RAOF: Thanks :)
=== jtechidna is now known as JontheEchidna
=== nellery_ is now known as nellery
[06:30] <Laibsch> good morning
[06:31] <Laibsch> I am trying to get http://mentors.debian.net/debian/pool/main/g/gourmet/gourmet_0.14.2-1.dsc into shape for inclusion.  I think it is almost there, except for one thing; "E: gourmet: file-directly-in-usr-share usr/share/gourmet-0.14.2.egg-info"
[06:31] <Laibsch> http://wiki.debian.org/DebianPythonFAQ suggested to pass the option "--single-version-externally-managed" to the "setup.py install" call, but that did not work out "error: option --single-version-externally-managed not recognized"
[06:31] <Laibsch> Any suggestions?
[06:32] <Laibsch> james_w: Sorry for the late response.  Did you have a chance to push those wordpress changes.  If it helps, I can still prepare an intrepid debdiff.
[06:34] <dholbach> good morning
[06:36] <Hobbsee> morning horsemen
[06:36] <dholbach> hi Hobbsee
[07:09] <awmcclain> Anyone know of a way to cache your GnuPG passphrase without using Seahorse?
[07:10] <Hobbsee> pinentry-gtk2?
[07:10] <siretart> gnupg-agent?
[07:12] <awmcclain> Thank you!
[07:21] <awmcclain> Is there any way to give (pre-cache)  my passphrase to gpg-agent before it's actually asked?
[07:27] <Hobbsee> is there any good reason to do so?
[07:29] <awmcclain> Hobbsee: I'm using autoppa to upload the ~30 packages I maintain, and it dies if you need to enter a passphrase. :(
[07:30] <Hobbsee> awmcclain: well, you can't put it in a textfile, and get it to read that.
[07:30] <Hobbsee> therefore, you're going to have to physically type it in once anyway.
[07:31] <awmcclain> Hobbsee: That's fine. I just want to be able to have gpg-agent cache it _before_ I run autoppa.
[07:31] <Hobbsee> consequently, the suggestion would be that you debsign a .dsc file manually (or something similar), then run autoppa afterwards, when it should still be cached.
[07:32] <awmcclain> Hobbsee: Perfect. I need to brush up on the individual deb helpers. I couldn't remember which would prompt me for a signature.
[07:32] <Hobbsee> awmcclain: ah, cool.
[07:32] <awmcclain> Just want to prime the pump.
[07:38] <awmcclain> Well, crap. debuild --no-tgz-check -S is still prompting for a passphrase.
[08:00] <jmarsden> awmcclain: debuild -S -uc -us
[08:02] <awmcclain> jmarsden: But that doesn't launch debsign?
[08:02] <jmarsden> Right, I thought you didn't want to sign the package?
[08:02] <Hobbsee> jdong: ping?
[08:03] <awmcclain> jmarsden: No, I'm trying to sign it, but using the cached key in gpg-agent. I think the problem is that debsign isn't configured to use gpg-agent.
=== dholbach_ is now known as dholbach
[08:03] <awmcclain> (Really, I'm trying to get autoppa not to break)
[08:04] <jmarsden> Are signed packages required for PPA upload?  if not, then not signing them should avoid all passphrases and thereby achieve your goal.\
[08:05] <awmcclain> jmarsden: They are, unfortunately. :-|
[08:06] <Hobbsee> jmarsden: they are, for very good reasons.
[08:07] <jmarsden> OK.  I've always signed mine, but I've never had a need to automate PPA upload either, I'm not that prolific.
[08:08] <awmcclain> Hobbsee: Very good, yes. Unfortunately for me, I should say.
=== dmb is now known as Guest88424
[08:08] <Hobbsee> awmcclain: well, i'm sure someone can upload a whole bunch of packages, doing various things, under your name, instead, if you really wish :P
[08:09] <awmcclain> Hobbsee: No thanks! I'd rather just get my gpg caching working. :D
[08:09] <Hobbsee> haha ;)
[08:09]  * Hobbsee wonders where all the crackporters are.
[08:10] <Hobbsee> really odd, to not even have *one* around
[08:16] <awmcclain> Hrm. Slowly making progress. The real issue is that I'm doing all this just on a console.
[08:22] <awmcclain> Is pinentry a GUI thing? Seems like it depends on QT or GTK.
[08:24] <Hobbsee> it used to have a console based one,iirc.
[08:32] <james_w> morning all
[08:32] <james_w> Laibsch: I haven't yet, sorry. I'll look at it this morning.
[08:32] <Laibsch> great, thanks
[08:32] <Laibsch> let me know if there is anything I can do to help
=== fta_ is now known as fta
[10:59] <james_w> slytherin: around?
[11:00] <james_w> slytherin: for lucene, does having that patch break anything?
[11:02] <slytherin> james_w: I wonder if that patch will apply at all. If it does, it will not break anything, simply bypass a unit test.
[11:02] <james_w> k
[11:06] <slytherin> james_w: I think it is better to wait till I file a bug. Just today lucene2 in Debian got updated to use libdb4.6-java as build and runtime dependency.
[11:07] <james_w> ok. I'll wait
=== echidnaman is now known as JontheEchidna
[13:32] <savvas> does anyone have a source of an debian package that uses svn-buildpackage ?
[13:34] <white> savvas: foo2zjs
[13:36] <white> savvas: svn.debian.org/svn/foo2zjs
[13:38] <savvas> thanks white :)
[13:45] <slytherin> savvas: I believe any packages that is team maintained in some svn (pkg-java, pkg-mono) can be build using svn-buildpackage.
[13:47] <savvas> slytherin: I'm actually reading about frostwire, since their code is in svn
[13:48] <savvas> some say there's a problem with some libraries, but I don't know what
[14:00] <lfaraone> How long does it take after I dput for somethign to get to REVU?
=== txwikinger2 is now known as txwikinger
[15:11] <james_w> Laibsch: hi, still around?
[15:11] <Laibsch> yes
[15:11] <Laibsch> any trouble?
[15:12] <ScottK> lfaraone: I think around 10 minutes.
[15:12] <james_w> Laibsch: sorry for the delay, I'm on it now
[15:13] <james_w> Laibsch: would you update the description of the bug as described in the SRU page?
[15:13] <james_w> !sru
[15:13] <ubottu> Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates
[15:19] <Laibsch> james_w: Are you referring to "Procedure - section 2.1 to 2.5"?
[15:19] <Laibsch> I think all the points there were covered in the bug, although there is not one nice, single paragraph to point to
[15:19] <Laibsch> I can add that if that is what you are looking for
[15:19] <james_w> yeah, please edit the description, it helps the SRU teams a lot
[15:22] <geser> Hi bddebian!
[15:23] <bddebian> Heya gang
[15:23] <bddebian> Hi geser
[15:23] <sebner> hi bddebian
[15:24] <sebner> geser: you also plan a multi vote like persia? ^^
[15:24] <bddebian> Hi sebner
[15:33] <Laibsch> james_w: take a look
[15:34] <Laibsch> I think it should be a good balance between verbose and concise
[15:34] <james_w> Laibsch: the dev branch thing means jaunty, not upstream
[15:34] <Laibsch> Oh, I see
[15:34] <james_w> I believe this was folded in to the merge for Jaunty, correct?
[15:35] <Laibsch> yes
[15:44] <james_w> Laibsch: diffs attached to the bug for your review
[15:46] <didrocks> james_w: (hi) I have a question about your last mail
[15:46] <james_w> hi didrocks
[15:47] <didrocks> james_w: does the "dpkg-statoverride call" has to be in the init script?
[15:47] <geser> sebner: first I need to read my collect mails from today
[15:47] <james_w> didrocks: that's kind of my question
[15:47] <sebner> geser: heh =)
[15:48] <didrocks> james_w: from what I understand (but I maybe wrong), it's just for replacing the "chmod 777", right?
[15:48] <didrocks> (and as the init script is launched as root, this is possible)
[15:48] <james_w> I'm not sure what you mean
[15:49] <didrocks> james_w: sorry, trying again : the best pratice is to used dpkg-statoverride in the init script, instead of using chmod/chown option to enable everyone to write in /var/run
[15:49] <Laibsch> james_w: Looks good, the date in the hardy patch is Nov 14th, but I guess that is rather irrelevant
[15:50] <Laibsch> thanks for the clean-up
[15:50] <savvas> Does anyone know a cdbs package that compiles using ant and ant.mk ? I'd like to see an example
[15:51] <james_w> didrocks: ah, no, dpkg-statoverride allows the admin to tell packages not to chown/chmod certain files/directories. The init scripts I have seen that chmod/chown do not respect this.
[15:51] <james_w> Laibsch: cool, thanks, I'll upload
[15:52] <didrocks> james_w: but in this case, I do not understand how, after a reboot, the right directory in /var/run is still writable for everyone
[15:53] <james_w> why should they be writeable to everyone?
[15:54] <didrocks> I was thinking you were talking about this case (when chown/chmod was needed in init script)
[15:54] <didrocks> but that was because I didn't understand the dpkg-statoverride use
[15:54] <didrocks> so, now, I think it's ok :)
[15:55] <didrocks> thanks a lot james_w. Will look closely at the discussion about this point :)
=== thekorn_ is now known as thekorn
[17:11] <iulian> Heya
[17:24] <james_w> directhex: hey, you about?
[17:25] <james_w> directhex: I've cot a bit of confusion with gmcs on ia64, and I would like you to tell me how it should look so I know what is broken
[17:31] <james_w> directhex: mono-gmcs doesn't seem to contain gmcs, but it's an Arch: all package.
[17:32] <sebner> james_w: afaik mono-gmcs contains gmcs1. gmcs2 is in mono-devel
[17:33] <james_w> I don't know how much to trust the Contents.gz, but they differ across arches
[17:33] <james_w> ia64 has gmcs2 in mono-gmcs and gmcs in mono-devel it seems
[17:34] <sebner> O_o
[17:34] <james_w> with gmcs in mono-gmcs and no mono-devel on i386
[17:34] <sebner> james_w: well, at least I had to install mono-devel so monodevelop alpha2 configure finds gmcs
[17:34] <sebner> on i386
[17:35] <james_w> this package may have built either side of mono2.0 being uploaded
=== mcasadevall is now known as NCommander
[17:58] <jdong> wow, network-manager sets up ad-hoc NATs.
[17:58] <jdong> I didn't know that.
[17:59] <slytherin> jdong: As per my observation, the only thing that NM doesn't manage is firewire point to point network.
[18:02] <jdong> never tried that before, so I can't say.
[18:02] <jdong> I did find it a bit counterintuitive that "Set up wireless network" defaults to setting up a NAT
[18:02] <jdong> although the functionality is nice, I would've liked it to be a bit more clear that's what it does.
[18:11] <Tetracomm> Hello.
[18:11] <Tetracomm> Does anyone know if checkinstall packages will ever become acceptable?
[18:12] <sebner> Tetracomm: never ever ;)
[18:13] <guille_> hi all
[18:13] <slytherin> Tetracomm: without changes? no.
[18:13] <guille_> does exist a mail list for packages?
[18:13] <slytherin> guille_: hi
[18:13] <slytherin> guille_: what kind of mailing list?
[18:14] <guille_> not sure what kind. actually i'm trying to build mysql with sphinxse (an storage engine) an package it; but no way to do it. i would like to ask people who knows
[18:16] <slytherin> guille_: Considering that mysql is in main, you will have better luck if you ask on #ubuntu-devel channel.
[18:17] <guille_> slytherin: ok, thank you
[18:29] <Tetracomm> Something needs to be done about the overcomplicated package creation process.
[18:30] <jdong> what is overcomplicated?
[18:30] <slytherin> Tetracomm: what is overcomplicated?
[18:30]  * lamont grumbles at jpds
[18:30] <Tetracomm> The package creation process.
[18:31] <Tetracomm> It is too difficult.
[18:31] <jdong> can you be more specific?
[18:31] <jdong> what part(s) did you find to be difficult?
[18:31] <broonie> You may want to use CDBS or similar if you're packaging something noddy enough.
[18:33] <lamont> jpds: if you wanna send me your nmap diff, it'll probably get uploaded and synced faster
[19:09] <slytherin> geser: any idea if java packages will ever need ${shlibs:Depends}, ${misc:Depends} ?
[19:20] <leslieviljoen> hey ppl! I was wondering: are packages "owned" by certain motu's? I reported a certain bug almost a year ago, including a patch. Today I mailed the Debian maintainer and he said he'd never seen it. Who's supposed to inform upstream?
[19:21] <azeem> the Debian maintainer is not necessarily upstream
[19:21] <slytherin> leslieviljoen: No. Packages are now owned by certain motu's. It has some advantages and at least one disadvantage that you mentioned.
[19:21] <azeem> well, depends on what you're talking about
[19:22] <leslieviljoen> in this case, the Debian maintainer was upstream
[19:23] <leslieviljoen> so is there a way of finding out if anyone is attending to something? do the devs handle bugs randomly?
[19:23] <geser> slytherin: I assume that dh_shlibdeps won't work for java packages, so ${shlib:Depends} is useless here, but one could perhaps use ${misc:Depends} for automagic dependencies on jars in other packages (if it's somehow possible to discover the dependencies)
[19:25] <geser> leslieviljoen: you might look at the "also notified" list but that is no guarantee that those people are really interested in the package
[19:25] <slytherin> geser: I guess jaranalyzer is supposed to determine dependencies. Never actually used it though.
[19:26] <leslieviljoen> so they are handled on a "I'm interested in that" basis?
[19:28] <leslieviljoen> So it comes down to this: I'm interested in fixing certain things, and I'm capable of doing it, I just don't know how to get my fixes into the repos. At least not in under a year.
[19:29] <leslieviljoen> What should I do?
[19:30] <lamont> leslieviljoen: patches sent to the bug report tend to get attention faster than bugs with no patches
[19:32] <leslieviljoen> Well look here: https://bugs.launchpad.net/wajig/+bug/174261
[19:32] <ubottu> Ubuntu bug 174261 in wajig "auto-install ignores noauth option" [Undecided,New]
[19:33] <leslieviljoen> It's a tiny problem but I fixed it almost a year ago. Upstream hasn't even heard of it yet.
[19:33] <leslieviljoen> (well they did today)
[19:34] <leslieviljoen> I made that fix to release a script that can find regressions in desktop packages: that script was a response to another bug I reported
[19:36] <leslieviljoen> so there seems to be a break-down in the link between launchpad and upstream - if there is any link
[19:56] <leslieviljoen> is there any reason not to report bugs directly upstream as opposed to launchpad?
[19:57] <geser> yes, as Ubuntu patches some packages/software a bug might be because of that patching so upstream can't really do anything about it
[19:58] <geser> and for the users it's easier to report bug reports at one place
[19:58] <geser> the downside is that we don't have enough manpower to distribute those bug reports to the different upstreams (after checking if it's really an upstream bug)
[20:01] <leslieviljoen> but I can easily check that
[20:01] <leslieviljoen> maybe I should become a motu
[20:01] <leslieviljoen> I just don't have consistent stretches of time
[20:02] <slytherin> leslieviljoen: that shouldn't stop you from trying
[20:02] <leslieviljoen> don't the motu's have set responsibilities?
[20:03] <leslieviljoen> ie. don't you need a certain minimum consistent amount of time to contribute?
[20:03] <directhex> if the patch is NOT in the packaging, then i'd STRONGLY recommend you file the bug upstream *yourself* and link the bug in launchpad
[20:03] <directhex> because chinese whispers are bad - you'd do a much better job of communicating the problem & answering questions than having a packager relay your issue without neccessarily fully understanding the issue
[20:05] <james_w> directhex: hey, did you see my question earlier?
=== santiago-pgsql is now known as Guest31387
[20:05] <james_w> directhex: it boiled down to which package is now supposed to ship /usr/bin/gmcs?
[20:06] <leslieviljoen> directhex: thanks for the advice. the problem is very rarely in the packaging though.
[20:06] <directhex> james_w, no, i didn't, sorry. things were exploding at work
[20:06] <james_w> directhex: no problem, it's not urgent
=== Guest31387 is now known as santiago-ve
[20:07] <directhex> james_w, we now ship 'generic' scripts in mono-devel - which means things like "sn" (as opposed to sh1 for .net 1, sn2 for .net 2), "al" (as opposed to... blah blah). and gmcs comes into that category
[20:08] <geser> leslieviljoen: MOTUs contributing in their free time, so its up to everyone how much time he's ready to spend (no commitments)
[20:08] <james_w> directhex: aha, so a package that wants to use gmcs should B-D on mono-devel, rather than mono-gmcs?
[20:08] <directhex> james_w, if you're asking due to a build dep, then the advice is to actually override the compiler you use to force 'csc', which is a debian-specific script pointing to the default c# compiler, which is gmcs for now (but might go back to being mcs in the future - upstream were talking about merging them)
[20:09] <directhex> james_w, http://wiki.debian.org/Teams/DebianMonoGroup/Mono20Transition#head-67c13a005dab7f510b0fd1ee8db7a30689e89669
[20:09] <james_w> directhex: nice, thanks. I'll work on that part and then consult you about anything else needed for the transition.
[20:09] <directhex> james_w, yes, please don't hesitate to ask
[20:11] <directhex> james_w, 2.0 passed debian NEW literally 150 minutes ago, so the transition is entering full swing there too. in experimental,mind
[20:12] <serialorder> i am working on a merge and the ubuntu version used automake 1.10.1 while the new debian version uses 1.10 this leads to a few extra things in the Makefile.in, which version should I keep?
[20:13] <directhex> (ubuntu is still newer though, 2.0.1-0ubuntu2 > 2.0-1. 2.0.1-0ubuntu2 is being referred to as 2.0.1-1~pre3 in private repo; ~pre4 exists but has a bugfix which does not affect buildds)
[20:14] <leslieviljoen> ok, will read up on how to motu, thanks chaps
[20:17] <directhex> leslieviljoen, if you're interested in a specific package, also worth considering is helping ubuntu by helping debian - especially if the package version is a debian version (i.e. nobody from ubuntu has made ubuntu changes) or a 0ubuntuX (ubuntu has a newer version than debian), then helping debian helps BOTH distros, as well as hundreds of debian-based distros
[20:19] <slytherin> serialorder: what are those extra things?
[20:21] <serialorder> there are three
[20:21] <serialorder> <<<<<<< dasher-4.7.0-0ubuntu2 (ubuntu)
[20:21] <serialorder> # 2003, 2004, 2005, 2006, 2007, 2008  Free Software Foundation, Inc.
[20:21] <serialorder> =======
[20:21] <serialorder> # 2003, 2004, 2005, 2006  Free Software Foundation, Inc.
[20:21] <serialorder> >>>>>>> dasher-4.7.3-1 (debian)
[20:21] <serialorder> <<<<<<< dasher-4.7.0-0ubuntu2 (ubuntu)
[20:21] <serialorder> DSYMUTIL = @DSYMUTIL@
[20:21] <serialorder> =======
[20:21] <serialorder> >>>>>>> dasher-4.7.3-1 (debian)
[20:21] <serialorder> <<<<<<< dasher-4.7.0-0ubuntu2 (ubuntu)
[20:21] <serialorder> MSGFMT_OPTS = @MSGFMT_OPTS@
[20:21] <serialorder> MSGMERGE = @MSGMERGE@
[20:21] <serialorder> NMEDIT = @NMEDIT@
[20:21] <serialorder> =======
[20:21] <directhex> blurp
[20:21] <serialorder> MSGFMT_OPTS = @MSGFMT_OPTS@
[20:21] <serialorder> >>>>>>> dasher-4.7.3-1 (debian)
[20:22] <leslieviljoen> is there any ubuntu team that just browses the bugs and reports them upstream if need be? Is that triaging?
[20:22] <superm1> !pastebin | serialorder
[20:22] <ubottu> serialorder: pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic)
[20:22] <leslieviljoen> I am re-reporting my launchpad bugs in debian right now.
[20:26] <slytherin> leleobhz: yes, there is bug-squad. there channel is #ubuntu-nugs
[20:26] <slytherin> serialorder: please use pastebin for pasting anything more than two lines.
[20:27] <slytherin> serialorder: The difference look unnecessary to me unless they were done intentionally.
[20:27] <serialorder> sorry guys, didnt know
[20:31] <superm1> that reminds me... is there a nice GUI tool for handling when this 3 way merge stuff gets spewed into one file?  meld works wonders on a 3 way diff with 3 files
[20:31] <serialorder> slythering that is what i was thinking, there is nothing in the changelog to indicate it was intentional
[20:32] <slytherin> serialorder: so drop it
[20:35]  * slytherin calls of the day
[20:35] <slytherin> s/of/off
=== DreamThi1f is now known as DreamThief
=== ogra_ is now known as ogra
[21:47] <mathiaz> kirkland: ok - what's your question with iscsitarget?
=== kompulsa_dot_com is now known as Tetracomm
[21:47] <kirkland> mathiaz: hey, so there appears to be a separate, but related bug in the iscsi_trgt.ko kernel module provided by l-u-m
[21:47] <kirkland> mathiaz: i've talked to smb and rtg, and they're going to work on that from the kernel side
[21:48] <jmarsden|work> http://packages.ubuntu.com appears to be down -- are others still able to access it?
[21:49] <kirkland> mathiaz: basically, the ubuntu module won't unload properly
[21:49] <kirkland> mathiaz: and the init script unloads that module on "stop" action
[21:49] <mathiaz> kirkland: ok
[21:49] <kirkland> mathiaz: exiting non-zero if it cannot unload the module
[21:50] <kirkland> mathiaz: which cause the package upgrade to fail
[21:50] <kirkland> mathiaz:  in the merged init script, i cleaned up a number of things, including lsb-izing it
[21:50] <kirkland> mathiaz: but i also made the module unload throw the warning/error, but it does not exit non-zero
[21:52] <kirkland> mathiaz: i was looking for a second opinion on that
[21:53] <mathiaz> kirkland: right - how important is it to unload the modules on stop?
[21:53] <kirkland> mathiaz: i also considered trying to put something in the pre-rm, that would soften the problems with the initscript "stop" failing, such that the package could be upgraded
[21:53] <kirkland> mathiaz: i'm not sure ...  the daemon is killed first, and that seems to happen well
[21:53] <mathiaz> kirkland: hm - right package upgrades.
[21:53] <kirkland> mathiaz: i can't get the module to unload at all, must reboot
[21:54] <mathiaz> kirkland: IIRC you could try to put some code in the new prerm script
[21:54] <kirkland> mathiaz: the "easy" work around is to a) stop the init script, ignore the error, b) move the init script out of the way, c) do the package upgraded
[21:54] <kirkland> mathiaz: yes, that would definitely work
[21:54] <kirkland> mathiaz: i thought maybe we'd see if a working module might be added to the kernel first
[21:55] <kirkland> mathiaz: but mainly, i was looking for a second opinion, and to alert someone about the potential issue
=== santiago-pgsql is now known as Guest95544
[21:55] <mathiaz> kirkland: yes - but that wouldn't help in the case of upgrades
[21:55] <kirkland> mathiaz: i also submitted a debian bug, with the patch
[21:55] <kirkland> mathiaz: i haven't heard anything back from them yet
[21:56] <mathiaz> kirkland: right - so you'd suggest to wait for the kernel fix before uploading a merge?
[21:56] <kirkland> mathiaz: sorry, no i uploaded the merge already
[21:57] <kirkland> mathiaz: and i noted in a bug report that a), b), c) workaround, if you're having trouble with the upgrade
[21:57] <kirkland> mathiaz: i'm asking you now if you think a maintainer script would be required
[21:58] <mathiaz> kirkland: yes
[21:58] <kirkland> mathiaz: okay ... next question...  there is a prerm script auto-generated by debhelper
[21:59] <mathiaz> kirkland: well - technically debhelper doesn't generate a prerm script - it substitutes some code in existing maintainer script
[22:00] <mathiaz> kirkland: the templates for the maintainer scripts can be found under /usr/share/debhelper/dh_make/debian
=== Guest95544 is now known as santiago-ve
[22:06]  * lamont notes that packages.ubuntu.com is happy agaain
[22:06] <Nafallo> jmarsden|work: packages.u.c back.
[22:06] <jmarsden|work> Nafallo: thanks
[22:06] <Nafallo> meeh. stupid scroll up :-)
[22:07] <lamont> heh
[22:37] <nhandler> Could someone give me a hand with merging loadlin from Debian? It FTBFS (http://paste.ubuntu.com/76599/).
[22:38] <jdong> nhandler: try -fno-stack-protector in CFLAGS?
[22:38] <DktrKranz> nhandler, try passing -fno-stack-protector to CFLAGS
[22:38] <jdong> *tells ke<noping>es to look away*
[22:39] <james_w> https://wiki.ubuntu.com/CompilerFlags#-fstack-protector
[22:41] <nhandler> I'm building it again right now. In the mean time, I'll read through that wiki page. Thanks jdong, DktrKranz, and james_w!
[22:42] <DktrKranz> nhandler, as ke<noping>es says, it's better to fix it properly, but if you're in a hurry...
[22:43] <nhandler> Well, the -fno-stack-protector didn't solve the issue. It still FTBFS with the same error
[22:44] <jdong> well loadlin probably doesn't use stdlib anyway
[22:47] <DktrKranz> nhandler, be sure CFLAGS are handled by debian/rules. If not, you need to adjust Makefile (or whatever) manually
[22:49] <nhandler> DktrKranz: debian/rules is handling the CFLAGS
[22:49] <DktrKranz> nhandler, try to pass -U_FORTIFY_SOURCE too
[22:50] <DktrKranz> buffer overflows are easier to track
[22:54] <nhandler> DktrKranz: Nope. -U_FORTIFY_SOURCE didn't fix it either.
[22:54] <NCommander> DktrKranz, -U?
[22:54] <NCommander> Why do you want to undefine it?
[22:56] <DktrKranz> NCommander, testing purposed
[22:57] <NCommander> ah
[22:57] <DktrKranz> nhandler, my bet is debian/rules doesn't pass CFLAGS to inner Makefile
[22:59] <james_w> would anybody like to review my changes in http://paste.ubuntu.com/76605/ ?
[23:01] <nhandler> DktrKranz: You might be right. The rules file sets up the CFLAGS variable. However, the only time it uses it is when deeling with freeramdisk. (http://paste.ubuntu.com/76603/)
[23:02] <DktrKranz> nhandler, if you have a Makefile in parent directory, try adjusting it by inserting -fno-stack-protector after gcc invocation
[23:06] <DktrKranz> james_w, at a first glance, it seems good (it follows the recipe provided by CompilerFlags)
[23:09] <james_w> thanks DktrKranz
[23:14] <nhandler> DktrKranz: Nope. Adding -fno-stack-protector to the make file didn't do any good either.
[23:16] <kirkland> mathiaz: hmm, i'm having some strange problem with dh_installdeb
[23:19] <kirkland> mathiaz: my diff currently looks like this: http://pastebin.ubuntu.com/76612/
[23:22] <mathiaz> kirkland: where does the init script fail currently? In prerm?
[23:22] <kirkland> mathiaz: well, the substitution claimed by dh_installdeb isn't currently happening
[23:22] <kirkland> mathiaz: there must be a debian/rules step missing
[23:22] <kirkland> mathiaz: but dh_installdeb appears to be present in the two places i'd expect it
[23:25] <DktrKranz> nhandler, I need to look at it then
[23:26] <nhandler> DktrKranz: No problem. I'll probably just put the merge up for grabs. I have no personal reason for doing it. In the end, it would just be another MOTUs solution that I would use. If nobody handles it by DIF, I'll take another look at it.
[23:28] <DktrKranz> nhandler, ok. I'll leave soon (quite late here), I'll have a look at it tomorrow (if I remember, of course)
[23:29] <nhandler> Thanks again for your help DktrKranz
[23:29] <directhex> james_w, which package are you working on mono transition for, OOI? it would be great if you could take ownership on http://wiki.debian.org/Teams/DebianMonoGroup/Mono20TransitionTODO to avoid duplication of effort
[23:29] <james_w> directhex: it was banshee. I requested the sync, and so got stuck with the build failure email
[23:29] <directhex> ah, right
[23:30] <directhex> well, slomo will receive appropriate kicks up the butt. since mono 2 is now in experimental, he'll get the same FTBFS there until he makes a 1.4.1-2
[23:30] <james_w> yup
[23:31] <james_w> I'll see if I can get something that builds for him to start from
[23:31] <directhex> although no sign of meebey tonight (grrr!)
[23:33] <kirkland> mathiaz: ^ thoughts?
[23:34] <mathiaz> kirkland: looking at the package now
[23:34] <kirkland> mathiaz: thx
[23:35] <mathiaz> kirkland: but a quick comment regarding your pastbin - why not put the logic in failed-upgrade?
[23:35] <directhex> james_w, are you a banshee user, then?
[23:35] <mathiaz> kirkland: it seems that this is the place to handle a failure of the prerm script from the existing package
[23:35] <james_w> directhex: nope
[23:44] <snikker> when i try to make a .deb package, i've got this warning: "dpkg-gencontrol: warning: unknown substitution variable ${shlibs:Depends}" and in "${misc:Depends}", can you help me?
[23:45] <mok0> snikker: they are defined in debian/control
[23:46] <mok0> snikker: you can safely delete it
[23:46] <azeem> snikker: it means nothing had to be substituted
[23:46] <azeem> AIUI
[23:46] <snikker> yes, they are there, isn't right?
[23:46] <azeem> well, apparently they are not needed
[23:46] <azeem> snikker: what programming language is your package in?
[23:46] <mok0> snikker: you can also leave them, it's not a serious problem
[23:47] <azeem> *if* they are really not needed
[23:47] <snikker> it's an service menu for kde4... so i can ignore it?
[23:47] <azeem> eh
[23:47] <azeem> kde4 is not a programming language
[23:47] <azeem> is it in C++?
[23:48] <mok0> snikker: so it's just image and text files?
[23:48] <kirkland> mathiaz: i suppose it could be handled there
[23:48] <snikker> if the servicemenu is in c++? no, it's just a text file (file.desktop)
[23:48] <azeem> ok then
[23:48] <azeem> snikker: then you can ignore it and/or delete it indeed
[23:49] <snikker> azeem: ok, thanks...
[23:50] <snikker> azeem: but suppose that i've got a c/c++ file (instead of text file) and i receive this warning, what i must do?
[23:52] <mok0> snikker: then you wouldn't get the warning
[23:53] <azeem> all c/c++ programs need at least the C/C++ system libraries, so if you get the ${shlibs:Depends} warning, it might mean the package build process failed to build or install the program
[23:53] <azeem> the ${misc:Depends} warning might not be a problem
[23:55] <snikker> azeem: ok, but if i've got a ${shlibs:Depends}, how can i check what's the problem?
[23:55] <snikker> there is a way for check it?
[23:58] <azeem> no, you will have to carefully manually inspect the .deb you get