[00:00] <crimsun> goodhabit: I don't understand your question.
[00:05] <goodhabit> dpkg-source: warning: extracting unsigned source package (./wired-0.6.orig.tar.gz)
[00:05] <goodhabit> dpkg-source: error: syntax error in source control file ./wired-0.6.orig.tar.gz at line 1: line with unknown format (not field-colon-value)
[00:05] <goodhabit> What can I do with it?
[00:31] <joejaxx> ah that stinks bryce is not in here :\
[00:33] <joejaxx> i wanted to talk to him about including my Xorg patch :D
[00:34] <joejaxx> and it needs to get in before freeze as it would create a new binary package off of the xorg-server source package
[00:34] <RAOF> joejaxx: What does it do?
[00:35] <joejaxx> it gives us KDrive :D
[00:35] <RAOF> I've seen that scroll past in the configure output, but what does it do?
[00:35] <joejaxx> it is tiny X
[00:36] <joejaxx> xserver*
[00:36] <joejaxx> a tiny*
[00:36] <RAOF> Ok, that makes sense.  Eventually :)
[00:36] <joejaxx> yeah
[00:36] <joejaxx> i am probably going to use it for fluxbuntu :)
[00:36] <joejaxx> i am using it now but i have not gotten xinerama to work correctly
[00:38] <minghua> What does the ordinary Xorg xserver have that XDrive doesn't?
[01:41] <rexbron> Anyone got time for a review? http://revu.ubuntuwire.com/details.py?package=libopenfx
[02:21] <bddebian> Heya gang
[02:21] <LaserJock> hi bddebian
[02:21] <RAOF> Yo bddebian
[02:22] <bddebian> Hi LaserJock, RAOF
[02:22]  * pochu waves
[02:22] <ion_> Hi all
[02:22]  * ion_ is about to go to bed
[02:23] <ion_> I just took my first shot at shooting and tonemapping an HDR photo. :-)
[02:23] <ion_> (There’s a lot of room for improvement, of course)
[02:30] <RAOF> Licensing sucks :(
[02:31] <crimsun> eh?
[02:31] <bddebian> Yep
[02:32] <RAOF> As in: reviewing debian/copyright for packages on revu.
[02:33] <ScottK> Depends on how much pleasure you take out of telling people, "Hey, you suck."
[02:33] <bddebian> heh
[02:34] <crimsun> ya gotta start somewhere, heh  :-)
[03:23] <RAOF_> Wow.  Translating pypy is an excellent way to generate excessive system load.
[03:23] <bddebian> heh
[03:24] <crimsun> for me, apparently so is scrolling in a Web browser while using the "normal" compiz config.
[03:24] <crimsun> yay, exa.
[03:25] <bddebian> Gah, I don't know how to test this libapache2-mod-xmlrpc2 properly :-(
[03:27] <emgent> crimsun, i talked now with kees about ubuntu-hackers team
[03:27] <crimsun> emgent: ok
[03:27] <emgent> he will talk with infra team monday
[03:27] <emgent> and go to ufficializzation :)
[03:27] <crimsun> emgent: excellent.
[03:28] <emgent> ^^
[03:28] <LaserJock> ubuntu-hackers?
[03:28] <emgent> LaserJock, yep
[03:28] <emgent> https://edge.launchpad.net/~ubuntu-hackers
[03:29] <LaserJock> fascinating
[03:29] <emgent> yep :)
[03:30] <LaserJock> what kind of thing would the team even do?
[03:30] <RAOF> Wow.  Enough system load to cause irssi to timeout, apparently.
[03:32] <emgent> LaserJock, team for infra debug and ubuntu community (and not) system.
[03:32] <emgent> penetrations test, auditing and builting patch
[03:32] <LaserJock> hmm
[03:33] <emgent> only about infra system (webapps etc..).
[03:34] <emgent> "The team of hackers Ubuntu aims to take care of security problems in Ubuntu Services as Launchpad, REVU, Forums, website and other community systems.
[03:34] <emgent> The team will also aims to organise the "Ubuntu Hack Day", a day dedicated to hacking tests on the structures of the community with auditing and penetrations tests."
[03:34] <LaserJock> emgent: but is there enough need for a team?
[03:34] <emgent> yep, because now ubuntu-security and motu-swat work only for packages.
[03:34] <LaserJock> seems like encouraging a community infrastructure team that wrote/tested, etc.
[03:35] <emgent> this is a indipendent group (motu-swat branch)
[03:35] <emgent> kees thinks that.
[03:35] <ScottK> Could we pick a different name though.  Us honest hackers would rather that stereotype wasn't furthered.
[03:35] <LaserJock> yeah
[03:35] <emgent> uhm ok np.
[03:35]  * keescook really would like to avoid the "what does 'hacker'" mean situation.  :P
[03:35] <LaserJock> I assumed it was a team *writing*, etc. for Ubuntu infra
[03:36] <emgent> monday kees will talk with infra team and council.
[03:36] <keescook> I would simply like to avoid confusion about the name, though..
[03:36] <emgent> waiting him :P
[03:36] <keescook> I don't have a solution for the name part exactly, but it does seem like people interesting in _finding_ security issues in ubuntu need a place to coordinate
[03:37] <keescook> my initial suggestion is to just make it all motu-swat
[03:37] <LaserJock> hmm
[03:37] <crimsun> that sounds feasible
[03:37] <keescook> since the audience of people interested in helping with security (either through fixes or through finding new issues) is somewhat small, I don't want to arbitrarily segment them up.  :)
[03:37] <emgent> i think branch to motu-swat
[03:38] <keescook> regardless, the entire idea of performing "organized pentesting of Ubuntu infrastructure" needs some level of validation from the IS staff.  :)
[03:39] <crimsun> agreed.  I'm frankly far more interested in app fuzzing.
[03:39] <keescook> solving the details of which team and what name is just a matter of making a judgement call everyone likes.
[03:39] <keescook> crimsun: yeah, I'd love to see more of that too.
[03:39] <LaserJock> crimsun: what is that again?
[03:40] <crimsun> LaserJock: `apt-cache show fuzz` will give you some idea  :-)
[03:40] <emgent> :)
[03:41]  * keescook wants to fuzz the X.org video drivers -- at least one issue in the past has come up in the nvidia driver
[03:41] <emgent> well keescook we will wait your news :P
[03:42] <keescook> emgent: cool.  :)  what do people think of having a recurring meeting for ubuntu security topics too?
[03:42] <keescook> we're starting to have enough different things going on that maybe we should try to coordinate a bit.
[03:42] <emgent> keescook, for me ok
[03:43] <emgent> keescook, date? :)
[03:44] <keescook> emgent: heh, I'm not sure.  perhaps Wed?  I will send email to the ubuntu-devel and ubuntu-hardened mailing lists when I get home tomorrow
[03:44] <emgent> send to me too.
[03:44] <emgent> in 26 and 27 i'm to Siena (Ubuntu italia meeting)
[03:44] <emgent> next week it's perfect
[03:46] <emgent> Wednesday it's ok for me
[03:47]  * keescook nods and crawls to bed for real now
[03:48] <emgent> lol
[03:50] <ScottK> Anyone know why we have octave2.1-forge, but octave2.9-forge was recently removed? - \sh_away?
[03:51] <persia> ScottK: I seem to remember some issue around the etch release that required both packages.  I don't expect we still need octave2.1-forge at this point.
[03:51] <LaserJock> we're gonna remove both 2.1 and 2.9 when 3.0 gets in
[03:51] <ScottK> Cool
[03:52] <ScottK> I'm double checking
[03:52] <ScottK> on \sh_away's affected package list for the transition.
[04:00] <LaserJock> hmm, it's too bad I know next to nothing about security :/
[04:00] <LaserJock> in general I think QA and security to very interesting
[04:00] <LaserJock> *to be
[04:00] <persia> LaserJock: No better way to learn than to help out fixing things.  Reading CVEs can be very informative.
[04:01] <StevenK> Reading CVEs tends to give a nice idea of what *not* to do.
[04:01] <persia> StevenK: Depends on your goal :p
[04:01] <StevenK> Heh
[04:03] <LaserJock> I did read up a bit while working on moodle MIR
[04:04] <LaserJock> it'd really be cool to have a resource for people writing our webapps, etc. to go to to make sure everything's tight
[04:05] <ScottK> Rule 1: No PHP.
[04:05] <emgent> lol
[04:05] <emgent> :)
[04:07] <LaserJock> ah, easier said then done I'm afraid
[04:07] <LaserJock> there are so many goodies in PHP
[04:08] <ScottK> All depends on your priorities.
[04:08] <LaserJock> and what you've got to work with
[04:08] <ScottK> \sh_away: My review is complete.  I found a couple of meta packages that need looking at, I think that was it.  All added to the bug anyway.
[04:09] <ScottK> LaserJock: You've got a lot to work with.  It's FOSS.
[04:09] <LaserJock> well, when it's not my server it's a bit limiting
[04:09] <LaserJock> and when most of the good apps are PHP it's harder :/
[04:10] <LaserJock> but I know what you mean
[04:11] <minghua> ScottK, LaserJock: I suspect octave2.9-forge was removed because it was removed in Debian testing/unstable.
[04:12] <ScottK> That'd make sense.
[04:12] <LaserJock> I am trying to learn Ruby though so I have a bit more in my toolbox
[04:12] <minghua> ScottK, LaserJock: There doesn't seem to be an octave3.0-forge in sight, though.
[04:12] <ScottK> Maybe it's all perfect now that 3.0 is out and no more extra goodies are needed?
[04:12] <minghua> LaserJock: BTW thanks for the mail reminder about \sh_away's work on octave3.0.  I talked with him on IRC.
[04:12] <LaserJock> minghua: ok good, I was afraid maybe I was stepping on toes
[04:13] <LaserJock> I just wanted to make sure everybody was on the same page
[04:13] <persia> There's a semi-automatic removal of anything removed from Debian that doesn't have rdepends or Ubuntu variation.  I thought that was good, but it might also cause this type of issue: anyone have any ideas for noticing?
[04:16] <LaserJock> hi tuxmaniac
[04:16] <crimsun> bug 186095
[04:16] <ubotu> Launchpad bug 186095 in ubuntu "hardware destroyed!" [Undecided,New] https://launchpad.net/bugs/186095
[04:17] <crimsun> brilliant!
[04:17]  * persia fondly remembers the IBM 5150
[04:17] <ScottK> Kewl.
[04:17] <minghua> LaserJock: Yeah, it was good, no toes stepped on.  I talked with \sh_away _after_ getting your commenting on his bug.
[04:20] <tuxmaniac> LaserJock,
[04:20] <tuxmaniac> LaserJock, can you please review http://revu.tauware.de/details.py?package=alliance . I have been advertising from yesterday :-(
[04:21] <bddebian> tuxmaniac: I'm trying but I have a full disk :(
[04:21] <tuxmaniac> bddebian, oh you are still around. :D
[04:21] <tuxmaniac> bddebian, its morning in India already :-)
[04:26] <bddebian> OK, I have this: in a rules file that works on the command line but gives missing '))' on build.  Any clues??
[04:26] <bddebian>         echo Ion:ApiVersion=$$((cat /usr/include/ion3/version.h; echo ION_API_VE
[04:26] <bddebian> RSION) \
[04:26] <bddebian>                 | cpp -P | tail -1 | sed 's/"//g') >>debian/mod-xinerama-for-ion
[04:26] <bddebian> .substvars
[04:26] <bddebian> Gah, sorry, bad pase
[04:27] <persia> bddebian: Didn't we drop ion3 for licensing reasons?
[04:27] <bddebian> Seems to be back afaict
[04:27] <bddebian> Debian has a 20080103 or so version
[04:28] <tuxmaniac> aah looks like \sh_away  has been going bizzerk with octave3.0 sync. Great to see and hope it gets into hardy! A wonderful milestone it shall be.
[04:28] <persia> bddebian: My understanding is that the license for io3 requires distribution of the latest snapshot, which we can't support.  Debian has it, but only because they have an RC bug preventing it reaching lenny.  Ubuntu has no such mechanism.
[04:28] <persia> s/io3/ion3/
[04:28] <bddebian> Ahhh
[04:28]  * bddebian thinks persia knows everything
[04:29]  * persia is certain that is a false statement, and is willing to provide mathematical proofs
[04:29] <bddebian> Now go fix survex for me ;-P
[04:29]  * persia cringes
[04:33]  * persia wonders if there are any spelunkers about
[04:36] <bddebian> Not me :)
[04:39] <RAOF> Oooh, looks pypy has finished locking my box :)
[04:45] <bddebian> Is there one of the texlive psuedo packages that installs the texlive-lang-* packages or do I need to build-dep on each texlive-lang-<language> ?
[04:47] <bddebian> Ah, texlive-common?
[04:48] <LaserJock> well, texlive-lang-all
[04:52] <LucidFox> Is there any way I can see which package versions a particular Hardy alpha contained?
[04:54] <persia> LucidFox: Your best chance is to download the CD, but many users call something "Alpha 2" when they have been doing daily updates.
[04:59] <minghua> And the alpha-2 label means nothing for universe anyway.
[05:27] <RAOF> Lack of copyright headers in source files isn't grounds for rejection from NEW, as long as there's a statement that the software is licensed under the GPL, right?
[05:30] <jdong> RAOF: I believe in that case ~ubuntu-archive would *like* you to make sure of the terms of the license of the headers, but right, it's not deathly necessary
[05:30] <jdong> and not, IMO, cause for rejection
[05:30] <jdong> though of course I'd be the worst, most liberal archive admin in the world
[05:31] <persia> RAOF: Depends on the archive admin.  There have been several rejections for that.  Ask upstream to follow the instructions in the GPL about how to apply the GPL to their source first, and only push to the archive admins if upstream won't fix it.
[05:32] <RAOF> Right.
[05:35] <desertc> If I wanted to get involved with the MOTU team, then would I need to set up a separate partition or make sweeping changes to my desktop system?  I have been reading the MOTU documents, but I am still unclear what would be the physical requirements.
[05:36] <persia> desertc: There are no physical requirements.
[05:36] <RAOF> No, not really.  There are a variety of tools for building packages in a clean system without actually having a clean system :)
[05:37] <persia> It is strongly recommended that you set up either pbuilder or sbuild.  pbuilder seems to want a fairly large /tmp, and sbuild wants it's own partition area (I set aside 19.99 GB for sbuild).
[05:39] <ScottK> RAOF: There also has to be a full copy of the license in the tarball.
[05:39] <tuxmaniac> desertc, I personally feel pbuilder is better for a start. Since I am also in the beginning stages.
[05:39] <desertc> I see.  Good to know.  Setting up a partition would not be a big deal.  I can always add another hard drive via USB.  I just was picturing having to have 09.04 configured or something.
[05:39] <desertc> um 08.04  :)
[05:39] <RAOF> ScottK: Yeah, it's got a copy of the GPLv2 in there, and it says that it's GPLv2 licensed.  It's just that none of the source files have any copyright attribution at all.
[05:40] <persia> desertc: Nope.  There are MOTU who run Dapper or even Debian.
[05:40] <tuxmaniac> desertc, though I have not tried sbuild, pbuilder is a breeze to get started.
[05:40] <ScottK> RAOF: You're probably OK then
[05:40] <desertc> I will take a look at pbuilder and idle here.  Hope to get a handle on how to help soon.
[05:40] <persia> RAOF: copyright attribution is different than licensing.  It is acceptable for the collective work to be under a collective copyright (although discouraged), but doing that doesn't match the instructions in the GPL for licensing.
[05:41] <ScottK> desertc: My main desktop is still dapper.  I've got servers on Gutsy and (until tomorrow - the last one dies - Feist), a Gutsy laptop and an Edgy install on my wife's laptop.
[05:41] <persia> desertc: What interests you?  A common way to get started is to look at problems with software you use or like, and try to get them resolved.
[05:41] <RAOF> ScottK: Wanna help me close the ITP, then? :)
[05:41] <ScottK> RAOF: It's late and I'm going to bed.
[05:41] <ScottK> Good night all.
[05:41] <RAOF> Fair enough.  Sleep well!
[05:42] <bddebian> Gnight ScottK
[05:43] <tuxmaniac> desertc, most of the info you might need are there here https://wiki.ubuntu.com/PbuilderHowto with respect to pbuilder
[05:43] <desertc> tuxmaniac: thanks for the link :)
[05:44]  * persia notes that the official buildds run sbuild, and points at https://help.ubuntu.com/community/SbuildLVMHowto
[05:45] <tuxmaniac> persia, thanks. I think I shall try that out on my home machine.
[05:45] <desertc> How much space (est) does pbuilder require?
[05:45]  * RAOF notes that sbuild-on-lvm can also be quite a lot faster than pbuilder. 
[05:45] <desertc> or sbuild
[05:45] <persia> desertc: Lots less.  Something like 50MB per chroot tarball.
[05:46] <RAOF> And then a variable ammount of space while building.
[05:46] <persia> Err.  pbuild requires lots less.  sbuild-on-lvm requires 4-5GB per chroot + 4-5GB per simultaneous build.
[05:47] <desertc> Is sbuild is recreating the environment of the entire OS?  And pbuilder is just for the individual package?
[05:47] <desertc> (taking a guess here)
[05:48] <RAOF> They're both doing the same thing, but different technical means.
[05:48] <persia> Similar things.  They are only about as close as apt-get and aptitude.  Each has a few unique features, and the codebases are different.
[05:48] <RAOF> pbuilder creates a minimal ubuntu system then tars it up.  Each time it builds, it unpacks that tarball under /tmp and then chroots into it.
[05:50] <RAOF> sbuild-on-lvm has a separate lvm logical volume containing the minimal system, then uses snapshots to build in.  The reason why each lv has to be big is so that you've got enough space to install the build-dependencies & build the package.
[05:50] <desertc> hmm!  thanks for the explanation!
[05:51] <persia> If you choose pbuilder, be sure to either have a fair amount of space available on /tmp, or if using tmpfs, a large swap partition.
[05:52] <tuxmaniac> can I have two pbuilder chroot tar? since I am on a limited bandwidth, its not simple to clean up everytime I build a different package. I mean two pbuilder ch tar for the same dist?
[05:53] <RAOF> You should be able to have a local apt cache, which will do what you want.
[05:53] <RAOF> I forget if pbuilder is set up to do that out of the box.
[05:53] <persia> tuxmaniac: Both pbuilder and sbuild clean up after each build.  You want a local mirror (or cache) to not download everything with each build.
[05:54] <minghua> That would be --aptcache option, or APTCACHE variable in pbuilderrc.
[05:55] <desertc> I have a CS background, but I've not put any of it to use since college.  I was thinking I might like to start working toward programming linux code, and I thought this might be a good way to get started on that path.  I also have work training in QA, so I think I can be pretty handy.
[05:56] <desertc> Most importantly, I have a lot of control over my time these days, which is awesome.  :)
[05:56] <RAOF> There's really not that much programming involved in MOTU work.
[05:56] <persia> desertc: MOTU only very rarely actually touches the linux package :)
[05:56] <RAOF> At least, the actual *packaging* part.
[05:56] <desertc> It will help me work toward it, by giving me a better understanding of the Ubuntu system.
[05:56] <persia> RAOF: Depends.  There can be for bugfixing, or library porting (and we can always use more library porters)
[05:56] <RAOF> The bug finding/fixing, yes.
[05:57] <desertc> You don't want me programming anything right now anyway.  I probably would have trouble with helloworld() at this point.
[05:57] <RAOF> In that case, bugfixing may well be a nice gentle reintroduction :)
[05:58] <tuxmaniac> desertc, I get memory leaks with my hello world sometimes
[05:58] <tuxmaniac> :D
[05:58] <desertc> :)  I was leading QA efforts for a popular open source project a short while ago, and I am burnt out from dealing with developers.  ;)
[06:00] <desertc> All features and no bug fixes.  Made me understand the importance of groups that hold the projects together at a high level, like the Ubuntu Project.  :)
[06:01] <desertc> Or did you mean actually making the programmatic changes myself, RAOF?  Hmm!  Interesting idea.
[06:01] <desertc> Okay, sorry to take over the conversation, I'll keep looking at pbuilder and sbuild.
[06:01] <RAOF> desertc: Oh, yes.  Making the changes yourself.
[06:02] <RAOF> It's quite a different skill to be able to dive into some totally unfamiliar code and find the bug :)
[06:06] <RAOF> Anyone want to close an ITP? http://tinyurl.com/2249zg for the DDs among us.
[06:06] <persia> RAOF: What does it break?  Should it really be priority "extra"?
[06:07]  * persia is not a DD, but picky about priority extra
[06:08]  * RAOF *always* forgets priority :(
[06:08] <RAOF> Thanks.
[06:09] <desertc> Okay - this will sound a bit noobish, but what does an Ubuntu programmer program?  Aren't Ubuntu packages derived from Debian, for the most part?
[06:09] <desertc> I suppose there is the installation and the upgrade software..
[06:09] <persia> desertc: It's mostly maintenance coding.  Looking through code from upstream or from Debian and fixing bugs or improving integration.
[06:09] <desertc> Ah, gotcha.  Thanks
[06:10] <persia> Most fixes end up being patches that go to Debian or to Upstream, and are dropped in the next release.
[06:12] <desertc> In MOTU work, you do a bit of compiling with the package source, right?
[06:13] <desertc> sorry - I should read and not keep asking questions that I can find myself  :-)
[07:02]  * RAOF hit's miro again, in the hope that it'll work if you give it a kick.
[07:02]  * RAOF is taken away by the society against cruelty to apostrophes.
[07:03]  * persia hands RAOF a white coat and a clipboard as defence against arbitrary societies
[07:06]  * Hobbsee hides in the white padded room, to avoid wor
[07:06] <Hobbsee> k
[07:07]  * persia hands Hobbsee a white jacket with long sleeves and extra straps
[07:08]  * Hobbsee gets out her whip
[07:08] <Hobbsee> woe betide anyone who decides to do *anything* stuipd tonight.
[07:12] <persia> !channels
[07:12] <ubotu> A list of official Ubuntu IRC channels, as well as IRC clients for Ubuntu, can be found at https://help.ubuntu.com/community/InternetRelayChat - For a general list of !freenode channels, see http://freenode.net/faq.shtml#channellist - See also !Guidelines
[07:51] <persia> tjaalton: Re: the java X bug.  Is it confirmed fixed for gcj & icedtea?
[07:52] <StevenK> Hmph.
[07:53] <StevenK> cln jumped from using cln-config to using pkg-config.
[08:02]  * persia wonders if anyone ever grabbed the first 38 libldap rdepends
[08:04] <StevenK> persia: I thought you had 19 of them?
[08:05] <persia> StevenK: I did 19, and you did 19, but I thought there were 78 or so in total.  Do I misremember?
[08:05] <StevenK> persia: For universe it was only 58 or so
[08:05] <StevenK> I have 2 left, I think
[08:06] <persia> I have 3 that didn't work smoothly.  I was just considering pushing the simple cases in "" - haskel if nobody else had yet.
[08:11] <jonnymind> Hello all
[08:14] <RAOF> Miro taunts me with new boost dependencies.  I shall set it on fire!
[08:22] <RAOF> How many libtorrents are there?
[08:28] <persia> RAOF: I think there should only be three
[08:29] <RAOF> Ah.  Which one is Miro embedding now...
[08:33] <tjaalton> persia: I'm not sure, haven't tried myself
[08:35] <persia> tjaalton: I'm just wondering if it's only a hypothetical closure.  I haven't encountered the issue, but it would be unfortunate if it still existed for new hardy installs using icedtea.
[08:35] <persia> (or openJDK, but I don't expect that to be ready for hardy)
[08:36] <RAOF> Right. It's not the libtorrent that we have in our archives, anyway.
[08:42] <tjaalton> persia: the upstream bug says that it's fixed, but doesn't mention the version
[08:43] <persia> tjaalton: Hmmm.  I don't expect our X to need any further modification, but just wondered if our Java did.  Maybe all is good (and maybe soon we can drop the sun java blobs)
[08:43] <tjaalton> we can't touch them, so it just needs to be mentioned on the release notes..
[08:44] <persia> tjaalton: We can't touch the sun-* blobs, but we can touch icedtea, which is why I mention it at all.
[08:44] <tjaalton> oh right
[08:44] <persia> Most things that work with sun-* should work with icedtea, and we should be patching icedtea like anything else in universe to demonstrate good practice, and encourage more open java.
[08:45] <tjaalton> I believe it's fixed there already, someone just needs to test it :)
[08:49] <RAOF> Accursed script kiddies!  Stop hitting my password-disabled ssh server, damn you!
[08:54] <persia> tjaalton: Do you have any good test case?  Testing first against gcj, I don't seem to have a jconsole binary, and don't understand fcitx well enough to be comfortable breaking my scim.
[08:54] <tjaalton> try eclipse
[08:55] <tjaalton> first check that /etc/eclipse/java_home has gcj/icedtea on top
[08:57] <persia> tjaalton: I don't have any Sun-* installed.  Shouldn't it do the right thing without any conffile mangling?
[08:57]  * minghua is awaken by the mentioning of scim.
[08:57] <tjaalton> persia: yep
[08:58] <persia> minghua: We're discussing bug #87947.  Not really a scim thing.
[08:58] <ubotu> Launchpad bug 87947 in libx11 "xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed." [Medium,Fix released] https://launchpad.net/bugs/87947
[08:58] <persia> it's just that one of the test cases uses fcitx
[08:58] <minghua> Heh, xcb issues.
[08:59] <persia> tjaalton: If the bug exists, eclipse should crash on first run?
[08:59]  * persia tries installing Sun Java to see if it breaks eclipse
[08:59] <minghua> persia, tjaalton: I don't think 87947 is in any way related to input methods.
[09:00] <tjaalton> persia: I think so..
[09:00] <persia> minghua: I agree.  It's just that I didn't want to mess with my scim configuration, so wanted another test case
[09:01] <minghua> persia, tjaalton: Sun Java is known to be (or have been) broken with xcb.  Old Xorg used to have problem with xcb for input methods, but as the bug states, it has been fixed.
[09:01] <tjaalton> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6532373
[09:01] <tjaalton> that's the upstream bug
[09:01] <tjaalton> gone ->
[09:02] <minghua> Actually, scim used to break with xcb as well.
[09:02] <persia> tjaalton: eclipse doesn't seem to show it either with or without sun-java.
[09:02]  * minghua once got a bug about this, but Xorg maintainers took it back after a few days and eventually fixed it.
[09:04] <persia> minghua: Does icedtea fix the problem with sun java?  I've never encountered the bug, and so have a hard time testing to see if it is fixed.
[09:05]  * persia doesn't like telling users "it's a problem with non-free software" when there is a free software replacement available.
[09:05] <minghua> persia: I've never encountered it either.
[09:05] <persia> tjaalton: Could you please find a test case, and verify whether it was fixed or not?  I'm happy to help test.
[09:05] <minghua> So hardy has xcb enabled now?  I didn't notice any difference.
[09:11] <persia> Does anyone know why python-profiler is in multiverse?
[09:12] <RAOF> There's a licensing issue in linking gpl code with openssl, isn't there?  Do I remember that correctly?
[09:13]  * minghua hopes not.
[09:13] <minghua> GPL code linked with openSSL is downright non-distributable.
[09:14] <persia> RAOF: The GPL code needs to offer a specific exception to allow linking against OpenSSL, if I remember correctly.
[09:14] <RAOF> Yes, that was what I was afraid of.
[09:14] <RAOF> Well, it seems miro is now undistributable.
[09:17] <persia> RAOF: You could patch it to not link against SSL for now.  It's not a problem to distribute source.
[09:17] <minghua> persia: Non-DFSG-free restrictions for the python-profiler case, it seems: http://mail.python.org/pipermail/python-dev/2005-February/051450.html
[09:18] <persia> minghua: OK.  That makes sense.  Thanks.
[09:18]  * persia is trying to reduce multiverse usage
[09:55] <persia> Anyone have any hints for injecting a local package into an sbuild session?
[09:56] <azeem> persia: sbuild takes .dsc files
[09:57] <azeem> persia: or what do you mean with injecting?  Installing it in the chroot rather than building it?
[09:57] <persia> azeem: Right.  I have two packages.  One build-depends on the other.  I could use a local archive of a PPA, but would like to just be able to tell sbuild I want this specific local package also installed in the chroot.
[09:57] <azeem> ah
[09:57] <persia> s/of a PPA/or a PPA/
[09:57] <azeem> that's not so trivial I think, yeah
[09:57] <azeem> I usually install it manually in the chroot
[09:57] <persia> azeem: In the base chroot?  Doesn't that affect your future builds?
[09:58] <azeem> well, and try to remember to remove it again afterwards ;)
[09:58] <azeem> deborphan is good for that
[09:58] <azeem> hrm
[09:58] <persia> azeem: install/purge cycles are supposed to be clean, but aren't always :(  Be careful with that.
[09:59] <azeem> persia: well ok, but it's no different to installing any other build-depens, that can potentionally happen all the time
[09:59] <persia> azeem: Depends on how you use sbuild.  I always use it in a snapshot LVM volume, which I discard after each build.
[10:01] <minghua> persia: Can't you login into your LVM snapshot chroot then?
[10:01] <persia> minghua: That's my workaround for now, but as I'm setup to discard chroots after use, I end up using debuild, which doesn't keep the logs in the same place.  I was hoping for something simple (and should probably be using a local archive)
[10:03] <azeem> yeah, I guess a local archive is the easiest then
[10:03] <persia> Well, a PPA is easier, but the latency from here to there makes downloading annoying.
[10:04] <minghua> persia: Make a PPA mirror! :-)
[10:05] <persia> minghua: Now there's an idea I never imagined promoted.
[10:16] <superm1> folks i've got a small app up for revu if someone else would like to take a glance: http://revu.tauware.de/details.py?package=project-x
[10:21] <jonnymind> Hello ppl; I have cleared the last stoppers from pochu on http://revu.tauware.de/details.py?package=falconpl
[10:22] <jonnymind> I think it should be clean now. Is there someone willing to have a look?
[11:08] <Coper> Hi can a REVU admin resync REVU uploaders keyring?
[11:09] <persia> Coper: starting now.  Takes about 20 minutes.
[11:09] <Coper> persia: okej, thanks
[11:12] <habit_> Hello. I am newbie. Can somebody teach me how to make packages (allready done with google, with ubuntu links). Just advice me how to solve some troubles.
[11:12] <habit_> ?
[11:13] <azeem> habit_: describe your troubles, and maybe somebody will be able to help you
[11:17] <habit_> I have done with dependencies, with dev packages needed for compilation, so, 'make' works fine and create binaries. 2nd step I have opened ubuntu packaging manual. At the begining as I understood I need to do 'dpgk -x source_tarball.tar.gz
[11:18] <habit_> Oups, mistake, dpkg-source -x
[11:18] <persia> habit_: That's not quite how I'd start.
[11:19] <persia> If you have a working upstream that compiles from source, the first step is usually tar xzf upstream-tarball
[11:19] <habit_> But dpkg-source returns an error.
[11:19] <azeem> dpkg-source acts on Debian source archives, not random upstream tarballs
[11:21] <persia> Then, move the upstream tarball to $(package)_$(version).orig.tar.gz and change the directory name to $(package)-$(version).  Create a "debian" directory in the new working directory, and add your control, copyright, and rules file.  Step down one directory, and create your copyright file with dch.
[11:21] <persia> At this point, `debuild -S -sa` should generate you a source package, which you could later use with dpkg-source -x
[11:23] <habit_> One question - i didn't understood what actually I must do with 'tar xzf'
[11:23] <persia> habit_: Unpack the upstream tarball
[11:26] <habit_> Guys, I'm sorry for maybe very stupid questions, but I'm totally newbie with computers :) So 1. I must unpack sources, create there 'debian' directory with needed description files and then I must run @ that directory (root unpacked sources directory I mean) 'debuild -S -sa'
[11:26] <habit_> Right?
[11:27] <persia> habit_: Yes.  You also have to make sure to rename the upstream tarball and unpack directory.
[11:28] <habit_> persia, the renaming is for later making "right-way tarball"? So I can just delete original tarball?
[11:28] <habit_> Now I have wired-0.6  wired_0.6.orig.tar.gz  wired_0.6.tar.gz directory and files.
[11:29] <persia> habit_: No.  debuild expects you to be in a directory named $(package)-$(version), and may behave oddly if you are not.  It also expects the upstream tarball to be in the parent directory and named $(package)_$(version).orig.tar.gz, and will likely be unable to build a source package if it is missing (or may build a native package, but that isn't what you want).
[11:30] <persia> Ah.  Yes.  You want wired-0.6 and wired_0.6.orig.tar.gz.  You don't need wired_0.6.tar.gz
[11:31] <habit_> What files I must put into DEBIAN folder?
[11:32] <persia> That is part of the binary package, and will be generated from the contents of the debian/ directory in the source package.
[11:33] <habit_> Now I have wired_0.6  wired_0.6.orig.tar.gz . Wired_0.6 - is unpacked wired_0.6.orig.tar.gz, but with debian folder into them.
[11:33] <habit_> Right?
[11:35] <persia> habit_: Right.  When you make the source, you will also get wired_0.6-0ubuntu1.diff.gz and wired_0.6-0ubuntu1.dsc.
[11:36] <habit_> Make the source mean 'cd wired_0.6 && debuild -S -sa'
[11:36] <habit_> ?
[11:37] <persia> habit_: You might want to run `dget http://launchpadlibrarian.net/10123377/wired_0.5.1%2Bdfsg2-0tsmithe3.dsc` to see previous packaging work on wired, and contact Toby to collaborate.
[11:37] <persia> habit_: Yes.  That would be making the source.
[11:37] <habit_> One more question. What files must contain DEBIAN directory?
[11:38] <habit_> AH, sorry )
[11:38] <habit_> Just saw your link.
[11:39] <persia> habit_: Note that wired is a fairly complex package, as it incorporates all of a library, an application, and some plugins.  You might want to try packaging something simpler to become familiar with the process first.
[11:40] <habit_> Actually I think I will not familiar never with it :)
[11:40] <habit_> As I think that it for "power users" and developers.
[11:40] <habit_> I am only normal user..
[11:40] <habit_> Whatewer )
[11:45] <habit_> persia, cannot find toby's contact. dget doesn't work also.
[11:45] <habit_> How I can search it?
[11:45] <vorian> habit_: check the changelog
[11:46] <persia> Grr.  I thought dget was supposed to work with launchpad now :(
[11:46] <vorian> woops
[11:47] <persia> habit_: dget http://ppa.launchpad.net/tsmithe/ubuntu/pool/universe/w/wired/wired_0.5.1+dfsg2-0tsmithe3.dsc
[11:48] <habit_> Now I must make debian folder like @ that file and do 'cd wired_0.6 && debuild -S -sa' yep?
[11:48] <habit_> I think I'm really annoing :(
[11:48] <habit_> But if I will take it once, I'll help next newbie :)
[11:49] <persia> habit_: https://wiki.ubuntu.com/PackagingGuide/Recipes/PackageUpdate may be helpful
[11:51] <rzr> persia: BTW, debian policy suggests now to use '~' in version names
[11:52] <persia> rzr: In what context?  ~ has been supported for a while.  Is there a new update to policy including that?  Are they now supposd to be used more often?
[11:53] <rzr> I saw that days ago in /usr/share/doc/debian-policy/changelog.gz
[11:53] <rzr> * Bug fix: "[PROPOSAL] Document ~ behavior in version numbers", thanks
[11:53] <rzr>     to Nicolas FranÃ§ois and Marc Brockschmidt                (Closes: #382612).
[11:54] <broonie> It's just an update to policy to reflect existing usage of ~.
[11:54] <persia> rzr: Right.  '~' has been there for a while.  3.7.3.0 finally included documentation of this behaviour.  Next question: did I tell you something this contradicts?
[11:55] <Coper> persia: I have still problems with getting a email with my password in REVU.
[11:55] <persia> Coper: REVU doesn't send emails with passwords.  Have you uploaded anything?
[11:56] <rzr> persia: i dont think so  this makes me think we you pasted the wired dsc
[11:56] <Coper> Yes I think everything is uploaded.
[11:57] <persia> rzr: Ah.  Yes.  That package wasn't ready for the archives.  I just thought it would be a good reference for habit when trying to start out, as it at least included the package split correctly, and handled a lot of the DFSG removals.
[11:57] <persia> (and was the same upstream)
[12:00] <Coper> When I try to recover password for my email, REVU says that there is no account. And my fil is not listed on the site.
[12:01] <persia> Coper: Which package did you upload?
[12:01] <Coper> console-freecell
[12:02] <persia> smater: dcut doesn't work on REVU.  Just wait 10 minutes and upload again.
[12:03] <persia> Coper: Get your password from http://revu.ubuntuwire.com/lostpw.py?email=lars@dunemark.se and look at your package from http://revu.ubuntuwire.com/details.py?package=console-freecell
[12:05] <StevenK> dcut is a Debian-ism
[12:05] <StevenK> It doesn't work for Ubuntu either
[12:06] <persia> StevenK: Maybe someone could patch dput to not tell the user to use it?
[12:06] <StevenK> persia: Maybe one could use it to sharpen their Python skills? :-)
[12:07]  * persia goes to look at dput...
[12:07]  * StevenK chuckles
[12:07] <StevenK> persia: I've got patches in dput, so if you want to run stuff past me, sure
[12:07] <Coper> persia: okej, the problem was that I was looking at http://revu.tauware.de/
[12:07] <persia> Coper: Same site.  Same code.  Different name.
[12:07] <persia> (same data too)
[12:07] <Coper> okej..
[12:08] <persia> Coper: The run only happens 5 times an hour or so.  You likely cheked just before the run, and I just after.
[12:14] <persia> Does dcut work on mentors.debian.org?
[12:15] <StevenK> Good question. I have no idea.
[12:15]  * persia decides to only block on "ubuntu", "revu", "local", and "ppa" for now.
[12:22]  * persia decides understanding python is a morning activity
[12:26] <smarter> hi there
[12:27] <smarter> could someone please review my packages? http://revu.ubuntuwire.com/details.py?package=extremetuxracer and http://revu.ubuntuwire.com/details.py?package=kde4-style-bespin
[12:45] <Coper> How do I create a binary package from my dsc file if I want to add it to my ppa repos?
[12:52] <effie_jayx> Coper, you must build it
[12:52] <rulus> Coper: just upload the source package, it gets build by Launchpad's build daemons (PPA support in #launchpad btw)
[12:53] <effie_jayx> rulus,  wow :O
[12:53] <rulus> If I'm wrong, please tell :p
[12:54] <Coper> so it's just to wait then. :)
[12:57] <rzr> man dget
[12:57] <rzr> man dput
[13:00] <civija> DktrKranz: could you please review this and let me know do you need any more info about this https://bugs.launchpad.net/bugs/184261? TIA
[13:00] <ubotu> Launchpad bug 184261 in slrnface "slrnface doesn't display X-Face header" [Undecided,In progress]
[13:02] <DktrKranz> civija, thanks for the pointer, I forget to check, I'll look at it now :)
[13:02] <civija> ok :)
[13:03] <DktrKranz> probably, I'll need your help to setup something, though
[13:03] <civija> just let me know
[13:44] <DktrKranz> civija, ok. I've got slrn up and running (or at least I think so), could you point me to a newsgroup with some discussion with X-Face headers in?
[13:45] <civija> DktrKranz: subscribe to group news.software.readers
[13:46] <DktrKranz> civija, mh, I've got news.software.misc, no .readers... I think I need to switch server
[13:47] <civija> DktrKranz: do you have alt.test?
[13:47] <DktrKranz> No
[13:47] <civija> jeez :)
[13:47] <DktrKranz> :)
[13:48] <mok0> What do you do if upstreams package comes in two archives, and you want to make one source package? Is there a smart way of dealing with this, without repackaging and merging?
[13:48] <DktrKranz> civija, which NNTP server are you using? If it is free, I can connect to it
[13:49] <civija> DktrKranz: i'm using my isp news server which allows access only for ip's from my country
[13:49] <civija> DktrKranz: wait, i'll find something
[13:49] <civija> server or newsgroup or ...
[13:50] <DktrKranz> civija, do they provide some exceptions from their neighbours? I'm not far away from you :)
[13:50] <civija> DktrKranz: only if you are their user :)
[13:50] <civija> DktrKranz: btw: where are you from? :)
[13:51] <DktrKranz> Italy
[13:51] <civija> hehe, cool :)
[13:51] <jdong> ha this is so sweet....
[13:51] <jdong> using a 37" LCD HDTV as a terminal :)
[13:51]  * jdong runs a matrix screensaver and pretends to do work
[13:52] <geser> jdong: which resolution?
[13:52] <civija> DktrKranz: do you have any test group on your server? i.e. it.test or something else ...
[13:52] <jdong> geser: it's a cheapie, 1024x768 currently, it's only 1080i
[13:53] <jdong> geser: was only recently able to obtain an HDMI cable at a price I felt was fair; before this TV was used as... um.... furniture? visual decoraton?
[13:54] <DktrKranz> civija, is there a quick way to sort or find them? They don't seem to be sorted
[13:54] <civija> DktrKranz: try shift-l
[13:55] <DktrKranz> civija, nervermind, I found use of backslash, and I found news.software.readers too
[13:55] <civija> DktrKranz: ok :)
[13:56] <civija> DktrKranz: wait i'll found some article on news.software.readers that has x-face in it
[13:56] <DktrKranz> good
[13:56] <DktrKranz> in the meantime, I'll test build slrnface with your patch in
[13:59] <mok0> Is there a policy on how to repackage if you fetch stuff from CVS?
[14:04] <civija> DktrKranz: open news.software.readers, you see thread with subject: [Leafnode] & [slrn] page: Comments?
[14:04] <civija> do you*
[14:06] <DktrKranz> civija, I see only 67 threads, and yours is not between them. Is there a way to expand buffer?
[14:06] <rexbron> Hey everyone! I am looking for a review of a small C library called openFX. http://revu.ubuntuwire.com/details.py?package=libopenfx
[14:07] <civija> DktrKranz: ok, nevermind
[14:07] <DktrKranz> civija, found!
[14:07] <civija> hehe :)
[14:08] <civija> DktrKranz: dou you see author named mike yetto in that thread?
[14:08] <DktrKranz> Yes
[14:09] <civija> ok, he has x-face
[14:09] <civija> when you open that article if slrnface works it should display a little picture on your screen
[14:09] <civija> top left corned by default
[14:09] <civija> corner*
[14:10] <civija> top right, sorry :)
[14:10] <civija> DktrKranz: does it display anything?
[14:10] <DktrKranz> No picture at all, just a black square
[14:11] <civija> ok, wait i'll just check something
[14:12] <civija> DktrKranz: black square size about 48x48 px?
[14:13] <DktrKranz> so it seems
[14:13] <civija> can you move that square around the screen? left click and hold
[14:14] <DktrKranz> I got a face now
[14:15] <civija> how?
[14:15] <civija> what did you do?
[14:16] <DktrKranz> Nothing relevant, just followed your instructions
[14:16] <civija> DktrKranz: ok
[14:16] <civija> DktrKranz: it seems that it works for you without a patch
[14:17] <civija> are you using hardy?
[14:17] <DktrKranz> yes
[14:17] <civija> ok
[14:17] <DktrKranz> I'll post a screenshot
[14:21] <DktrKranz> civija, http://img104.imageshack.us/img104/1025/slrnsj2.png
[14:22] <civija> DktrKranz: yep, that's it
[14:23] <DktrKranz> do you want me to test on gutsy too?
[14:23] <civija> DktrKranz: i would be most gracefull :)
[14:23] <civija> if it isn't too much trouble for you
[14:24] <DktrKranz> absolutely not
[14:26] <DktrKranz> civija, for your reference, I found thread you showed in your bug report, and I'm able to see shark in my first try
[14:26] <DktrKranz> now, let's try guysy
[14:26] <DktrKranz> *gutsy
[14:27] <civija> DktrKranz: ok, tnx
[14:31] <DktrKranz> civija, gutsy works well too... I keep compiz off.
[14:32] <civija> DktrKranz: thank you very much for you help
[14:33] <DktrKranz> you're welcome :)
[14:33] <civija> it seems that problem is somewhere else then
[14:33] <DktrKranz> I guess so
[14:33] <civija> i'll look into it more :)
[14:35] <DktrKranz> Is it ok for you to unsubscribe u-u-s?
[14:38] <civija> DktrKranz: yes, but i can't unscribe them only myself
[14:38] <civija> unsubscribe*
[14:38] <DktrKranz> I'll do it now.
[14:39] <civija> ok, tnx
[14:39] <DktrKranz> Try to look into .slrnfaces directory in your home if there's some pipe in when displaying faces
[14:40] <DktrKranz> as suggested by README
[14:40] <civija> will do
[14:43] <Coper> I have some problem with my package that I don't get any binary inluded in my package.
[14:44] <Coper> I get all README files and that shoudl be added to /usr/share/doc/... but no files are copyed to /usr/bin.
[14:48] <DktrKranz> Coper, do you use debhelper or cdbs?
[14:48] <Coper> debhelper
[14:48] <ion_> cdbs uses debhelper
[14:49] <DktrKranz> Coper, do you use dh_install (and associated files) or invoke install in your rules?
[14:50] <Coper> in binary-arch: build install  there is a # before dh_install
[14:51] <Coper> and no dh_install in the install: section.
[14:51] <StevenK> ion_: CDBS doesn't have to use debhelper.
[14:51] <DktrKranz> Coper, it seems your rules lacks some install routine, could you please show us in pastebin?
[14:51] <DktrKranz> !paste
[14:51] <ubotu> pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic)
[14:52] <ion_> stevenk: True indeed. I’ve just never seen anyone using CDBS without using debhelper. :-)
[14:53] <Coper> http://paste.ubuntu-nl.org/53562/ <- There is my rules file.
[14:55] <bddebian> Heya gang
[14:55] <DktrKranz> Coper, it seems "$(MAKE) DESTDIR=$(CURDIR)/debian/freecell install" does not work properly
[14:57] <Coper> DktrKranz: should it point to the binary that should be installed?
[14:57] <Coper> example $CURDIR/src/freecell
[14:58] <tjaalton> persia: ok I'll try to find a test case
[14:59] <DktrKranz> Coper, DESTDIR is fine
[15:10] <shibata> Hi, all.
[15:10] <shibata> I would like to create package of poppler-data.
[15:11] <shibata> This package include adobe cmap files which need to display CJK fonts in PDF.
[15:13] <shibata> License of cmap files is Redistribution is OK, "altered" is NG. Probably, "altered" mean "modify".
[15:13] <shibata> Should I upload it into multiverse?
[15:15] <shibata> If so, can I upload revu in the same way as universe package?
[15:23] <civija> DktrKranz: can I close LP #184261 or you have to do that?
[15:23] <ubotu> Launchpad bug 184261 in slrnface "slrnface doesn't display X-Face header" [Low,In progress] https://launchpad.net/bugs/184261
[15:24] <DktrKranz> civija, you can close it, if you think everything is fine now.
[15:24] <DktrKranz> thanks for investigating :)
[15:24] <civija> DktrKranz: ok, is there anywhere close link or something? :)
[15:25] <DktrKranz> just set status to Invalid
[15:25] <civija> ok, tnx
[15:25] <DktrKranz> you're welcome
[15:28] <hellboy195> Also Debian folks are lazy at documenting changes -.-
[15:34] <hellboy195> hoi DarkSun88 :)
[15:35] <DarkSun88> Hi hellboy195
[15:42] <hellboy195> ahoi jono :)
[15:43] <Hobbsee> oh noes, it's jono!
[15:44]  * jdong pings jono too because it seems to be a fad :)
[15:44] <jono> hey folks
[15:44] <jono> :)
[15:45]  * ion_ performs a man-in-the-middle attack when jdong pings jono
[15:45] <jono> hehe
[15:46] <DktrKranz> hellboy195, in bug 186035, it seems Debian fixed something which Ubuntu managed in edgy with 1.99.16-8.1ubuntu3, is is worth merge it?
[15:46] <ubotu> Launchpad bug 186035 in oleo "Merge oleo  1.99.16-10 from Debian(Unstable)" [Wishlist,In progress] https://launchpad.net/bugs/186035
[15:46] <hellboy195> DktrKranz: I was very unsecure with that merge. I'll check it later again
[15:47] <DktrKranz> hellboy195, thanks. Also, since you dropped some changes, could you explain why?
[15:48] <hellboy195> DktrKranz: if you have time would you mind telling me what's exactly false? Maybe I only forgot some ... :/
[15:52] <DktrKranz> hellboy195, I'll be back in about an hour, will you be there, so we can look at it?
[15:52] <hellboy195> DktrKranz: sure :) thx
[15:52] <DktrKranz> c u later then :(
[15:53] <DktrKranz> erm.. wrong smiley
[15:53] <DktrKranz> :)
[15:53] <hellboy195> ah
[15:53] <hellboy195> ^^
[15:53] <hellboy195> k, cya
[16:16] <hellboy195> I'm doing a merge some things changes I wanted to test it with pbuilder. But I get an error debhelper (>=6) is not installable and I should remove pbuilder-satisfydepends-dummy
[16:16] <hellboy195>  to solve the problem. so how to remove that?
[16:18] <geser> hellboy195: debhelper 6 isn't in hardy yet
[16:19] <geser> hellboy195: either downgrade the build-depends to debhelper 5 (and also debian/compat) or wait till debhelper 6 is merged
[16:21] <hellboy195> geser: ah. good to know :) any idea how long it will take until v. 6 is in hardy?
[16:25] <geser> hellboy195: depends on my sponsor
[16:26] <geser> I hope in the next week
[16:26] <hellboy195> geser: so what do you advice me for my merge? downgrade or waiting?
[16:29] <RainCT> Adri2000: Hi. Anything new? :)
[16:31] <geser> hellboy195: it's up to you, but if you can wait (and the merge isn't important) I'd wait to not introduce extra changes compared to Debian which can be dropped again soon
[16:32] <hellboy195> geser: Yeah I also think so. And it's not that important I think so I'll wait. Thx :D
[16:37] <the_belgain> hi, is there any way to package a program which requires a version of ffmpeg supporting non-free codecs (aac, mp3, xvid, ...) at the moment?
[16:38] <the_belgain> because the version of ffmpeg in universe is compiled without support for these
[16:39] <the_belgain> the comments in the bug suggest the answer is no, but i just wanted to double-check: https://bugs.launchpad.net/ubuntu/+source/ffmpeg/+bug/6366
[16:39] <ubotu> Launchpad bug 6366 in ffmpeg "Please enable AAC Support in ffmpeg" [Wishlist,Confirmed]
[16:39] <the_belgain> snap.  shame
[16:39] <the_belgain> looks like this isn't something which is being actively worked on?
[16:40] <the_belgain> is there a compelling reason why two separate (free and non-free) ffmpeg packages couldn't be provided?
[16:44] <proppy> hi
[16:45] <bddebian> Hello proppy
[16:45] <crimsun> the_belgain: there are arguments both ways, but in addition to the source bloat (having to maintain separate versions), there is the compelling factor that no one with commit access wants to touch it.
[16:46] <crimsun> the_belgain: if you'd like to volunteer to ensure that the non-free version remains synced at all times with the free one, then please submit a source package to REVU.
[16:47] <crimsun> the_belgain: if you're unfamiliar with Debian or Ubuntu packaging, the links in the topic of this channel are a good place to start, particularly under Contributing.
[16:48] <the_belgain> i'm in the process of becoming familiar with deb packaging (i'm currently packaging a program which uses ffmpeg, hence my question)
[16:55] <Seveas> the_belgain, heh, you've picked an awful starting point :)
[16:55] <Seveas> ffmpeg is insane
[16:56] <jonnymind> Good evening.
[16:56] <the_belgain> well it looks from the debian/rules in ffmpeg that enabling / disabling the non-free codecs is just a case of setting/unsetting a single debian build flag ("risky") - ffmpeg has been packaged in such a way that it should be straightforwardish to recompile from souce
[16:57] <DktrKranz> hellboy195, back here.
[16:57] <hellboy195> DktrKranz: wb :)
[16:57] <the_belgain> so an ffmpeg-nonfree package would be identical to ffmpeg-free but with that debian build flag set?
[16:58] <the_belgain> that still leaves the issue of keeping them in sync though - is there any mechanism to keep similar debian packages in sync with each other (a simple diff-based mechanism, in the same way that a package itself has the program source plus a diff against it)?
[16:58] <crimsun> you'd also need to modify debian/control* so that the appropriate new binary package(s) and build-dependencies are set.
[16:59] <hellboy195> DktrKranz: query?
[17:00] <DktrKranz> hellboy195, probably here is better, unless someone complains
[17:00] <hellboy195> DktrKranz: np
[17:01] <the_belgain> debian/rules already adds the required dependencies to the weak-build-deps variable - at the moment it then just prints it out to screen, but presumably these can just be added to debian/control, yes
[17:02] <the_belgain> is the "risky" build string a standard string which gets set or unset, or just something someone's added here?
[17:02] <DktrKranz> hellboy195, in 1.99.16-8.1ubuntu3, we put "chmod -R 644 debian/tmp/usr/share/doc/$(package)/examples/*", which is basically what 1.99.16-10 does.
[17:03] <hellboy195> DktrKranz: ah, right
[17:03] <DktrKranz> hellboy195, in that revision, it seems translog files have been removed
[17:04] <DktrKranz> I really don't know what they are, though. Probably some junk stuff inserted by mistake
[17:06] <hellboy195> DktrKranz: hmm
[17:07] <hellboy195> DktrKranz: postrm for example?
[17:08] <DktrKranz> I'm referring to http://dad.dunnewind.net/oleo/oleo_1.99.16-10.patch, translog.20010520153852.log and translog.20010602042022.log
[17:09] <jeromeg> can anyone review my SRU proposal ? bug 184112
[17:09] <ubotu> Launchpad bug 184112 in klavaro "[SRU] klavaro crash" [Wishlist,Incomplete] https://launchpad.net/bugs/184112
[17:09] <hellboy195> DktrKranz: ah, I don't suppose we need them?
[17:12] <DktrKranz> hellboy195, me too.
[17:13] <DktrKranz> They shouldn't be published anywhere but in .diff.gz, though
[17:14] <hellboy195> DktrKranz: well I didn't remove them, the Debian folks did it so hopefully they know what they do
[17:15] <DktrKranz> I think they can be safely removed, but let's see if they are referenced somewhere
[17:23] <hellboy195> DktrKranz: I don't think that they are used. Or have you found something?
[17:35] <jeromeg> jdong: hello !
[17:35] <jeromeg> would you mind ack'ing some backports please ?
[17:43] <DrKranz> jeromeg, hi. Does bug 184112 triggered only with french locale?
[17:43] <ubotu> Launchpad bug 184112 in klavaro "[SRU] klavaro crash" [Wishlist,New] https://launchpad.net/bugs/184112
[17:43] <jeromeg> DktrKranz: seems so, some say it also happens with the Spanish locale
[17:44] <DktrKranz> jeromeg, I'll try with italian one too
[17:44] <jeromeg> ok thank you
[17:44] <DktrKranz> Only Gutsy seems affected?
[17:44] <hellboy195> DktrKranz: so. any others things to change beside the "chmod -R 644 debian/tmp/usr/share/doc/$(package)/examples/*" ?
[17:45] <jeromeg> DktrKranz: yep fixed it got fixed in hardy thanks to our forwarding of bugs :)
[17:45]  * DktrKranz hugs bugsquad
[17:46] <DktrKranz> hellboy195, since there are some changes, we'll need to look at them more carefully
[17:46] <hellboy195> DktrKranz: I'm ready ;)
[17:46] <DktrKranz> since a couple of them sounds weird to me
[17:48] <DRebellion> When the rules file is executed, what is its current directory?
[17:53] <DktrKranz> DRebellion, the one which contains debian directory
[17:54] <hellboy195> DktrKranz: I'm going to have dinner now. Ping me if you have time :)
[17:55] <Coper> I have a problem with that my last 2 dput of a package to REVU didn't get the orig.tar.gz file uploaded. Anybody know why?
[17:56] <DktrKranz> Coper, when uploading to REVU, remember to use -sa flag when launching debuild or dpkg-buildpackage
[17:57] <Coper> DktrKranz: okej, will try agian.
[17:58] <DRebellion> DktrKranz: so the directory above debian/? eg. i have monkeystudio/debian/rules . when rules is executed its current directory will be monkeystudio/ ?
[18:02] <jeromeg> got to go, bye
[18:04] <DktrKranz> DRebellion, yes
[18:05] <DRebellion> DktrKranz: thanks
[18:16] <jonnymind> people, a question on dh_makeshlibs
[18:16] <jonnymind> the man says it "adds" ldconfig calls to postinst/postrm
[18:17] <jonnymind> if those scripts are unneeded except than for that, they should be present in the source package or not?
[18:30] <luckyone> when could I expect to see Tomcat 6 in the repos?
[18:33] <Seveas> luckyone, when someone packages it :)
[18:34] <luckyone> Seveas: could any old idiot be a packager (me for instance)?
[18:34] <Seveas> any idiot willing to spend some time on learning packaging
[18:34] <Seveas> !packagingguide
[18:34] <ubotu> packagingguide is 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
[18:34] <luckyone> Seveas: is it pretty tough?
[18:35] <Seveas> it takes some time to get the hang of it
[18:37] <luckyone> Seveas: thank you for the info - and thanks for all your work - I have your repos in my source.list :D
[18:38] <jonnymind> An OT question: Why, when I put myself in away, and my nick stays the same, i am being pinged by MOTUS saying I should not changing my nick and using /away instead?
[18:39] <mgdm> jonnymind: does your client send a message to the channel when you go away?
[18:39] <jonnymind> yes
[18:39] <jonnymind> Well, to the server.
[18:39] <mgdm> That's why
[18:39] <pochu> jonnymind: because of that
[18:40] <jonnymind> Oh, ok, I will part from the channel before going away
[18:40] <pochu> jonnymind: emilio@venus:~/.irclogs/Freenode$ grep jonnymind \#ubuntu-motu.log | grep 'jonnymind is away' | wc -l
[18:40] <pochu> 14
[18:40] <mgdm> if you're just setting /away then you're fine, but if you spam the channel with "jonnymind is away [BX MsgLog: on]" or some nonsense you will be frowned upon
[18:40] <pochu> jonnymind: just deactivate that script!
[18:41] <jonnymind> It's not a script; it's xchat.
[18:41] <jonnymind> let me see...
[18:41] <blueyed> I'm at the grep package, which uses autotools.mk and tarball.mk in debian/rules. How can I rebuild the grep-2.5.3.tar.gz?
[18:41] <jonnymind> Ok, fixed. Sorry for the distress.
[18:45] <jonnymind> people, I have made dh_makeshlibs -p libfalcon-engine1 -V in the package and removed postrm and shlibs, and now...
[18:45] <jonnymind> gian@hplin:~/tmp/falbuild_ubuntu/falconpl-0.8.8$ lintian /var/cache/pbuilder/result/*.deb
[18:45] <jonnymind> Elly: libfalcon-engine1: no-shlibs-control-file usr/lib/libfalcon_engine.so.1.9.0
[18:45] <jonnymind> Elly: libfalcon-engine1: postinst-must-call-ldconfig usr/lib/libfalcon_engine.so.1.9.0
[18:45] <jonnymind> (sorry Elly, that was just E:)
[18:46] <ion_> :-D
[18:46] <ion_> I’ve never understood why that “feature” was implemented and why people use it. :-)
[18:49] <pochu> jonnymind: your last upload to REVU doesn't have a dh_makeshlibs call
[18:50] <jonnymind> Yes, that was a test, sorry.
[18:50] <jonnymind> I am testing with dh_makeshlibs
[18:50] <pochu> jonnymind: ok. -V needs an argument (the version)
[18:51] <jonnymind> No, it doesn't need it, but I get it:
[18:51] <jonnymind> dh_makeshlibs creates the files in /debian
[18:51] <jonnymind> they must then be installed with something as
[18:51] <jonnymind> dh_installdeb
[18:52] <pochu> Call dh_installdeb then :)
[18:52] <pochu> +too
[18:53] <jonnymind> yes; I was going to try it :-)
[18:55] <jonnymind> same
[18:55] <jonnymind> dh_installdeb
[18:55] <jonnymind> dh_shlibdeps
[18:55] <jonnymind> dh_install -plibfalcon-engine1 --sourcedir=debian/tmp
[18:56] <jonnymind> after dh_makeshlibs -p libfalcon-engine1 -V
[19:16] <luckyone> I am working on setting up fax-to-email on my asterisk server, but I am getting an error using SetVar()
[19:16] <luckyone> hah wrong channel
[19:20] <joejaxx> luckyone: lol
[19:21] <joejaxx> Good Afternoon All :D
[19:31] <jonnymind> pochu: I got it.
[19:32] <jonnymind> I was calling the utils before installing the package in the local dir, and there was no warning about the missing files.
[19:32] <jonnymind> Uploading
[19:32] <stgraber> pochu: Yeah, virtualbox on 2.6.24 !!! :)
[19:33] <pochu> stgraber: let me know what I broke when the buildds do their work ;-)
[19:33] <pochu> (NB: I tested it) :)
[19:45] <LaserJock> hmm, we really should get the "Maintained by: MOTU Media" thing fixed
[20:34] <LaserJock> anybody know what "modified" on merges.ubuntu.com means?
[20:35] <Flare183> LaserJock: means someone has messed with it
[20:37] <LaserJock> hmm, "local" and "repackaged" are I guess the ones I'm wondering about
[20:38] <LaserJock> I was trying to find an easy way to find the number of Ubuntu-changed packages
[20:42] <LaserJock> grepping through _Sources is faster :-)
[20:49] <vemon> what are the files in /usr/share/menu used for?
[20:50] <geser> vemon: for the Debian menu which is disabled by default on Ubuntu
[20:50] <vemon> is it ok for an ubuntu package to be lacking that kind of menu file?
[20:51] <vemon> providing that the package already has a .desktop -file
[20:52] <geser> LaserJock: you could also use the mdt summary to get those numbers
[20:53] <geser> LaserJock: Same version, but Hardy has local changes : 1218 packages + Outdated in Hardy (Sid version > Hardy version), and Hardy has local changes : 269 packages + Outdated in Sid (Hardy version > Sid version) : 121 packages
[20:53] <geser> 1608 total
[20:53] <Taggard> Hi.
[20:54] <Taggard> I'd like to help with Ubuntu somehow and I'm looking at MOTU but I'm not exactly sure what you do. I think you package packages into .debs, but there also seems to be things about you coding bugfixes and such.
[20:56] <geser> Taggard: yes, packaging new software is one aspect but fixing existing packages is also important
[20:56] <pochu> Taggard: https://wiki.ubuntu.com/MOTU/GettingStarted
[20:57] <LaserJock> geser: yeah, but the mdt summary is wrong
[20:58] <LaserJock> geser: there are 10869 packages in universe and 1770 with Ubuntu versions, that doesn't even come close to what the mdt page has
[20:59] <Taggard> geser, pochu: I think I am competent enough to package software (probably), but I don't have coding experience other than Ruby or a little Python. Is coding experience required here, or are languaged like c++ or c required?
[20:59] <jpatrick> Taggard: (ruby rocks), languages aren't needed but recommended
[21:00] <Taggard> jpatrick: (Yeah it does), Okay.
[21:00] <geser> LaserJock: we modified of 16% of the source packages? wow
[21:00] <LaserJock> yes
[21:01] <LaserJock> the mdt page is a bit messed up, I think something must've gone wrong in Fujitsu's script
[21:01] <LaserJock> it works fine for Science bugs, but Universe has 0 for packages where Sid == Hardy and that's not right :-)
[21:01] <blueyed> mdt?
[21:02] <LaserJock> multidistrotools
[21:02] <geser> Taggard: coding experience isn't required. Often patches/fixes exist already, you just need to find them and seldom write them on your own. You just need to apply them on the package and test if it fixes it.
[21:02] <LaserJock> blueyed: http://qa.ubuntuwire.com/multidistrotools/universe.htm for instance
[21:02] <blueyed> +l
[21:02] <LaserJock> warp10: ;-)
[21:04] <warp10> hey LaserJock :)
[21:11] <Coper> Can someone revu my package? http://revu.ubuntuwire.com/details.py?upid=1517
[21:15] <luckyone> when trying to build a package, why is it saying that I am missing glibconfig.h?
[21:15] <luckyone> I have the -dev package installed
[21:16] <blueyed> luckyone: which package? Try apt-get build-dep <package>
[21:16] <luckyone> trying to build source for agx-ast-addons
[21:17] <luckyone> I think the build script I am using is puking on cmake "." -DCMAKE_INSTALL_PREFIX=/usr
[21:18] <jpatrick> luckyone: maybe the makefiles have the header paths incorrectly set
[21:18] <geser> luckyone: does it happen during configure or during the build?
[21:19] <luckyone> geser: there isn't a .configure script, just a build.sh
[21:20] <geser> luckyone: does it use the correct include path for glibconfig.h?
[21:21] <luckyone> geser: I can't tell which cmake file it is using for the path
[21:22] <luckyone> geser: /usr/include/glib-2.0 /usr/lib/gl
[21:22] <luckyone> ib-2.0/include
[21:26] <luckyone> good to go now, thanks
[21:36] <LaserJock> yikes, Planet Gnome has some not-so-friendly remarks on our SRU policy
[21:42] <jpatrick> LaserJock: ouch..
[21:46] <amarillion> "who will eventually contribute to the Yodeling Yak version of Ubuntu?"
[21:48] <amarillion> That is going to be Ubuntu 16.10...
[21:51] <pochu> Taggard: I didn't know any programming when I started (and I don't know much nowadays...)
[21:52] <LaserJock> me neither
[21:53] <Taggard> pochu: :)
[21:54] <geser> LaserJock: there will always be people unhappy with the SRU policy. Either people complain that it's to restrictive or people complain that stable changes to much
[21:55] <LaserJock> yeah, but it's a bit trickier when it's upstreams that are unhappy
[21:55] <geser> LaserJock: we wonders what those people think of Debian stable where gnome is much older
[21:55] <geser> LaserJock: doesn't upstream always want the last, best version in stable?
[21:56] <LaserJock> the kind of thing that guy is talking about doing, putting a warning in Gnome software about Ubuntu, is a bit troubling
[21:57] <geser> sound like the ion3 issue where upstream was unhappy about Debian stable shipping old devel versions and changed the license which lead to moving ion3 to non-free
[21:58] <LaserJock> yeah, but unlike ion3, people actually use Gnome ;-)
[22:02] <zoke> what is this converstaion about ?
[22:03] <zoke> is Gnome warning it's users about Ubuntu or what ?
[22:08] <LaserJock> zoke: http://blogs.gnome.org/phomes/2008/01/26/ubuntu-update-policy-suckage/
[22:10] <zoke> LaserJock, can't this be fixed by putting fixes via backports ?
[22:10] <zoke> and then encouraging the user to use backports ?
[22:52] <LaserJock> zoke: well, but the same problem exists
[22:53] <LaserJock> -backports isn't for bug fixes primarily, but for new upstream versions
[22:53] <LaserJock> it's not meant to have the stability
[22:53] <LaserJock> what the Gnome guy wants is a stable distro with the latest version of his software
[23:30] <zoke> LaserJock, isn't that what we all want ?
[23:36] <Seveas> Pumperni1kle, Pumperni2kle Pumperni4kle Pumperni5kle Pumperni6kle Pumpernickle: dude fix your connection :)
[23:36] <persia> LaserJock: The list of packages unchanged between hardy & sid is intentionally removed from the ubuntuwire multidistrotools report: it's about 13,000 packages and would otherwise hide interesting information.
[23:36] <pochu> lol
[23:39] <LaserJock> persia: that's what I figured
[23:40] <LaserJock> persia: I'm a little suspicious of the Not in sid: 784 packages
[23:40] <persia> LaserJock: Why?  The new semi-automated removals script is doing a good job of keeping that down, and several people have been pushing packages to Debian.
[23:41]  * Taggard is working his wya through the packaging guide.
[23:43] <persia> Taggard: At this point in the development cycle, you'd likely do better to start working on bugs, rather than packaging new software.
[23:43] <Taggard> persia: That generally involves coding though, doesn't it?
[23:44] <persia> Taggard: About 30% of the time.
[23:44] <pochu> persia: he can do package updates too
[23:44] <LaserJock> persia: I can't imagine there being more than 100 "not in sid:" packages
[23:44] <persia> There are lots of bugs that just need some adjustment to the packaging, some patch pulled from upstream, etc.
[23:44] <Taggard> persia: Surely I do need to do the packaging tutorial to do that though?
[23:44] <persia> pochu: Deadline for that is also ~2 weeks away.  Better to do bugfixes.
[23:45] <persia> LaserJock: REVU is a powerful force
[23:45] <LaserJock> persia: ummm, I guess that's one way of putting it
[23:45] <persia> Taggard: Depends how you learn.  The packaging tutorial won't hurt.
[23:45] <LaserJock> a horrendous drag was what came to mind
[23:46] <Taggard> persia: (:
[23:46] <persia> LaserJock: Why?  I think that now that we have UEHS, it's significantly less painful.  About half the packages report as up-to-date (I think).
[23:47] <persia> LaserJock: Err.  Nevermind.  Seems there was less progress than I thought.  About 100 of the packages seem to be in good shape.
[23:47] <LaserJock> persia: because most of that software should be maintained in Debian
[23:49] <persia> LaserJock: Why?  A lot of our multiverse media stack is maintained in Debian-multimedia, which inflates the numbers some.  Also, I don't think it is a bad thing to add new software, as long as it is maintained.  As our tools improve, we should be better about this.
[23:49] <LaserJock> if that page is correct, we roughly 1/3 of the software we maintain is *not* in Debian
[23:49] <LaserJock> bah, kill the first "we"
[23:50] <persia> Right.  1/3 of the stuff we touch is not in Debian.  I believe this to be a result of our documentation: we encourage new packaging.  We need to encourage bugfixing more.
[23:50] <Taggard> Hmm
[23:50] <Taggard> dpkg-buildpackage sure is picky about the changelog file
[23:50] <persia> Also, we need to encourage chasing UEHS during merge season: it should be clear by DIF.
[23:51] <persia> Taggard: The dch tool is your best means of getting it formatted correctly.
[23:51] <Taggard> persia: Probably, I don't knpw, but I'm just doing the manual section of the tutorial right now
[23:52] <Taggard> If I continued doing this and made bugfixes would they actually go into the next release?
[23:52] <LaserJock> persia: well, Multiverse isn't even included in the 784
[23:52] <LaserJock> Multiverse adds another 84
[23:54] <persia> LaserJock: Still, from a policy viewpoint, which is better: killing off REVU and saying everything must go through Debian and DMO, or advocating UEHS review at the beginning of each cycle?
[23:54] <persia> Personally, I suspect the first would annoy Debian.
[23:55] <geser> Taggard: you mean hardy? yes
[23:55] <Taggard> geser: That'd be a pretty rewarding feeling
[23:55] <LaserJock> persia: well, I actually think a bit of both
[23:57] <LaserJock> I don't think we should totally shut down REVU, but 800+ packages is a lot for us if we have no packaging upstream
[23:57] <geser> Taggard: for the programming language part: I know C but since I started to contribute to Ubuntu I didn't do much C, more Makefiles or shell scripting and of course the packaging of the fixes
[23:57] <persia> LaserJock: Utnubu complained that they wanted someone as a point of contact with whom to coordinate.  DCT keeps flailing due to differences in individual preferences of DDs.  Perhaps reinvigorating one or both of these might help?
[23:58] <LaserJock> well, I think the new DM stuff may make it easier for people to maintain stuff in Debian
[23:58] <LaserJock> I mean, if people are *actually* going to maintain packages in Ubuntu and have no interest in Debian I think that's fine
[23:58] <geser> Taggard: it depends on with part you concentrate, there are enough parts where help is needed, e.g. catching unmet deps, fixing package which fail to build (FTBFS), looking out for important fixes in Debian unstable which need to be included in hardy, etc.
[23:59] <LaserJock> but 1/3 of our package load just seems way too much