[01:02] <apachelogger> persia: ahoy, now that nixternal did a +1 on Quintasan's application I suppose quorum is reached and Quintasan can be confirmed to be motu?
[01:05] <persia> apachelogger: I'll probably do that today.  I was just kinda hoping that the others would chime in, but they failed to respond to requests.
[01:05] <persia> apachelogger: Is there some urgency that means it should be done *now*, or would in a few hours be just as good?
[02:53] <ScottK> dktrkranz: When you merge csound, please be sure to bump the boost build deps (we're aiming for 1.40)
[03:46] <ScottK> bddebian: Does mapnik build with boost1.40 on Debian?
[03:51] <bddebian> ScottK: Haven't tried, would you like me to?
[03:51] <ScottK> bddebian: Yes.  Please.
[03:55] <bddebian> pbuilding...
[03:58] <ScottK> Thanks.
[04:00] <LucidFox> Can an orig.tar.gz include free TTF fonts?
[04:01] <bddebian> Shouldn't
[04:01]  * LucidFox nods
[04:02] <ScottK> LucidFox: As long as you use the system fonts and they are appropriately licensed, it's no problem.
[04:02] <ScottK> (i.e. don't use the code copies shipped in the tarball in your build)
[04:02] <bddebian> ScottK: Getting some warnings about deprecated headers but so far it's going
[04:09] <ScottK> bddebian: I got to /usr/bin/ld: cannot find -lboost_python-mt
[04:10] <bddebian> ScottK: Yep, it built
[04:11] <bddebian> Hmm, strange
[04:11] <ScottK> Any suggestions how I might figure that out?
[04:15] <bddebian> ScottK: I assume that lib does exist?
[04:16]  * ScottK goes to inspect the .deb
[04:16] <bddebian> Is it pulling in libboost-python-dev?
[04:19] <ScottK> Yes and yes.
[04:19] <bddebian> Very odd
[04:20] <ScottK> Maybe ajmitch knows since he's officially our boost-python expert now.
[04:20] <bddebian> w00t :)
[04:21] <ScottK> (He fixed a bug in it, so that makes him the expert.
[04:21] <ScottK> )
[04:21] <bddebian> WFM :)
[04:22] <dtchen> does anyone have access to an armel porter?
[04:23] <dtchen> I'm getting a slew of FTBFS that I can't easily test :(
[04:26] <ScottK> There's a armel PPA that Canonical devs have access to.
[04:27] <ScottK> Other than that, I think you need ogra_ or NCommander.
[05:37] <fabrice_sp> bigon,  why do you need sponsorship on bug 427542: you're a motu, right?
[05:40] <dtchen> fabrice_sp: his membership in MOTU is active, at least
[05:40] <dtchen> so, yes
[05:41] <fabrice_sp> dtchen, that's what I thought: as this package was in main some releasea ago, I think he got 'distracted' :-)
[05:41] <fabrice_sp> thanks  to confirm ;-)
[06:05] <siretart`> Whoopie: IIRC we disabled dv support because vlc needed porting to the new API, or there was some general breakage with dv support. Have you tested that dv actually works?
[06:06] <siretart`> Whoopie: in any case, I've pointed xtophe to your patch, he takes a look and will probably apply it for the 1.0.4-1 upload
[06:34] <dtchen> mm, I can ditch the "nvidia" driver completely, because "nv" works great in Lucid
[06:42] <bjsnider> dtchen, is that a joke?
[06:48] <dtchen> absolutely not
[06:49] <dtchen> granted, I don't use anything requiring libGL.so.1, so my particular case is limited
[06:49] <bjsnider> the nv driver is there to provide basic mode-setting so you don't see a black screen the first time you boot linux
[06:49] <bjsnider> it's a transitional driver
[06:50] <bjsnider> nouveau and nvidia are much better
[06:50] <dtchen> I don't much care, frankly; if nv gives me x-terminal-emulators, I'm golden
[06:50] <maco2> who needs compositing?
[06:51] <maco2> dtchen: wait why dont you just use screen in a tty? it can do tiling
[06:51] <dtchen> I do use tmux/screen.
[06:51] <bjsnider> maco, human beings walking around on this earth
[06:52] <bjsnider> but i never mentioned compositing
[06:52] <maco2> well thats the point of using nvidia instead of nv, isnt it? because nv is 2D-only. i kinda though nouveau was still rather experimental though
[06:53] <maco2> *thought
[06:53] <bjsnider> nv has no xv or vdpau
[06:53] <bjsnider> font rendering is probably a mess
[06:54] <bjsnider> no power management. no support for xrandr 1.2
[06:54] <bjsnider> not much of anything
[06:54] <bjsnider> of course the blob doesn't support xrandr 1.2 yet either
[06:54] <bjsnider> but nouveau does
[06:54] <bjsnider> nouveau works great, but possibly not in lucid yet
[06:54] <dtchen> font rendering is fine
[06:55] <dtchen> I used nv for about nine hours without realizing it
[06:55] <bjsnider> dtchen, you don't use your rig for anything interesting? it's all just coding shell scripts in gedit?
[06:56] <dtchen> gedit's a bit too fancy for my lazy self
[06:56] <bjsnider> why not just boot to a back screen then...
[06:56] <dtchen> I do.
[06:57] <bjsnider> just you know, install the kernel by itself
[06:57] <Quintasan> hi
[06:57] <maco2> bjsnider: because sometimes he uses firefox instead of lynx
[06:57] <dtchen> geez, the point is that I can finally kill off the last non-Free driver
[06:58] <maco2> you could've just gotten intel graphics and not had to worry about it :P
[06:58] <bjsnider> nouveau is foss
[06:58] <maco2> yes, his point is he can ditch the binary nvidia driver
[06:58] <bjsnider> but he's not using the best foss driver
[06:59] <maco2> he doesnt care which alternative to go to, it just so happens that nv is on his system and works, so he's going with it
[06:59] <bjsnider> was my point
[06:59] <maco2> if it works, does it matter?
[06:59] <dtchen> I'm sure there are more optimal methods, but I can't be arsed; I'd rather fix this pot of audio bugs.
[07:00] <maco2> hmm though now you've got me wondering... is there a curses calendar app i could use with mutt to ditch kontact?
[07:43] <dholbach> good morning
[07:43] <persia> dtchen: I've got an armel jaunty box (haven't been able to upgrade yet).  Is there something I could test with that?
[07:59] <RAOF> bjsnider: If things go well, nouveau will be the default for lucid, so daniel will be using it instead of nv :)
[08:56] <bigon> fabrice_sp: right the pkg was previously in main, my bad
[09:03] <paultag> o/ MOTU, I have a question about the process of importing from debian
[09:03] <persia> paultag: ask it :)
[09:03] <paultag> do we use the dsc and modify the control / changelog and use that, or do we take the upstream tgz and recreate the debian folder
[09:03] <paultag> persia, sheesh, I was working on it :P
[09:04] <persia> paultag: Sorry.  We get lots of folk who ask to ask and need prompting.
[09:04] <paultag> persia, I know that deal ;)
[09:07] <m4rtin> hi all; I submitted a patch for sponsorship review (regression fix) over a month ago and haven't heard anything. Any ideas; core team v. busy? (it's in bash-completion)
[09:08] <persia> m4rtin: Which is the bug number?
[09:09]  * persia can't help get it merged, but may be able to help check process compliance
[09:09] <m4rtin> #449349
[09:10] <persia> bug #449349
[09:13] <persia> m4rtin: So, is broken in lucid as well as karmic?
[09:13] <m4rtin> persia: I would assume so... it was broken *in* Karmic, so I wrote a fix which someone then suggested I try to get into lucid
[09:15] <m4rtin> It was owing to a bash version upgrade and the bash_completion script being incompatible
[09:15] <persia> m4rtin: So, basically you just want someone to upload the debdiff in comment #45 ?
[09:15] <persia> (and then maybe you'll look at karmic, but that's process stuff for later)
[09:17] <m4rtin> persia: #25 I believe... as for Karmic, I was lead to believe that this would not be ported back as an update...? Is that incorrect? I've been using the fix on my Karmic systems with no problems...
[09:18] <persia> m4rtin: #25, riht.  Sorry.  Dunno how I imagined the extra 20 comments.
[09:18] <persia> It looks to me like you've done everything correctly, and are just stuck waiting for a sponsor.
[09:19] <m4rtin> persia: yeah, I thought so - I'll just sit tight
[09:20] <m4rtin> (my first patch, so I didn't know what to expect)
[09:20] <persia> m4rtin: Yeah.  Sometimes it's slow.  Sorry about that.
[09:21] <m4rtin> it also fixes another very irritating issue in the same package that has existed since 8.10 - ssh completion puts far too many \ characters in to escape spaces and thereby makes it useless for completing more than 1 directory - it's all in the changelog though :)
[09:22] <persia> m4rtin: On the bright side, it looks like it got confirmed as a regression by the update verification team, which means that it's probably getting a bit more visibility than it would otherwise
[09:22] <persia> (but that was a couple weeks ago)
[09:23] <m4rtin> persia: yeah, I saw that; guess they were busy with featuredefinitionfreeze recently, but hey, at some point they'll see it I'm sure
[09:24] <persia> We can certainly hope.
[10:23] <Whoopie> siretart: yes, the DV plugin works under karmic, I don't have a lucid installation.
[10:23] <Whoopie> siretart: I added vlc 1.0.3 to my PPA and enabled DV support for testing.
[10:28] <siretart`> Whoopie: I'd say then feel free to upload the change to lucid :-)
[10:28] <siretart`> Whoopie: or even better, let's discuss this on #debian-multimedia@oftc.net and get this change into debian proper
[10:42] <Whoopie> siretart`: I can't upload anything.
[10:43] <maxb> wiki/SponsorshipProcess doesn't say much about what needs to appear in a merge-sponsorship-request bug. Should I be describing the changes, or should I assume that the sponsor will prefer to read the diff and debian/changelog anyway, so a brief "please merge this" is ok?
[10:46] <persia> I like to get a quick description of the patch.
[10:46] <persia> Something like "Here's something that addresses ${issue} for ${release}
[10:46] <persia> Just to have some idea what I'm looking at.
[10:46] <persia> Yes, the sponsor will be reading the diff and changelog, but a little advance hint never hurts :)
[10:47] <persia> maxb: Actually, in the specific case of merges, some people like more.
[10:47] <persia> For instance, some people like to have the imported Debian/changelog entries summarised in the bug (the ones coming from Debian).
[10:48] <persia> This is less important before Debian Import Freeze, and it would be nice to merge everything.
[10:48] <persia> But after that it becomes more important, as it lets the sponsor make a more informed decision as to whether it's worth digging into the details
[10:57] <siretart`> Whoopie: okay, I'll remember that when uploading to and merging from debian
[11:00] <persia> maxb: The only relevant thing I find in the wiki is https://wiki.ubuntu.com/UbuntuDevelopment/Merging?action=show&redirect=MOTU%2FHowToMerge#File%20a%20merge%20bug
[11:01] <persia> Which doesn't seem to ask for that much info.  I personally tend to file as much info as I would for a sync, but it may not matter.
[11:04] <maxb> ok, thanks for the info :-)
[12:21] <RoAkSoAx> hey guys is merges.ubuntu.com been updated regularly?
[12:22] <slytherin> RoAkSoAx: It should be. What is the problem?
[12:23] <RoAkSoAx> slytherin, some debian package versions are still not updated in the universe list even though the debian package has been in testing for quite a few days
[12:23] <slytherin> RoAkSoAx: any example?
[12:23] <RoAkSoAx> slytherin, apgdiff (its been in testing for 4 days :) ) Or, how much does it take to update the list?
[12:24] <slytherin> RoAkSoAx: As far as I knew it used to be updated daily. May be that has changed recently.
[12:25] <RoAkSoAx> slytherin, prolly its is because they want us to change to distributed development or because the new debian source format
[12:26] <RoAkSoAx> s/prolly/probably :)
[12:26] <slytherin> AFAIK, MoM has support for new source format.
[12:27] <RoAkSoAx> slytherin, yeah but they were doing some tests this past few days in building the packages to see if they can change or not since I think some packages were FTBFS
[12:28] <slytherin> RoAkSoAx: Was that related to MoM or Launchpad?
[12:28] <RoAkSoAx> slytherin, Launchpad
[12:28] <persia> Launchpad still needs a bit of work in order to support uploads of the new format, but I'm not certain this is related to MoM
[12:28] <RoAkSoAx> slytherin, do you know who maintains those lists?
[12:29] <slytherin> nope
[12:29] <slytherin> persia: AFAIK, source format 3.0 landed in edge.launchpad.net
[12:30] <persia> slytherin: I heard it was disabled pending some software upgrades.
[12:30] <persia> (that was from #launchpad sometime in the last 12 hours)
[12:31] <slytherin> Ok. Then you have latest info. I was only tracking the bug.
[13:08] <Laney> launchpad but not the buildds, afaik
[14:16] <slytherin> If a library has some part sunder this license it is free enough to be included in archives - Smack contains icons and images licensed from INCORS GmbH. You are not licensed to use these icons outside of Smack.
[14:16] <persia> Erm.
[14:16] <persia> I'd say that belongs in multiverse, personally.
[14:21] <Whoopie> jdong: Hi, sorry for prodding but how do we continue with bug 481448?
[14:21] <Whoopie> jdong: I just need someone to upload the package.
[14:23] <slytherin> persia: the icons will be included in jar file and not be available separately.
[14:23] <persia> slytherin: Right, but I don't think it's DFSG free.
[14:24] <slytherin> that is bad then. :-( I will ask on Debian lists.
[14:24] <persia> I don't think that icons packaged that way meet the requirements for #3 and #6 at http://www.debian.org/social_contract#guidelines
[14:24] <persia> Yeah, ask Debian.  I'm probably extra picky :)
[14:26] <slytherin> Whoopie: You should bug RainCT about that.
[14:30] <slytherin> persia: And what if the library which includes the icons is not being packaged at all? I mean there are 3 jars in the package and only one contains these icons. I am not planning to ship this jar in any binary package.
[14:31] <Laney> I'd repack to remove it then
[14:31] <persia> slytherin: I don't think it matters: the *source* needs to be DFSG free (well UFSG, which is basically DFSG + a couple specific exceptions)
[14:31] <persia> Because the source is *also* being distributed.
[14:31] <persia> But send a note to debian-legal explaining the details and your plans, and see what they say.
[14:31] <slytherin> Ok. Then repacking makes sense. That way source becomes DFSG free and binary has no problems.
[14:32] <persia> That also works :)
[14:32] <slytherin> by the way looking at quality of icons I am wondering why they are bothering with shipping them at all.
[14:32] <persia> heh :)
[14:39] <mterry> persia, I was looking at the link at the top of REVU to the diff file: http://revu.ubuntuwire.com/revu1-incoming/netbook-launcher-efl-0912171333/netbook-launcher-efl_0.2.0.0-0ubuntu1.diff
[14:40] <Rhonda> Oh, CoC 1.1 finally arrived. :)
[14:40] <persia> You're looking at an old revision: see http://revu.ubuntuwire.com/revu1-incoming/netbook-launcher-efl-0912171439/netbook-launcher-efl_0.2.0.0-0ubuntu1.diff
[14:41] <Rhonda> ... but somehow the release date can't be proper, 2005-04-12. :D
[14:41] <persia> heh, no.
[14:41] <mterry> persia, Huh.  Yeah, I went to the main REVU page and landed on the new page.  I guess I didn't realize I could get stuck on an old revision
[14:41] <Laney> Rhonda: That's because the old CoC is considered to be compatible with this one
[14:41] <Laney> (so as not tp
[14:41] <Laney> to expire old signatures)
[14:41] <persia> mterry: Each revision is separately available for detailed review :)
[14:42] <Rhonda> Laney: Erm.  "The current version is 1.1, released 2005-04-12"
[14:42] <persia> Laney: Except the content changed: how are we to know if we agree with the current version?
[14:42]  * persia does, but is curious about the abstract
[14:42] <mterry> persia, still can't upload, as eina and friends aren't updated in lucid.  Well, I could push, but it would be dependency wait.
[14:42] <Rhonda> Laney: I have no clue what you refer to so that old signatures don't expire, but that sounds pretty fishy.
[14:42] <Laney> Rhonda, persia: Yeah, I'm just the messenger
[14:42] <persia> mterry: Your call, rally.
[14:43] <mterry> persia, they did that to not invalidate old signatures, under the theory that the changes were not substantive
[14:43] <persia> Laney: Understood.  We just kinda hoped you had a larger message :)
[14:43] <Laney> Rhonda: So if people agreed to the older version then LP considers that they agree to 1.1
[14:43] <persia> Um, the changes are substantive enough that we've an *active* developer (Rhonda) who has been waiting for them for almost two years.
[14:43] <Rhonda> Laney: And that for the page has to lie about the release date of the 1.1 version?
[14:43] <Laney> https://bugs.edge.launchpad.net/launchpad-registry/+bug/479870/comments/3
[14:44] <Laney> Rhonda: That's because LP compares the date released to the date signed to see which versions of the CoC you have agreed to
[14:44] <persia> Oh, so it's an implementation trick.
[14:44] <Laney> ...so they couldn't update the date released without expiring all old sigs
[14:44] <Laney> yes
[14:45] <persia> Well, they *could*, but it would require coding changes, etc.
[14:45] <Whoopie> slytherin: where can I find him/her?
[14:45] <Laney> right
[14:45] <persia> (which is more delay)
[14:45] <Laney> they couldn't *as it stands now*
[14:45] <persia> Right.
[14:46] <slytherin> Whoopie: him, right here, have patience.
[14:46] <Whoopie> slytherin: ok, thanks
[14:48] <Rhonda> Laney: A wording change would be appropriate then. This is just confusing as it stands now. :(
[14:48] <Laney> Rhonda: I agree. Perhaps you could file an LP bug?
[14:49] <Rhonda> Yes, am already wondering wether launchpad-registry is the proper target? :)
[14:49] <Rhonda> ... actually, was just about to ask exactly that. :)
[14:49] <Laney> a) Fix the "date released" thing. b) Fix the semantics of signing previous versions — just need to make it clear that signing old versions is still acceptable for being an Ubuntu member, etc
[14:50] <Laney> Rhonda: Not sure, I'd just file to Launchpad and let it be triaged
[14:50] <Laney> or you could ask in #launchpad
[14:50] <mterry> persia, my irc client must be confused, I don't see any admins of this channel.  I'm assuming you're one?  Can you mark me a reviewer in the REVU database
[14:51] <persia> REVU admins and #ubuntu-motu admins aren't the same set, but yeah, I'm supposed to be able to do that
[14:51]  * persia hasn't done it in a while, so it may take a few minutes
[14:52] <persia> BY the way, the Statistics page on REVU has a list of all the admins
[14:53] <mterry> persia, oh, the REVU wiki page is unclear on the distinction.  let me edit.  How is someone supposed to know set of REVU admins?
[14:53] <mterry> persia, heh, whoops.  OK
[14:53] <shriekout> http://revu.ubuntuwire.com/p/happytimer
[14:53] <shriekout> please... advice....
[14:53] <persia> mterry: Should work now.
[14:53] <persia> (and as our newest reviewer, maybe you want the latest review request ? )
[14:54] <mterry> persia, I'll start with netbook-launcher-efl
[14:55] <persia> shriekout: I don't have time for a proper review of happytimer right now, but I'll give you a capsule one here
[14:56] <persia> Priority "extra" is for packages that break things or conflict with core: you want Priority "optional"
[14:56] <shriekout> :)
[14:56] <shriekout> yes...
[14:56] <shriekout> thanks :)
[14:57] <persia> shriekout: Please add a debian/watch file or get-orig-source rule
[14:57] <shriekout> humm...
[14:57] <persia> Err, ignore that.  The diff is sorted differently than I expected :(
[14:58] <shriekout> :)
[14:58] <persia> I don't see anything else quick-like.
[14:58] <persia> But I'm doing a few other things: maybe someone else can do a full review, or I'll catch it later.
[14:58] <shriekout> yes..
[14:59] <shriekout> persia, thanks :)
[14:59] <persia> Nice work!
[14:59] <Rhonda> Laney, persia: https://bugs.edge.launchpad.net/launchpad/+bug/497785
[14:59] <shriekout> have a nice day :)
[14:59] <persia> shriekout: Well, l'm an hour east of you, but thanks :)
[15:00] <shriekout> :)
[15:00] <persia> Rhonda: Thanks for the pointer.
[15:00] <shriekout> i'm a korean... I’m not so good at English... sorry...
[15:02] <shriekout> thanks persia for your advice :)
[15:02]  * Rhonda thanks persia and Laney :)
[15:03] <persia> Rhonda: I'm not sure I deserve that, but you're always welcome :)
[15:03] <Rhonda> You do deserve more. :)
[15:05] <jpds> Rhonda: dholbach was the person who landed the coc-1.1 branch.
[15:06] <Rhonda> jpds: I'm aware of that. :)  But this isn't about the CoC itself, rather about wording on the codeofconduct page in launchpad.
[15:13] <ulysses__> Hello, I am working on bug 497742
[15:13] <ulysses__> I want a littlhe help: what should I write in the control file for Build depends?
[15:15] <persia> ulysses__: That's usually best detemined by trial and error.
[15:15] <persia> But you might look at some other plasmoids, and start with a minimal set like that.
[15:15] <persia> You might also get more specific advise in #kubuntu-devel (although there are often a fair number of KDE people here).
[15:15] <ulysses__> Thanks
[15:34] <Quintasan> dholbach: I sent you answers for Behind MOTU, the picture of me is just... well I'll wait for your reaction :P
[15:35] <Laney> I forgot to respond to that when I got MOTU :(
[15:36] <Quintasan> Laney: what a shame, you are missing you opportunity for international fame, tons of money and girls ;)
[15:36] <Quintasan> your*
[15:37] <dholbach> Laney: do it
[15:37] <dholbach> Quintasan: I'll have a look in a bit
[15:37] <Quintasan> dholbach: Great :)
[15:37] <matti> dholbach: ;]
[15:40] <bddebian> Heya gang
[15:41] <Quintasan> bddebian: \o
[15:41] <bddebian> Hello Quintasan
[15:43] <paultag> Hey guys, I have a quick question about importing from debian -- do we use the dsc and modify the control / changelog and use that, or do we take the upstream tgz and recreate the debian folder, any links or help would be well recieved :)
[15:49] <ScottK> paultag: Hopefully we don't make any change at all.
[15:50] <ScottK> If some change is needed, it's use the .dsc, modify changelog, control, etc.
[15:50] <paultag> ScottK, I'm doing upstream, and I wanted to submit it for Ubuntu review
[15:50] <paultag> ScottK, so it's OK to use the dsc and make small changes to control / changelog?
[15:51] <ScottK> Yes.
[15:51] <paultag> ScottK, thanks :)
[16:08] <machina> anyone know how to make a diff that would remove binary files?
[16:09] <persia> machina: You can't.
[16:09] <Laney> you can't remove files, only reduce them to emptiness
[16:09] <persia> (limitation of patch)
[16:09] <persia> machina: You could delete stuff in debian/rules clean: (which is what some people do)
[16:09] <persia> But if they are non-free binaries, you need to repack or complain to upstream.
[16:10] <machina> that's kinda upsetting...
[16:11] <machina> they aren't non-free, it just looks like the author, run ./configure or make in his new upstream
[16:12] <machina> should I just not worry about the object files & binary file then?
[16:18] <machina> I'll send a message to upstream though
[17:44] <Emanem> Hi all, I have an issue with Ubuntu deb creation
[17:44] <Emanem> is there anyone able to help?
[17:45] <persia> !ask
[17:47] <Emanem> ok... I'm assembling by hand a deb file
[17:47] <persia> Ah.  You probably don't want to start from there :)
[17:47] <persia> Do you have source?
[17:47] <Emanem> I've created the debian-binary and the archive with control (control.tar.gz) and data (data.tar.gz)
[17:47] <Emanem> no
[17:48] <Emanem> I'll release the source as tar.bz2 plus just 2 packages for ubuntu 32 and 64
[17:48] <Emanem> and I just want to created a deb file with 1 only executable
[17:48] <azeem> Emanem: assembling by hand is discouraged
[17:48] <Emanem> btw I've coded and compiled the binary
[17:48] <Emanem> why?
[17:49] <Emanem> then what can I use?
[17:49] <azeem> it's not easily reproducable
[17:49] <Emanem> this software is .2 and wanted to release the source plus 32 and 64 deb just for testing purposes (eg for people that don't want to recomile it)
[17:50] <Emanem> so which tools can I use?
[17:51] <persia> Emanem: Create a source package, and then get it built somewhere to generate your .debs.
[17:51] <Emanem> why do I have to do so?
[17:52] <Emanem> my deb consist of 2 dependencies and 1 only executable
[17:52] <Emanem> plus I'm using a simple Makefile to build my project, don't want to include the ./configure etc etc
[17:53] <geser> Emanem: how can I be sure that the binary you build matches the source?
[17:54] <wrapster> hi all.. when i dist upgrade is done this is the error I get... http://pastie.org/747466
[17:54] <wrapster> its not ubuntu ... but related to packaging so asking here...
[17:54] <wrapster> could anyone please help me understand what this means and about any ideas as to how i can resolve it?
[17:55] <Emanem> persia , geser : I don't think honestly, I'll provide the sources with GPLv3, so people will be able to rebuild themselves. Packages are only for people which don't want to rebuild it
[17:55] <Emanem> that's why I want to include an executable
[17:55] <persia> Emanem: See, you create a source package, and you have it built, and users can get the binaries.
[17:56] <Emanem> I'm getting this error btw: http://ubuntuforums.org/showthread.php?t=1356471
[17:56] <persia> We just don't have any good tools for assembling binary packages directly.
[17:56] <Emanem> sorry but doesn't the deb format rely on ar ?
[17:57] <Emanem> I don't understand this then... how can people like Skype provide proper packages?
[17:57] <geser> Emanem: and an user can also use the source package if he needs to modify your program (e.g. apply a patch, build with newer libs, etc.) to build a new deb
[17:58] <Emanem> geser :  the program will be released under gplv3, so they'll be free to do whatever they want :)
[17:58] <Emanem> the point is, there must be a proper guide/howto to explain the format/which tools/programs are used to create proper packages
[17:58] <geser> Emanem: sure, but without a source package it harder to them to build an updated deb (or do you ship a script to hand-build a deb?)
[17:59] <Emanem> geser: latter could be... but even not, the program is simple
[17:59] <persia> Or better stated: it's harder for *you* to build a binary package.
[18:00] <Emanem> so, what am I doing wrong? the error I'm having when I try to install the deb is : dpkg-deb: file `/home/ema/TEST/packages/TEST-0.2_amd64.deb' is not a debian binary archive (try dpkg-split?)
[18:00] <geser> Emanem: Skype probably use a source package too, they just skip the compilation during the package building and install the pre-built binaries
[18:01] <geser> Emanem: how did you assemble the deb? (the last step)
[18:01] <persia> I thought Skype used a source package and just didn't share the source.
[18:02] <Emanem> geser: "ar -r mypackage-2.0_amd64.deb control.tar.gz data.tar.gz debian-binary"
[18:03] <geser> persia: I don't know, I just assumed
[18:03] <persia> Emanem: We're not really prepared to help you do it that way.  None of us do it that way.
[18:04] <Emanem> Sorry guys, but can you please point me to the script that is assembling the last step? I fear that I have to manually modify the "archived" (ar -r) file
[18:05] <geser> Emanem: although debs are 'ar' archives, dpkg doesn't like all (don't know the details)
[18:05] <Emanem> and how are these created? which tool?
[18:06] <persia> We use debuild or dpkg-buildpackage on source packages to generate binary package.
[18:06] <persia> So we really don't know the manual process.
[18:07] <persia> (or we use sbuild or pdebuild or upload to some archive)
[18:07] <Emanem> sorry but there must be some sort of tools used to produce proper deb if ar can't be used...
[18:08] <geser> in the end dpkg-deb creates the deb, but as persia said, without a reason nobody looks at the low-level steps to build a packages
[18:09] <persia> Emanem: You really will find your life easier if you just create a few files in debian/ in your source and run debuild.
[18:09] <persia> It's not a clean package, but it's easier than trying to create binary packages manually.
[18:10] <Emanem> persia: what is debian/ ? maybe I'm missing that bit
[18:10] <persia> !packaging
[18:10] <persia> Emanem: Take a look at our packaging guide.
[18:11] <persia> Basically, to create a package, unpack your source tarball, create a debian/ directory, add copyright, changelog, control, compat, and rules, and build.
[18:11] <persia> (it can get more complex, but that's the high-level overview)
[18:11] <Emanem> ubottu: the guide is broken
[18:14] <Emanem> persia: do you know where can I find the online sources of dpkg-buildpackage so I can look them myself?
[18:16] <Emanem> (I'm tempted to release the 2 binaries without any deb package...and btw this is why devs have hard time doing these things... how comes that one has to use 3/4 scripts to basically create an archive file (deb)?)
[18:16] <persia> apt-get source dpkg-dev
[18:16] <geser> Emanem: http://git.debian.org/?p=dpkg/dpkg.git
[18:16] <Emanem> thanks geser
[18:16] <geser> Emanem: http://git.debian.org/?p=dpkg/dpkg.git;a=blob;f=scripts/dpkg-buildpackage.pl;h=cf39187aa0726ef68b034012828f0920df80aeaa;hb=HEAD
[18:19] <Emanem> The error I get is thrown here: http://git.debian.org/?p=dpkg/dpkg.git;a=blob;f=dpkg-deb/extract.c;h=cd8332282f6261903af6d62d4fad3667a1931474;hb=HEAD#l147
[18:21] <Emanem> LOL found out the error
[18:22] <Emanem> dpkg expects the first file of the archive to be debian-binary... omg...
[18:22] <Emanem> so even order matters...
[18:24] <Emanem> well now I'm getting another error... I guess I'll source-debug dpkg and eventually find out all the issues and fix them...
[18:24] <Emanem> thanks guys for the dpkg sources
[18:25] <persia> Emanem: You really might have an easier time with a source package :)
[18:26] <Emanem> persia: I'm more a software dev/computer scientist and actually when something doesn't properly work I really enjoy dig, understand and (possibly) fix
[18:26] <Emanem> thanks for suggestions anyway :)
[18:30] <Emanem> persia, geser: YESSS! I did it! :-)
[18:31] <blackxored> I need an sru for azureus in karmic
[18:31] <ScottK> !SRU
[18:32] <blackxored> s/I need an sru/I need to do an sru
[18:33] <blackxored> the azureus issue
[18:33] <blackxored> is confirmed
[18:33] <blackxored> can't run 4.2.0.8 in karmic anymore
[18:33] <blackxored> so I got 4.3.0.0 in lucid
[18:33] <blackxored> how to proceed?
[18:33] <blackxored> this bug
[18:34] <blackxored> Bug #488507
[18:34] <Emanem> persia, geser: One last question: are the following libraries [libstdc++.so.6 , libm.so.6, libgcc_s.so.1, libpthread.so.0 ] installed by default on every Ubuntu system, am I correct? I guess nothing would run without those...
[18:37] <ScottK> blackxored: Generally SRU should be a patch targetted to solve a specific problem.  You should probably discuss it with someone in ubuntu-sru.  IIRC jdong is both on ubuntu-sru and familiar with azureus.
[18:37] <blackxored> ScottK, thanks
[18:37] <geser> Emanem: you can assume that. they are so low in the dependency chain, that nothing is left if you try to remove them
[18:38] <Emanem> geser: I definitely would imagine that after 10+ years c/c++, but you know, better double check than have bad surprises...
[18:40] <geser> you might need to check if you need special symbols that only appear since a specific version
[18:42] <awe> lool, james_w: do either of you guys know what the deal is with merge-o-matic ( merges.ubuntu.com )?  is it supposed to be up-to-date?
[18:42] <james_w> I think it keeps falling over
[18:43] <awe> I did a merge two weeks ago for gst-plugins-bad, and it hasn't updated...
[18:45] <geser> last I heard MoM still doesn't like format 3.0 packages (even with the backported dpkg), don't know if it got fixed
[20:04] <tombee> Are there any opportunities to get involved with security programming in Ubuntu? :)
[20:06] <kees> tombee: sure thing.  see https://wiki.ubuntu.com/SecurityTeam
[20:06] <tombee> Wow great, thanks kees
[20:06] <kees> np.  we hang out in #ubuntu-hardened  (redirected from #ubuntu-security)  see the bottom of that page for the GettingInvolved link
[20:07] <tombee> The thing is I'm not that experienced in software security, but it's something I'd like to gain experience in and educate myself in :)
[20:08] <tombee> So I'm not sure how I would go about 'getting started'
[20:11] <tombee> kees: the roadmap looks good though :)
[21:48] <Rhonda> I wonder… I merged multiple accounts into my rhonda account. With that came various mail addresses. If I remove those addresses, will the merge be undone, or would that only affect future stuff that would get imported with those addresses?
[21:51] <geser> I guess you need to ask in #launchpad to get an answer (or even file a question)
[21:55] <persia> Rhonda: I'd recommend just hiding the addresses, unless there's some special reason to forcibly remove them.
[21:55] <Rhonda> Yeah, they are hidden anyway.
[21:56] <Rhonda> geser: Oh, right. Always forget about that special-purpose channel. Sorry. %-/
[21:59]  * wgrant is concerned that it's "special-purpose", and not for a different product, as is reality.