[00:51] <radix> what's the policy about using a distro series of UNRELEASED? I've seen it a few times
[00:52] <azeem> it's a placeholder for a not-yet-ready-to-be-uploaded package
[00:52] <radix> hmm, okay, I thought I've seen changelogs that had UNRELEASED for one entry and a real distro series for the next
[00:52] <azeem> so you don't accidently upload a half-ready package, cause unreleased is not a valid distro
[00:52] <radix> ah, okay
[00:52] <azeem> radix: that means that changelog didn't get uploaded then
[00:52] <radix> so it's not actually processed by anything, it's just a convention to prevent mistakes
[00:52] <azeem> I think so, yes
[00:59] <calc> radix: i think normally people don't bump package revision for unreleased packages so you shouldn't see that often unless you are in looking in a revision control system
[01:00] <calc> er i mean they just rename UNRELEASED to the distro and don't bump the version again for the distro version
[01:00] <radix> so I was preparing a package for releasing upstream version 1.0.24 but now 1.0.25 is out. should I just rewrite my top changelog entry to talk about 1.0.25 and cat the two changelogs together or should I add a new entry?
[01:00] <azeem> the former is more customary
[01:00] <calc> radix: if you never uploaded 1.0.24 then i just cat them together
[01:00] <radix> hm, okay
[01:00] <radix> alright cool
[01:01] <azeem> if you prefer the latter, then it makes sense to keep the unreleased around so people reading the changelog know that didn't get uploaded
[01:01] <azeem> but I think most people go with just changing the version
[03:45] <nhandler> ScottK-laptop: ping
[03:46] <ScottK> Pong
[03:46] <ScottK> nhandler: ^^
[03:46] <ScottK> Is this aboug skanlite?
[03:46] <nhandler> Yeah ScottK
[03:46] <nhandler> Was your upgrade (aside from the icon) the same as the one ajmorris did?
[03:47] <ScottK> Yes.
[03:47] <ScottK> Actually I didnt' diff them, but I probably should.
[03:47]  * ScottK fires up diff.
[03:47] <nhandler> Ok, I just wanted to verify. And I do appreciate you giving him credit for the desktop file icon change upload
[03:48] <ScottK> nhandler: I also dropped the transitional package.
[03:48] <nhandler> Ok, that is fine
[03:48] <ScottK> Well it was my bad.  I should have checked bugs before I updated it.
[03:49] <nhandler> Well, it isn't a huge deal. The package got updated, and the bug got closed. ajmorris also got the learning experience of doing the upgrade.
[03:50] <ScottK> Hopefully he doesn't feel too upset I did it too.
[03:52] <nhandler> ScottK: I just talked with him. He is fine and looking forward to trying another upgrade ;)
[03:52] <ScottK-laptop> OK.  Great.  I felt bad when I realized I'd bypassed the work he did.
[05:30] <hyperair> http://revu.ubuntuwire.com/details.py?package=sigx <-- review, anyone?
[06:08] <fabrice_sp> hyperair: lintian gives me an error on package libsigx-2.0_2.0-0ubuntu1_amd64.deb
[06:08] <fabrice_sp> E: libsigx-2.0: sharedobject-in-library-directory-missing-soname usr/lib/libsigx-2.0.so
[06:09] <fabrice_sp> and I'm having a warning on the dev package: W: libsigx-dev: debian-changelog-file-is-a-symlink
[06:09] <fabrice_sp> and no doc package built :-/
[06:13] <hyperair> fabrice_sp: are you sure there isn't a doc package built?
[06:13] <hyperair> fabrice_sp: it built on my system
[06:13] <hyperair> libsigx-doc
[06:13] <hyperair> and yes i know that there isn't a SONAME, but the problem is that the upstream made it that way. what should i do?
[06:14] <hyperair> also, i don't know what i can do about the warning. dh_something automatically makes stuff the /usr/share/doc/<pkg>/ files symlinks if a dependency of the same source package contains them
[06:15] <hyperair> i mean if a dependency, which comes from the same source packaage includes them
[06:15] <hyperair> -dev depends on -2.0
[06:15] <fabrice_sp> hyperair: about doc package. I switched to sbuild recently, and could be my fault. I'll check
[06:15] <hyperair> alright
[06:15] <hyperair> so what should i do about that missing SONAME?
[06:15] <hyperair> should i add it?
[06:18] <fabrice_sp> I've just seen a big problem with sources: not all sources have a copyright.
[06:18] <fabrice_sp> (header)
[06:28] <RAOF_> hyperair: I believe the cannonical response to "upstream doesn't use a SONAME" is the "let's talk about library versioning" talk.
[06:32] <hyperair> T_T why do i pick all the hardest packages to package
[06:33] <fabrice_sp> because they are all hard to package? :-P
[06:35] <hyperair> no, the first one i picked was codelite, and i can't continue because all the extensions are placed in /usr/share/codelite, instead of /usr/lib/codelite
[06:35] <hyperair> that one also had copyright header issues
[06:35] <hyperair> which i managed to persuade upstream to fix
[06:36] <hyperair> but the whole extensions dir thing still requires more work from upstream
[06:36] <hyperair> and then there's this one which has issues with copyright headers missing as well
[06:36] <hyperair> say, is there any tool that can show me which files are missing copyright headers without having to upload to revu?
[06:37] <fabrice_sp> I do it by hand
[06:37] <fabrice_sp> opening all single src file
[06:41] <hyperair> it's tedious
[06:41] <fabrice_sp> I know, but without copyright header, the package won't be accepted...
[07:37] <pmjdebruijn> good morning
[07:37] <pmjdebruijn> Does anybody have time to review my new package: http://revu.ubuntuwire.com/details.py?package=lensfun
[08:10] <pmjdebruijn> I already fixed all lintian errors, and a amd64 related issue
[08:10] <pmjdebruijn> It should be in pretty good shape
[08:24] <cutout> hello, can you please review my package it is called monajat
[08:30] <RAOF_> hyperair: There's 'licensecheck', which I think is what revu uses.  In ubuntu-dev-tools, I believe.
[08:30] <hyperair> RAOF_: i see. thanks
[08:31] <RAOF_> Libraries are always more difficult.
[08:32] <cutout> hello am searching for a MOTU :-D
[08:58] <pythetic> hi. if a daemon package has no sensible default configuration should it have an ENABLED="false" line in a /etc/default/foo file?
[08:59] <directhex> sounds sensible to me
[10:43] <cutout> Hello am new here, how can I get my package reviewed??
[10:49] <DktrKranz> StevenK: re bug 303245, I don't see sources in Intrepid yet. Is that normal?
[10:59]  * directhex wonders who's alive, can do merges, and can be poked into action with a mere cookie
[11:04] <Laney> didrocks: you rocks
[11:05] <Laney> huats: (you're not here but) you rocks too
[11:05] <directhex> they do?
[11:06] <sebner> directhex: subscribe u-u-s?
[11:08] <Laney> directhex: Yeah! They did stuff that I need to update glom and goocanvasmm, so they get roses and chocolates from me
[11:08] <directhex> sebner, done!
[11:11] <sebner> directhex: beagle?
[11:12] <directhex> sebner, yes!
[11:12] <directhex> it's the beagliest!
[11:13] <sebner> directhex: I'll be back in some hours. If nobody takes it until then I'll do it
[11:13] <directhex> yay
[11:49] <pmjdebruijn> does anybody have the time to take a look at my new package: http://revu.ubuntuwire.com/details.py?package=lensfun
[11:54] <didrocks> Laney: ^^
[12:28] <cutout> looking for someone to review my package
[12:28] <cutout> ???
[12:28] <directhex> cutout, people are at the ubuntu developer summit. it's nighttime in california
[12:29] <cutout> sorry, but when can I connect to this channel
[13:18] <mikearthur> hey guys, trying to package my software for Ubuntu, is this the right channel for questions?
[13:29] <ScottK-laptop> mikearthur: It is the right channel.
[13:29] <mikearthur> in my control file, as debuild gets my runtime deps automatically, do I add the devel packages to Build-Depends?
[13:30] <ScottK-laptop> Generally yes.
[13:31] <mikearthur> ok, thanks
[13:32] <mikearthur> is there any way of tweaking ${shlibs:Depends} output, it's depending on too fine a Qt version
[13:32] <mikearthur> e.g. 4.4.3 when 4.4.0 works fine
[13:32] <Laney> But 4.4.3 is already in the release, right?
[13:32] <mikearthur> yeh, I guess
[13:32] <ScottK-laptop> mikearthur: It's doing that because that's what you built it against.  If it was built against an earlier version it would give a different anwser.
[13:33] <mikearthur> ah ok
[13:33] <mikearthur> yeh, I guess if that's in the release it's fine
[13:33] <ScottK-laptop> mikearthur: Put the correct minimum version in the build-dep version requirement (for backports) and it'll all work out.
[13:33] <mikearthur> ok, thanks
[13:34] <mikearthur> also, my package probably isn't going to go in Ubuntu (proprietary, sadly)
[13:34] <mikearthur> so is it acceptable for the hardy package to depend on something in hardy-backports?
[13:34] <ScottK-laptop> emgent: It looks like UTU is stuck.
[13:34] <ScottK-laptop> mikearthur: That's up to you and your use case then.
[13:35] <ScottK-laptop> mikearthur: If your target is Hardy with backports enabled, then it's fine.
[13:35] <mikearthur> the fact you haven't gasped and tried to kill me over the internet means I'll probably do it then ;)
[13:35] <ScottK-laptop> mikearthur: If you learn about packaging your proprietary app, maybe you'll also use that knowledge for good.
[13:35] <mikearthur> aye, I will
[13:35] <mikearthur> I'm a KDE developer as well, just got to pay the bills and that
[13:36] <mikearthur> work for www.mendeley.com and we may opensource one day
[13:36] <ScottK-laptop> Understand.  We all have bills to pay.
[13:36] <ScottK-laptop> mikearthur: What do you work on in KDE?
[13:37] <mikearthur> little bits and pieces
[13:37] <mikearthur> KOrganizer, KDEPIM stuff
[13:37] <ScottK-laptop> OK.  Ah.
[13:38] <ScottK-laptop> mikearthur: If you want to work on KDEish stuff here, you're welcome to join us in #kubuntu-devel.
[13:38] <mikearthur> yeh, cheers
[15:29] <bobbo> Can any MOTU ACK a sync request?
[15:30] <DktrKranz> bobbo: you can do it on your own now ;)
[15:30] <bobbo> DktrKranz: hehe, I meant, can I ACK someone elses sync request now?
[15:31] <DktrKranz> bobbo: unless it's maintained by a specific subset of people (you should notify them), you can
[15:31] <bobbo> DktrKranz: cool, thanks :)
[15:31] <DktrKranz> you're welcome :)
[15:31] <DktrKranz> bobbo: and thanks for joining u-u-s!
[15:32] <bobbo> DktrKranz: I spent most of the last year sitting in that queue, I'll do anything to help it out!
[15:33] <DktrKranz> bobbo: GREAT!
[15:34] <bobbo> DktrKranz: already cleared out most of an NBS too (Being a MOTU is awesome)
[15:34] <pflanze> Hello. Who should I talk to about the gambc package which lists the ubuntu-motu mailing list as maintainer?
[15:36] <pflanze> Or, asked differently: *should* I talk with anyone, or should I just communicate with the Debian packager whose package I guess is the basis of this one?
[15:36] <DktrKranz> bobbo: heh, it's good to have superpowers to speed up things
[15:37]  * DktrKranz has three items in u-m-s queue right now, waiting for sponsors too :)
[15:50] <DktrKranz> bobbo: have you already started clearing NBSes?
[15:51] <bobbo> DktrKranz: yep, did libparted1.8-9 -> libparted1.8-10 last night
[15:52] <DktrKranz> bobbo: it's good, but I'd wait DIF just to avoid wasting buildds time if newer versions are autosynced from Debian (rarely, these days though). They get rebuilt automatically.
[15:54] <bobbo> DktrKranz: OK, I checked in Debian to see if there were new versions but there were none, so thought that would be OK?
[16:14] <directhex> sebner, still about?
[16:38] <Elbrus> pflanze: I guess it depends what the subject is. You are invited to just post your question here.
[16:38] <Elbrus> people will redirect if necessary
[16:43] <hefe_bia> Hi! What has higher priority: Removing unnecessary (big) stuff from original sources or leaving the original source archive intact? (Speaking about 2MiB vs. 10MiB)
[16:45] <directhex> hefe_bia, disk space is cheaper than developer time
[16:45] <directhex> hefe_bia, repacking orig sucks
[16:46] <hefe_bia> directhex: ok, nice - that's what I thought. Just wanted to make sure before uploading to revu...
[16:49]  * jpds waves at SWAT.
[16:53]  * SWAT waves back at jpds 
[16:54] <hefe_bia> So... I have fixed the licensing issues of gebabbel together with upstream. Gebabbel is a frontend for gpsbabel. If someone wants to review: http://revu.ubuntuwire.com/details.py?package=gebabbel - I'd be happy ;)
[16:58] <DktrKranz> hefe_bia: since I commented it, I'd be happy to review it later this evening, mind remind me later?
[17:00] <hefe_bia> DktrKranz: Thank you! I'll be here for a while (Have to work late...)
[17:01] <DktrKranz> hefe_bia: heh... work is a common tragedy :)
[17:01] <hefe_bia> ;)
[17:12] <pflanze> Elbrus: I had written to the mailing list in the meantime.
[17:19] <cutout> hello am looking for a MOTU to review my package... is this the right time??
[17:21] <DktrKranz> cutout: yes
[17:52] <jcfp> Looking for volunteers to review http://revu.ubuntuwire.com/details.py?package=sabnzbdplus. It was advocated before but has received no reviews in a long time. TIA
[18:59] <DktrKranz> hefe_bia, commented on gebabbel
[19:01]  * directhex wonders who's alive, present, and has magic merge powers
[19:01] <sebner> directhex: myself, you are a way too impatient
[19:02] <directhex> sebner, yes!
[19:02] <sebner> directhex: I'll take a look and upload beagle merge then
[19:02] <DktrKranz> beagle?
[19:02] <DktrKranz> sebner, do you remember our time with beagle? :)
[19:03] <sebner> DktrKranz: hihi, yes
[19:03] <directhex> yeah yeah, i know, beagle sucks
[19:03] <directhex> but unless you're talking about yanking it from the archive, this merge is needed
[19:03] <sebner> directhex: no, he means that myself also merged beagle sometimes
[19:03] <DktrKranz> we spent half an hour to discover why that one FTBFSed
[19:04] <sebner> DktrKranz is the FTBFS killer =)
[19:04] <DktrKranz> wasn't it ncommander?
[19:04] <sebner> DktrKranz: nope, you you yo
[19:04] <directhex> NCommander is the FTBFS killer. no disrespect, DktrKranz, but his record's a few miles long ;)
[19:04] <sebner> heh
[19:15] <hefe_bia> DktrKranz: the gpsbabel stuff is not used at all for the Ubuntu package. It does not link with gpsbabel. It uses CLI. Upstream just wants to ship the static binaries for convenience.
[19:22] <DktrKranz> hefe_bia, I understand, but I think it would be clearer if that part would be omitted
[19:23] <hefe_bia> So I should change the original tarball?
[19:24] <DktrKranz> My guess is that, others might think it differently
 hefe_bia, disk space is cheaper than developer time
[19:25] <hefe_bia>  hefe_bia, repacking orig sucks
[19:25] <hefe_bia> ;)
[19:28] <DktrKranz> unsafe binary objects are much worse ;)
[19:28] <hefe_bia> But they are not used at all. They don't make it into the .deb
[19:32] <rjune> hefe_bia, did you catch that I found out how to verify the version of the dev environ pbuilder has?
[19:32] <mseaborn> would anyone like to review my package for Xpra (which is basically "screen" for X)? :-)  i uploaded a package to http://revu.ubuntuwire.com/details.py?package=parti-all
[19:32] <hefe_bia> rjune: no. I think I was offline then. How did you do it?
[19:33] <directhex> wait, wait, hold on, hefe_bia never said they were BINARY
[19:33] <directhex> in that case you need to +dfsg it
[19:33] <directhex> unused source is completely different to unused binary
[19:33] <hefe_bia> directhex: ok. Misunderstanding there... ;)
[19:33] <rjune> cat /etc/lsb-release
[19:34] <rjune> that seems to be it.
[19:34] <hefe_bia> rjune: nice. Didn't think of that ;)
[19:34] <directhex> rjune, technically i think you're meant to use the lsb_release command
[19:36] <rjune> directhex, where were you two days ago when I asked? :-)
[19:36] <directhex> rjune, eating pizza
[19:37] <iulian> Hmm, yummy.
[19:37] <hefe_bia> directhex: Regarding the binary issue: Is this for legal or for security reasons? (dfsg version)
[19:37] <rjune> oh, well then. pizza makes it all better
[19:38] <directhex> hefe_bia, security reasons are precisely WHY you're meant to +dfsg it to remove binary junk
[19:38] <LaserJock> well, +dfsg is legal
[19:38] <ScottK> LaserJock: +1
[19:38] <LaserJock> but security is a part of it for sure
[19:39] <pochu> but if it's not used at all, then there's no need to remove it, is there?
[19:39] <pochu> (providing the source is shipped too, otherwise it would be a DFSG violation)
[19:39] <hefe_bia> source is shipped too.
[19:40] <LaserJock> I probably wouldn't bother if it doesn't end up in the .deb
[19:40] <pochu> then I think you can leave it there
[19:40]  * DktrKranz wonders why to ship them, then
[19:41] <hefe_bia> https://wiki.ubuntu.com/PackagingGuide/Howtos/ChangingTheOrigTarball also does not mention any reason to strip them
[19:41] <directhex> ftpmaster would probably reject it if you submitted to debian
[19:41] <directhex> if you care
[19:41] <DktrKranz> 13,9 Mb of "junk" against a total size of 14.3 Mb
[19:41] <pochu> DktrKranz: ouch
[19:41] <LaserJock> directhex: you think so?
[19:42] <pochu> hefe_bia: btw, why does upstream ship them, if it's not used at all?
[19:42] <directhex> LaserJock, if i know what ftpmaster is like, yes
[19:42] <directhex> pochu, optional. probably
[19:42] <pochu> hmm, what package are we talking about? :P
[19:42] <directhex> pochu, i.e. --with-foolib=system
[19:42] <LaserJock> wait it's 13.9 MB of binary in 14.3 MB total?
[19:42] <LaserJock> directhex: as do I
[19:42] <pochu> s/what/which/
[19:42] <DktrKranz> pochu, gebabbel
[19:43] <hefe_bia> pochu: He wants to ship them for convenience so users don't habe to compile gpsbabel themselves.
[19:43] <pochu> ok
[19:43] <DktrKranz> LaserJock, exactly
[19:43] <hefe_bia> I don't think it's a good idea but I couldn't convince him otherwise.
[19:43] <LaserJock> DktrKranz: holy cow, that's a whole different ball game
[19:44] <hefe_bia> I'm happy to provide a +dfsg version as long as I don't get somebody else complaining about that...
[19:44] <LaserJock> that means 97% of the package in terms of space is binary!
[19:44] <DktrKranz> well, I need to redo my numbers... half of the 13.9 Mb are from gpsbabel source tarball
[19:44] <LaserJock> I don't know if I'd necessarily call that a +dfsg, as it's not a legal issue
[19:45] <DktrKranz> but we have some .exe and .dll which are ~ 7 Mb
[19:45] <DktrKranz> maybe a +repack would help?
[19:45] <LaserJock> yeah, perhaps so
[19:46] <hefe_bia> btw, I had +dfsg before when upstream did not include the sources...
[19:46] <DktrKranz> that was right
[19:46] <LaserJock> that's enough extra cruft to make it worth stripping out, IMO
[19:47] <hefe_bia> so I'll move the get-orig-source stuff back in and change it accordingly to use repack instead of dfsg and exclude the sources, too...
[19:47] <pochu> hefe_bia: try to convince upstream if users don't want to build that library, they don't need to as it's optional :)
[19:47] <DktrKranz> mseaborn, I'll have a look
[19:48] <pochu> hefe_bia: and that instead of shipping binaries in the source tarball, they could build the application itself and ship that separately
[19:49] <hefe_bia> pochu: I told him that it would be better to leave the binaries out of the source distribution.
[19:52] <mseaborn> ﻿DktrKranz: thanks
[20:02] <fabrice_sp> Hi! Someone willing to spend some time reviewing dvdstyler (http://revu.ubuntuwire.com/details.py?package=dvdstyler)? Thanks!
[20:04] <DktrKranz> mseaborn, commented
[20:05] <cutout> Is there a MOTU to review JAVA applications here?
[20:07] <rjune> ok, so I've read through the basic docs. I want to build a package. I'm guessing that the packages at merges.ubuntu.com all have problems with Jaunty?
[20:08] <rjune> aka, what package should I work on?
[20:14] <RainCT> ScottK: Someone is asking me about an antivirus for Ubuntu (to protect Ubuntu itself, not other systems). I'm right if I tell him "just keep your system updates and forget about antivirus stuff", aren't I?
[20:14] <directhex> RainCT, technically, yes
[20:15] <ScottK-laptop> RainCT: It depends.  Generally yes, but there are some cross-platform problems in, for instance, Firefox.
[20:15] <ScottK-laptop> RainCT: If you know what you're doing, it's  no problem.
[20:15] <RainCT> ScottK-laptop: but is an antivirus going to avoid this?
[20:15] <mseaborn> ﻿DktrKranz: what is wrong with "Architecture: any" in this case?  the package includes a python extension module.  (would you prefer if i posted this question on the REVU review page?)
[20:16] <directhex> RainCT, technically, of course, you could recommend clamav. but most people used to the idea of virus scanners expect on-access protection
[20:16] <ScottK-laptop> RainCT: Not really sure.  Clamav also has some anti-phishing stuff in it too now, so it's not completely irrelevant.
[20:16] <ScottK-laptop> Right, which clamav can't do until we get the Dazuko modules in the kernel.
[20:17] <directhex> you mean clam IS getting on-access?
[20:17] <directhex> hurrah
[20:17] <LaserJock> RainCT: I would venture to guess that somebody asking about antivirus for Ubuntu is really talking about overall security
[20:18] <LaserJock> and not just specifically about viruses
[20:18] <RainCT> ScottK-laptop, directhex : Thanks. I'll quote you, if you're fine with this.
[20:18] <rjune> ogra!
[20:18] <directhex> RainCT, i never say anything i'm not prepared to back up
[20:18] <RainCT> + LaserJock: he just heard about antivirus for GNU/Linux on the radio or something and doesn't want to believe me that it's unnecessary :P
[20:19] <DktrKranz> mseaborn, does it compile architecture dependent code?
[20:19] <directhex> Grisoft sell antivirus for linux, albeit an obsolete version (8.0 is current, only 7.5 for linux)
[20:20] <ScottK-laptop> directhex: It's actually for Klamav.  Klamav + Clamav + Dazuko can do on access.
[20:20] <LaserJock> RainCT: I generally tell people that it's always possible, but so far it's not a very common threat
[20:20] <LaserJock> people seem more like likely to get nailed through Firefox or ssh
[20:20] <ScottK-laptop> Yep.
[20:21] <LaserJock> I've seen a number of machines broken into via ssh
[20:21] <ScottK-laptop> OTOH, if you forward stuff to friends with Windows, making sure you forward on clean stuff is polite.
[20:21] <LaserJock> yeah, Ubuntu does a public service :-)
[20:21] <ScottK-laptop> LaserJock: Yeah, this is why I rate limit ssh attempts in iptables.
[20:22] <rjune> ogra, How was the booze?
[20:22] <LaserJock> "help your neighbor, run Ubuntu" ;-)
[20:22] <LaserJock> ScottK-laptop: I use fail2ban
[20:22] <directhex> how frequent does the auto debian importificationer run?
[20:23] <sebner> directhex: uploaded
[20:24] <directhex> sebner, ta!
[20:24] <sebner> directhex: and I left a comment :P read it carefully ^^
[20:24] <jpds> http://www.flickr.com/photos/kwwii/3103305868/ <- UDS group photo.
[20:25] <krusaf> directhex krusaf@ares:~$ find /etc/cron* -iname "*apt*"
[20:25] <krusaf> /etc/cron.daily/apt
[20:25] <krusaf> /etc/cron.daily/aptitude
[20:26] <directhex> sebner, i don't open a bug until a debdiff is written already! you're trying to break my workflow :'(
[20:26] <sebner> directhex: your workflow != ubuntu workflow :P
[20:26] <directhex> waaaaaaaa!
[20:28] <RainCT> LaserJock: thanks
[20:28] <RainCT> LaserJock: re SSH, why don't you just disable password authentication? :P
[20:45] <LaserJock> RainCT: because I might need to ssh in :-)
[20:46] <RainCT> LaserJock: then you're like me, just that I don't care about security and have no protection at all :P
[20:46] <RainCT> perhaps I should install fail2ban too..
[20:50] <LaserJock> RainCT: it's helpful, I figured it out after having a "problem" :-)
[20:51] <RainCT> heh
[20:51] <RainCT> hopefully not a bad problem :P
[20:51] <LaserJock> it's not nice when your computer is used to make like 100k https pings in a couple minutes
[20:51] <LaserJock> so I then learned 2 things
[20:52] <LaserJock> 1) fail2ban or similar are very handy
[20:52] <LaserJock> 2) get rid of old test users as soon as you're done with them
[20:53] <RainCT> lol yeah, 2 is a good point :)
[20:54] <RainCT> uhm.. fail2ban could need a GUI :P
[20:54] <LaserJock> RainCT: I think it'd sort of bee a good addition to the ufw stuff
[20:54] <LaserJock> letting you poke holes in your firewall with sanity ;-)
[21:26] <hefe_bia> If somebody from the previous discussion is interested: I have updated gebabbel and stripped the unnecessary parts from the source tarball: http://revu.ubuntuwire.com/details.py?package=gebabbel
[21:33] <CarlFK> when I run dpkg-buildpackage i get a .deb for the platform I am on.  I need to build a 32 bit when I am on x64.  is there a way to do that that does not involve touching the debian/ files?
[21:33] <CarlFK> something like DEB_BUILD_OPTIONS="nostrip" dpkg-buildpackage -rfakeroot -uc -b
[21:34] <LaserJock> CarlFK: you could certainly do it with pbuilder/sbuild
[21:36] <CarlFK> hmm, will I need 32bit:  apt get build-dep foo
[21:38] <directhex> CarlFK, dpkg doesn't deal with 32-bit and 64-bit versions of the same lib installed at once
[21:38] <CarlFK> I may be doing this the hard way.  "﻿try running the 32bit binaries"  what is the best way to do that?
[21:38] <LaserJock> CarlFK: I'd set up a 32bit pbuilder
[21:39] <directhex> so would i
[21:39] <CarlFK> https://wiki.ubuntu.com/PbuilderHowto  good place to start?
[21:40] <LaserJock> CarlFK: probably
[21:40] <directhex> it has a good pbuilderrc iirc
[21:41] <CarlFK> "pbuilder is useful for is building i386 packages on an AMD64 machine"  :)
[21:44] <directhex> it's not foolproof though!
[21:44] <directhex> there are cases where your real cpu arch is used
[21:44] <directhex> linux32 should be liberally applied to problem packages
[21:48] <et3> Is it possible to install a package that just adds text to a system file and deletes that text when uninstalled?
[21:48] <et3> For instance: if I were to make a package that added it's own bash completion, how would I do that?
[22:06] <\\localhost> hello, how can i setup the build process in the rules file for a source that is using cmake ?
[22:07] <DRebellion> sebner, do you think that the rpath issue is present in cifer, or should i reupload a package with the chrpath calls removed?
[22:13] <LaserJock> \\localhost: depends on what build system you're using (debhelper, cdbs) but in general I think you just want to run cmake in the configure rule
[22:15] <\\localhost> LaserJock hmmm i have added cd build && cmake ../ in the build-stamp: configure-stamp
[22:18] <LaserJock> \\localhost: is there a configure: rule?
[22:18] <LaserJock> \\localhost: you don't really need to really cd build
[22:18] <LaserJock> \\localhost: you could just run: cmake .
[22:19] <\\localhost> well i do that because cmake doesn't have "clean" rule
[22:19] <\\localhost> so i have put "rm -rf build" as clean rule
[22:19] <\\localhost> but i don't have a configure: rule
[22:19] <LaserJock> \\localhost: makes sense
[22:19] <\\localhost> configure: configure-stamp
[22:20] <\\localhost> configure-stamp:
[22:20] <\\localhost> i only have theses two
[22:20] <LaserJock> ok, right, configure: calls configure-stamp:
[22:20] <LaserJock> so that's where you want it
[22:22] <\\localhost> yes i've put it there but when i call debuild -S -sa i have an error
[22:23] <LaserJock> \\localhost: ah, what's the error?
[22:23] <\\localhost> a mistake of mine , i forgot to gzip the orig file
[22:23] <\\localhost> gonna repair this
[22:25] <\\localhost> okay i've generate the dsc file
[23:15] <bddebian> Heya gang
[23:15] <directhex> bah, i need to file a sync request
[23:15] <directhex> hello bddebian
[23:15] <LaserJock> bddebian: Barry!
[23:17] <bddebian> Heya directhex, LaserJock!
[23:18] <LaserJock> bddebian: long time, no see
[23:18] <bddebian> LaserJock: Aye, where you been hiding? :)
[23:19] <LaserJock> bddebian: in a dissertation
[23:20] <StevenK> With a chemistry set
[23:22] <LaserJock> StevenK: actually the chemistry set is at home (not sure why)
[23:23] <\\localhost> LaserJock thanks for your support
[23:23] <LaserJock> \\localhost: no problem, I didn't do much but tell you you were doing it right :-)
[23:24] <\\localhost> ;)
[23:24] <bddebian> heh