[00:00] <maxb> It's an obscure and complex corner case that is handled perfectly adequately in the package name in ubuntu
[00:00] <mirak> maxb: it's just I don't think it's logical to have to change the source version, if the source just doesn't change
[00:01] <mirak> maxb: I am maybe a perfectionist but I just think there should be two layers of depency.
[00:01] <mirak> it's like dpkg does just half of the job
[00:02] <maxb> I remain unconvinced, sorry.
[00:06] <mirak> why gxine_0.5.903-4ubuntu1~ppa1~jaunty1 is below gxine_0.5.903-4ubuntu1 ? I did something wrong here
[00:06] <maxb> That's the special significance of ~
[00:07] <directhex> that's the purpose of ~
[00:07] <directhex> ~ is a generic "less than" marker
[00:07] <directhex> 1.0~1~1 < 1.0~1 < 1.0
[00:08] <mirak> ok
[00:08] <directhex> + is the reverse
[00:10] <mirak> but why xine-ui_0.99.5+cvs20070914-2.1~lenny2ubuntu2~ppa1~jaunty1 upgraded over xine-ui_0.99.5+cvs20070914-2.1~lenny2ubuntu2 ?
[00:10] <mirak> maxb: my bad
[00:10] <mirak> I forgot the number mistake
[00:11] <ajmitch> those version numbers hurt my eyes
[00:12] <directhex> ajmitch, agreed. "cvs"? :o
[00:13] <jtechidna> a backport of a ppa version of an ubuntu version of a backport from lenny? lulz
[00:13] <directhex> actually, it's impressive. a jaunty build of a ppa build of an ubuntu build of a lenny backport of a NMU of a CVS snapshot
[00:13] <maxb> "cvs from a year and a half ago" :O
[00:13] <directhex> with whipped cream and a cherry on top
[00:14] <directhex> JontheEchidna, don't miss the NMU, that's added lulziness
[00:14] <ajmitch> directhex: it's missing an x.y.xisreallya.b.c
[00:14] <JontheEchidna> hehe
[00:14] <directhex> ajmitch, don't make me wave the behemoth at you
[00:15] <directhex> 10.0.1.218+10.0.0.525ubuntu1~hardy1+really9.0.124.0ubuntu2
[00:15] <ajmitch> where's the epoch?!
[00:16] <directhex> 3:3.3.8really3.3.7-0ubuntu11.1
[00:16] <directhex> ajmitch, howzat?
[00:17] <ajmitch> starting to get there
[02:28] <ScottK> ajmitch: We really don't want to do an epoch if Debian doesn't.
[02:29] <ScottK> I'm pretty sure I recognize directhex's example as my work.
[02:32] <ajmitch> ScottK: I know, we were joking
[02:32] <ScottK> OK.
[02:58] <qiyong> should I create pv on a whole disk device or on a  partiton ?
[03:30] <bucket529> Question: The mail-notification package in Debian has SSL disabled ( http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=286672 ) due to a Debian Legal opinion on OpenSSL. The developer disagreed, claiming that the package has no such code in it, but disabled SSL anyway to get accepted by Debian. Is it worthwhile to file a needs-packaging bug in Ubuntu to get an SSL-enabled version into the repos? Or is there a better wa
[03:31] <ScottK> bucket529: Without looking, I'd say that there is no difference between our policy on such things and Debian's.
[03:33] <bucket529> ScottK: Sensible. The developer (not me) claims the refusal to accept an SSL-enabled version was an error on Debain's part. Whether it is or not (I'm not a lawyer), who would make that call in Ubuntu?
[03:33] <ScottK> bucket529: Now I've read the bug.  If it links against openssl and is GPL, but doesn't have an openssl exception, it's not distributable.
[03:33] <ScottK> We have the same policy as Debian on this.
[03:34] <bucket529> ScottK: So the key is 'links against', not 'includes code' ?
[03:34] <ScottK> In Ubuntu it would be decided by an archive administrator (like ftp-master in Debian).
[03:34] <ScottK> Yes.
[03:34] <ScottK> Upstream's statement that it includes no code from openssl is not the real issue.
[03:35] <bucket529> ScottK: Thanks for the clarification.
[03:36] <ScottK> There is some discussion about if openssl qualifies as a system library with a standard interface, but generally in Debian/Ubuntu that's not accepted.
[03:37] <bucket529> ScottK: Ah.
[03:39] <lifeless> bucket529: gnutls
[03:40] <VK7HSE> I've had a go at merging  libhtml-parser-perl it's uploaded to me PPA on LP https://edge.launchpad.net/~vk7hse/+archive/ppa is there a mentor free to have a look and advise me of any mistakes?
[03:41] <ScottK> lifeless: That's mentioned in the Debian bug as an option, but some porting is required.
[03:45] <bucket529> lifeless: Upstream will do what upstream will do. My advice to the fellow who asked me will be: 'Nudge upstream to seek the exception'.
[03:46] <lifeless> bucket529: indeed.
[03:48] <calc> you can only ad a openssl exception if everyone that wrote code for it agrees and it doesn't link to anything gpl either
[03:49] <calc> s/ad/add
[03:50] <bucket529> calc: Thanks.
[04:12] <ajmitch> oh goody, a new tool for me to package up for karmic
[04:12]  * ajmitch looks for an ITP bug
[04:15] <pangloss> so question that I am sure has been answered before: if I am packaging something that requires some libraries, and I am nearly positive that those libraries will never be used by any other application, should I just package the application witht he libraries integrated, or should I packaged the libraries individually and then add them as depends in the application?
[04:19] <ScottK> pangloss: Individually.  It's actually probably easier and it's better in the long run in case you're wrong.
[04:20] <pangloss> ScottK, Thanks
[04:50] <hansfbaier> I am the developer of libprolooks and jackpanel, I packaged them (as native packages), built them in my ppa for karmic and uploaded them to revu.
[04:53] <hansfbaier> Should I get a response after subscribing ubuntu-universe-sponsors to the bug?
[04:56] <ScottK> Yes, although native packages probably aren't right.
[05:43] <hansfbaier> ScottK: Since I am the developer of the software, should I then keep the debianization in a separate git repo?
[05:44] <ScottK> hansfbaier: yes.
[05:44] <ScottK> You don't want to have to make a new release everytime you change the packaging.
[05:44] <ScottK> That or just exclude it when you roll your upstream tarball.
[05:46] <hansfbaier> ScottK: I include it in my upstream tarball
[05:46] <ScottK> Right, that's what makes it a native package.
[05:46] <ScottK> Don't do that.
[05:47] <ScottK> It will make your life easier in the long run (I package stuff I'm upstream for and this is what I've found)
[05:47] <persia> hansfbaier, A couple examples where it is easier:
[05:47] <hansfbaier> ScottK: So since I use git, probably git-buildpackage would be best, wouldn't it.
[05:47] <persia> 1) the case where there is some silly transition in a distro that doesn't affect the code
[05:47]  * ScottK and git aren't on good terms.
[05:47] <persia> 2) the case where a distro is under some freeze, and one wants to backport a patch
[05:48] <hansfbaier> ScottK: What do you use, then?
[05:48] <ScottK> hansfbaier: mostly svn.
[05:48] <hansfbaier> ScottK: Where should the repo be located, is there any preference?
[05:49] <ScottK> I'm also very good with diff and patch.
[05:49] <ScottK> I'm old and probably have a workflow that isn't at all typical.
[05:49] <ScottK> But that doesn't change the basic principle.
[05:49] <hansfbaier> ScottK: The packaging repo, that is.
[05:49] <ScottK> It's really up to you.
[05:49] <hansfbaier> ScottK: Ah thanks.
[05:50] <ScottK> In my svn layout I have it exactly where it unpacks to.  I just exclude it when I roll the tarball.
[05:51] <hansfbaier> ScottK: So in your svn you have the debian/ dir, but you exclude it in the upstream tarball?
[05:51] <ScottK> yes.
[05:52] <ScottK> Then I let the packaging continue to evolve in trunk even though I include a snapshot of the packaging in the tag.
[05:52] <hansfbaier> ScottK: What are native packages for, exacly, something that is innate to the distro?
[05:52] <ScottK> Yes, exactly.
[05:52] <hansfbaier> s/exacly/exactly/
[05:52] <hansfbaier> ScottK: I see.
[05:52] <ScottK> Some people do use them as you were considering, but it's really suboptimal.
[05:53] <hansfbaier> ScottK: I have 4 branches in my repo, one for karmic, one for hardy, one for jaunty and one master
[05:53] <hansfbaier> ScottK: Which differ in packaging
[05:53] <ScottK> Is the upstream source the same for all of them?
[05:54] <hansfbaier> ScottK: Not really, since karmic needs some workarounds for the bugs in Vala 0.7.2
[05:54] <ScottK> You can still manage that and not have a native package.
[05:54] <hansfbaier> ScottK: And hardy comes with vala 0.5.7 and needs some backporting therefore.
[05:55] <hansfbaier> ScottK: That is where git-buildpackage would come in.
[05:55] <ScottK> I know in pkg-clamav on alioth (Debian) they have upstream clamav and packaging all in the same git repo.
[05:55] <ScottK> Probably.
[05:55] <hansfbaier> ScottK: generating debian-diffs, right?
[05:55] <hansfbaier> ScottK: So I probably have to read more on git-buildpackage.
[05:56] <ScottK> Since they are uploading directly and not looking for sponsorship they are interested in tools to produce a package ready for upload.
[05:56] <ScottK> However, once you have that, a debdiff is trivial to get to.
[05:58] <hansfbaier> ScottK: Thank you very much for the feedback.
[05:59] <ScottK> hansfbaier: You're welcome.
[05:59] <hansfbaier> persia: Thanks too.
[06:15] <hyperair> is anyone free to review remuco-server? http://revu.ubuntuwire.com/p/remuco-server
[07:41] <kklimonda> any motu around to sponsor bug 368855?
[07:52] <dholbach> good morning
[07:53] <nixternal> good morning
[07:53] <dholbach> hiya nixternal
[07:54] <nixternal> howdy
[08:03] <kklimonda> btw, to fix 368855 in KK new version of cherrypy3 has to be packaged (be either us or debian maintainer - For now I've reported bug on debian bts about it). Should I link to debian bug in this report or create a new one?
[08:07] <geser> link the Debian bug to the existing bug in LP
[08:15] <didrocks> good morning
[08:21] <Toadstool> good morning
[08:25] <bizkut> morning
[08:56] <evanrmurphy> good morning/night
[09:00] <toabctl> hi all. i build a new package with cdbs and created some patches with cdbs-edit-patch. when i want to build the package with debuild -S, i got: Patch debian/patches/osmap_path.patch is not applied. Why?
[09:12] <runasand> toabctl: maybe you have to apply the patch first?
[09:14] <toabctl> runasand, and how to do that? i thought, debuild will do it for me...
[09:17] <runasand> that is a good question ;p
[09:18] <runasand> toabctl: have you read what the cdbs-doc says about patching? using dpatch etc
[09:19] <toabctl> runasand, thanks. i'll read the docs.
[09:19] <runasand> it says something about an include-line you should add to debian/rules
[09:19] <runasand> at least.. :)
[09:27] <maxb> toabctl: You are including simple-patchsys.mk, yes?
[09:27] <toabctl> maxb, ye
[09:27] <toabctl> yes
[09:27] <maxb> hmm
[09:27] <maxb> Personally I find the simple-patchsys too simple, so I can't really help much more than that
[09:28] <dholbach> toabctl: is that a warning or an error?
[09:28] <dholbach> to me it sounds like simple-patchsys just lets you know that the patch is not applied
[09:28] <toabctl> dholbach, yes, i think so
[09:39] <toabctl> dholbach, here is my build-process. is it fine now? http://paste.ubuntu.com/171376/
[09:41] <runasand> did you figure it out, toabctl?
[09:41] <LucidFox> maxb> What's wrong with simple-patchsys?
[09:41] <LucidFox> That you have to name patches in order?
[09:42] <maxb> Well mainly that it's bound to cdbs, to be honest :-)
[09:42] <toabctl> runasand, i think, it was only a message that the patch was not applied. it wasn't an error
[09:42] <LucidFox> ah
[09:43] <LucidFox> I use CDBS for simple common scenarios and dh 7 when I need more fine-grained control
[09:43] <LucidFox> mostly
[09:44] <maxb> !
[09:44] <maxb> simple, and CDBS, are not two concepts that I would use together :-)
[09:44] <runasand> toabctl: ah :)
[09:44] <LucidFox> Heh.
[09:45] <LucidFox> Well, it allows ffor very short debian/rules files
[09:45] <toabctl> maxb, im new to debian packages and cdbs and simple patch system are great for me..
[09:46] <toabctl> maxb, i don't know much about makefiles and all that stuff. so cdbs is good to start.
[09:46] <dholbach> toabctl: yep, looks good to me! :)
[09:47] <toabctl> dholbach, and what to do now?
[09:47] <toabctl> can i test the buildprocess with pbuilder?
[09:48] <dholbach> toabctl: yep
[09:48] <dholbach> toabctl: or with simply running   debuild
[09:49] <maxb> I think the real problem with cdbs is that it's too easy to write a package that you don't really understand
[09:49] <LucidFox> Is there a way to automatically install build-dependencies for a given source package or unpacked package directory?
[09:49] <LucidFox> maxb> Same with dh 7
[09:50] <maxb> Indeed, I favour traditional dh
[09:50] <LucidFox> although at least it doesn't hide away build steps... hmm
[09:50] <dholbach> LucidFox: sudo apt-get build-dep <bla>  for a package in the archive or   /usr/lib/pbuilder/pbuilder-satisfydepends   in the source tree
[09:50] <dholbach> sudo /usr/lib/...
[09:50] <directhex> ooh, running pbuilder-satisfydepends
[09:50] <directhex> clever!
[09:50] <LucidFox> Is pbuilder-satisfydepends used on a .dsc?
[09:50] <dholbach> LucidFox: no, just in the source tree should be fine
[09:51] <LucidFox> And won't it leave pbuilder-satisfydepends-dummy installed?
[09:51] <dholbach> /usr/lib/pbuilder/pbuilder-satisfydepends-gdebi then :)
[09:51] <dholbach> should be faster too
[09:52] <LucidFox> pbuilder's dependency resolution used to be really slow before they swithed to the pbuilder-satisfydepends-dummy system
[09:57] <LucidFox> There's IRC for emacs? O_O
[09:58] <directhex> LucidFox, i'm waiting for emacs to get a decent text editor
[09:58] <LucidFox> Old joke :p
[09:58] <directhex> LucidFox, the old ones are the best
[09:58] <LucidFox> ^_^
[09:58]  * LucidFox switches back to Eclipse
[09:58] <directhex> LucidFox, and since i can't use duke nukem forever jokes anymore...
[09:59] <LucidFox> You mean Duke Nukem Dead Forever?
[09:59] <directhex> whatever happened to eclipse packaging effort? what i saw made it sound like a new tarball is the coming of the apocalypse
[09:59] <LucidFox> directhex> There was a preliminary 3.4 package in December 2008, last I know
[10:00] <maxb> I've heard that the Eclipse build system is the stuff of nightmares
[10:00] <LucidFox> The Eclipse plugin system is a mess.
[10:00] <LucidFox> I updated my home installation recently and broke SVN support.
[10:01] <maxb> I "packaged" Eclipse for my company's desktops (just repackaging the binaries) - worked great in 3.3 - since they introduced the supposedly "better" p2 stuff in 3.4, it's become hellaciously fragile
[10:02] <LucidFox> p2?
[10:02] <maxb> That piece of evil regression-laden mess that replaced the Update Manager
[10:02] <LucidFox> Oh.
[10:02] <LucidFox> Yes LS
[10:02] <LucidFox> * :S
[10:03] <LucidFox> and DEPENDENCY HELL
[10:03] <LucidFox> in all caps
[10:05] <LucidFox> although I only use Eclipse when I actually need a full-featured IDE.
[10:05] <LucidFox> I tried using it for packaging, but I found out that what I really used was just a text editor with a directory tree view, so I switched to gedit
[10:06] <maxb> It's totally only worth it for the code assist, refactoring, etc.
[10:06]  * LucidFox nods
[10:06] <LucidFox> yes, I can't imagine writing Java without it
[10:07] <maxb> silly overly verbose language :-)
[10:07] <LucidFox> I like it.
[10:08] <maxb> Oh, I use it a lot too, and its.... ok
[10:08] <LucidFox> I'm actually thinking of rewriting my website in Java from PHP
[10:08] <maxb> I often want to beat Sun around the head with a cluestick though
[10:09] <LucidFox> What for?
[10:09] <maxb> Little stupidities like: there's no way to do mkdir, and find out why it fails, if it fails
[10:10] <LucidFox> oh
[10:10] <maxb> And, the subprocess invocation API explicitly warns you that if you don't simultaneously read both stdout and stderr of a child, buffering issues may cause you to deadlock... but there's NO WAY TO DO SO
[10:10] <maxb> (short of spawning an extra thread)
[10:11] <maxb> Oh, and the fact that it's practically impossible to write a Java application which doesn't require a shell/perl/python script to start it up
[10:11] <maxb> These are not huge impenetrable stumbling blocks. They are just hideous warts
[10:18] <directhex> LucidFox, i did the reverse - my website used to be hand-rolled JSP, which i had to port to PHP when my webhost went to hell and nobody would host JSP on the cheap
[10:19] <LucidFox> Ewwww, JSP
[10:19] <directhex> maxb, doesn't java have a binfmt wrapper?
[10:19] <directhex> LucidFox, i can easily say something more "ewww" than JSP. watch this:
[10:20] <directhex> i could write some ASP.NET in Java, using IKVM! genius!
[10:20]  * LucidFox is intent to write all her new Java web applications in Wicket
[10:21] <directhex> i tell a lie, i still fail to grasp the central asp.net paradigms
[10:22] <maxb> Wicket is indeed rather lovely
[10:22] <directhex> perhaps packaging something would help. i wonder if i could find a dfsg-free wiki or blog to package
[10:25] <LucidFox> directhex> Depends on the version of ASP.NET. I vaguely remember ASP.NET 1.0, but knowing Microsoft, everything has probably changed a bazillion times already.
[10:26] <directhex> LucidFox, well, i did ASP in you yoof, but ASP and ASP.NET only share a name, nothing else
[10:26] <LucidFox> YES
[10:26] <LucidFox> Just like ADO and ADO.NET
[10:27] <quadrispro-acer1> mok0: hi! are you around?
[10:27] <mok0> aye
[10:27] <quadrispro-acer1> bug #193393
[10:27] <quadrispro-acer1> i uploaded the package to REVU
[10:28] <mok0> quadrispro-acer1: ah, a revu request... :-)
[10:28] <quadrispro-acer1> yeah
[10:28] <mok0> quadrispro-acer1: I will take a look at it later
[10:29] <quadrispro-acer1> ;) ok tr
[10:29] <quadrispro-acer1> * thx
[10:30] <LucidFox> I thought packages from debian-multimedia.org could be uploaded directly to NEW?
[10:31] <AnAnt> Hello, can someone review sabily-keyring: http://revu.ubuntuwire.com/details.py?package=sabily-keyring
[10:32] <quadrispro-acer1> LucidFox: I think its's not "legal", because debian-multimedia isn't debian, so we need to review them before uploading
[10:32] <directhex> LucidFox, i think it's all about branding - i.e. "you liked foo, try foo.net" rather than "you liked foo, try bar"
[10:33] <quadrispro-acer1> however, the policy for this kind of pkgs isn't really clear
[10:33]  * quadrispro-acer1 going away for a few of minutes
[10:34] <quadrispro-acer1> directhex: sorry for the late: congrats! and welcome aboard :)
[10:35] <directhex> quadrispro-acer1, thanks
[10:37] <LucidFox> quadrispro-acer1> Well, I believe jdong uploaded mpeg4ip straight to NEW, and so did I with kplayer, and I got sync requests from DMO acked and approved in the past
[10:38] <LucidFox> for new packages, that is
[10:39] <LucidFox> directhex> yes, that's bsically it
[10:45] <james_w> well, I'd at least advise you to review the licenses and debian/copyright
[10:48] <LucidFox> That goes without saying, james_w :)
[10:48] <james_w> well, judging by some of the things that end up in NEW, I'm not so sure :-)
[10:49] <LucidFox> ^_^
[10:52] <joaopinto> hi
[11:11] <Toadstool> hmm, the new REVU workflow proposal looks really promising to me, I really like it
[11:11] <hyperair> hmm? workflow proposal?
[11:11] <hyperair> got a link?
[11:11]  * Toadstool high fives whoever worked on this
[11:11] <Toadstool> hyperair: https://wiki.ubuntu.com/REVUWorkflowProposal
[11:12] <runasand> Toadstool: I agree, it looks nice :)
[11:15] <Toadstool> speaking of reviewing, it's been so long since I didn't do any... I feel rusty :)
[11:15] <runasand> I would if I could :]
[11:39] <Toadstool> oh right... I can't advocate packages, nevermind
[13:17] <savvas> if the packaging is changed from debian native to normal, it should be shown correctly in revu, right?
[13:18] <jmehdi> needs review: http://revu.ubuntuwire.com/details.py?package=webstrict (I'm ready to do any change quickly as this package is here from more than a year!)
[13:20] <aboudreault> Hi, I am wondering if there is someone who is very familiar with packaging and launchpad, and who can speak French. There is a few that I'd like to understand, but i have some problems to explain everything in English.
[13:21] <runasand> jmehdi: have you fixed the copyright-issues and stuff? and what about the warning/notice that's shown on revu?
[13:28] <loic-m_> aboudreault: fire ahead ;)
[13:31] <loic-m_> jmehdi: since you're one of the two people that wrote webstrict, can't you assign a copyright for each source file? It would really help
[13:35] <jmehdi> loic-m_: I've added a copyright at the beginning of the java files, should I add something else?
[13:35] <loic-m_> jmehdi: only thing I see is that you're saying "please refer to the copyright file". It's not the same
[13:36] <cjwatson> nothing in Ubuntu policy requires a copyright notice in every source file
[13:36] <jmehdi> loic-m_: I did the same thing as the gnome-do team did
[13:36] <loic-m_> jmehdi: ok
[13:36] <cjwatson> there's no reason for that to cause a rejection at the revu stage
[13:36] <cjwatson> some *upstream* organisations require this, e.g. GNU, but it would be crazy for Ubuntu to do so
[13:37] <loic-m_> cjwatson: isn't it a pain later when there's other contributors and you can't track who touched what because of some laziness at the beginning?
[13:37] <cjwatson> from our point of view, if the licensing is clear from the object as a whole distributed by upstream (i.e. the tarball) then that's all we need
[13:37] <cjwatson> loic-m_: that's not Ubuntu's problem
[13:37] <cjwatson> loic-m_: all we need is clear and consistent licensing
[13:38] <loic-m_> cjwatson: it is when the original uploader moves away and someone has to update the package
[13:38] <dlynch> Is the terminator application an excellent example from which to copy the handling of i18n tasks in python? I'm the upstream author of a desktop python application who is very new to i18n, and I'm trying to find excellent examples of organizing and packaging the po files and any other house keeping tasks
[13:38] <cjwatson> loic-m_: what does that have to do with copyright status?
[13:38] <cjwatson> loic-m_: you do not need this information as a packager
[13:38] <loic-m_> cjwatson: spending 10+ more hours tracking a svn because else you can't also maintain it in Debian it a pain
[13:38] <cjwatson> loic-m_: what does that have to do with copyright status?
[13:39] <loic-m_> cjwatson: I've seen packages rejected from DD because the copyright in the source files is severely outdated (missing names)
[13:40] <cjwatson> loic-m_: there has been some confusion about this from some newbie Debian ftpmasters, but I believe it's been resolved on debian-policy
[13:40] <loic-m_> cjwatson: and people in Debian dropping their ITP because upstream didn't want to correct it
[13:40] <cjwatson> loic-m_: as a Debian developer, you need to reproduce copyright notices from upstream
[13:40] <cjwatson> loic-m_: you don't need to do better than upstream
[13:41] <cjwatson> loic-m_: *shrug* those people are wrong and should have been persistent
[13:41] <loic-m_> cjwatson: I'll need to read debian-policy again ;)
[13:41] <cjwatson> see e.g. http://lists.debian.org/debian-policy/2009/03/msg00270.html
[13:41] <cjwatson> "We do not require people to wade through $VCS commit logs or mailinglist
[13:41] <cjwatson> threads to find out who wrote each single line of code."
[13:41] <captivus> Good morning
[13:42] <directhex> just through all the source files, when AUTHORS is out of date
[13:43] <ScottK> directhex: All you need to go through the source files for is difference licenses.
[13:43] <LucidFox> https://edge.launchpad.net/~ubuntu-6had <-- What the heck?
[13:43] <cjwatson> directhex: and even then it's a matter of debate; what one Debian ftpmaster rejects on is not the same as Debian policy
[13:43] <LucidFox> it seems Launchpad teams are becoming weirder with each day
[13:44] <_Andrew> How do I get a list of packages that depend upon a selected package?
[13:44] <runasand> LucidFox: uuuuhm :p
[13:44] <loic-m_> cjwatson: thanks for the link to the discussion
[13:44] <_Andrew> I want to test my built package and make sure everything works with what's in ubuntu
[13:45] <cjwatson> LucidFox: seems to me that Joey Hess might be justifiably annoyed about that
[13:45] <cjwatson> I'm not aware that anyone from Ubuntu helped him to write dh7 at all
[13:46] <cjwatson> _Andrew: the dctrl-tools package has useful search tools
[13:46] <_Andrew> thanks
[13:46] <runasand> http://img76.imageshack.us/img76/3616/ubuntu.jpg -- ^_^
[13:49] <Hobbsee> runasand: haha.  wave the magic wand
[13:49] <runasand> Hobbsee: yeah ;p
[13:49] <_Andrew> The package "funguloids" says it depends upon "ogre-plugins-cgprogrammanager" however there is no such package?
[13:49] <LucidFox> O_O
[13:49] <Hobbsee> runasand: "IT support.  have you tried turning it off and back on again?"
[13:50] <runasand> Hobbsee: \o/
[13:50] <runasand> Hobbsee: the it crowd rocks :)
[13:50] <Hobbsee> :)
[13:50] <Hobbsee> indeed!
[13:50] <directhex> Hobbsee, i had to do that to a car once.
[13:50] <directhex> Hobbsee, i had to reboot the engine to make the stereo stop sounding like a bad Am radio
[13:50] <Hobbsee> hah.  nice!
[13:51] <directhex> Hobbsee, not really :|
[13:51] <directhex> no wonder GM are in the toilet
[13:52]  * kmdm sighs and notes he still has 0118 999 881 999 119 7253 committed to memory, tune et al. :)
[13:53] <ScottK> _Andrew: There is such a package, it's just never built, IIRC.
[13:53]  * runasand wonders what "et al" means
[13:53] <loic-m_> Is it still required that changelog for a new package only contain one entry?
[13:53] <kmdm> runasand: probably nothing, but I sometimes use it as "and all" ;)
[13:53] <runasand> loic-m_: think so
[13:53] <runasand> kmdm: ah :)
[13:53] <ScottK> _Andrew: IIRC as it stands it's impossible to get it to build on our buildds.  It only works in Debian because they allow binary uploads.
[13:54] <directhex> tsk. unbuildable packages
[13:54] <_Andrew> I think the bug I filed (284750) changes that
[13:55] <ScottK> It's non-free/multiverse anyway
[13:55] <directhex> tsk. non-free
[13:56] <ScottK> _Andrew: Yes.  That would do it.
[14:02] <jmehdi> loic-m_: do you see any other problems with my webstrict package?
[14:11] <loic-m_> jmehdi: your changelog should only had one entry AFAIK
[14:12] <ScottK> popey: Cheers for advertising a new service without spamming my inbox.  When I read, "It's now moved into an invite-only beta phase" I thought for a moment it was going to be an ubuntuone parody.
[14:13] <loic-m_> jmehdi: keep the top entry (1.4...), just copy/paste in it the entries from 1.3... (unless you droped the patches)
[14:14] <jmehdi> loic-m_: should I keep the version? (1.4-0ubuntu2)
[14:14] <jmehdi> loic-m_: to upload again on revu should I put 1.4-0ubuntu3?
[14:14] <popey> :) ScottK
[14:18] <loic-m_> jmehdi: no, keep everything at 0ubuntu1 since only the upload to Ubuntu repositories (= not REVU uploads) counts in Ubuntu
[14:18] <jmehdi> loic-m_: ok, that's what I thought
[14:18] <loic-m_>  jmehdi: (that's different than on Debian)
[14:19] <loic-m_>  jmehdi: I didn't have the time to really check, but you seem to have addressed all of persia's concerns
[14:19] <jmehdi> loic-m_: ok, is it correct: http://pastebin.ubuntu.com/171631/
[14:20] <loic-m_>  jmehdi: you should put the fact you addressed all his concerns in a comment (wheter you detail that or not) to encourage reviewers to check your package
[14:20] <jmehdi> loic-m_: ok, and how is made the final approval?
[14:21] <loic-m_> jmehdi: looks ok to me
[14:21] <loic-m_> jmehdi: you need to convince two MOTU to review and advocate your package
[14:22] <jmehdi> loic-m_: ok
[14:22] <loic-m_> jmehdi: another thing that can help (but isn't required) is uploading you package to a PPA (if you have one) to show that it builds ok (and people can try it too)
[14:23] <jmehdi> it's already on my PPA (but not this last version) ; where should I put the PPA url? in a comment on REVU ?
[14:23] <loic-m_> jmehdi: it just depends if people are busy or not at a certain time. I'd suggest hanging around on REVU days (Fridays) since people set time aside for reviewing
[14:24] <loic-m_> jmehdi: yes, in a comment it's good
[14:24] <jmehdi> loic-m_: ok
[14:24] <loic-m_> jmehdi: changelog un-necessary > unnecessary
[14:25] <jmehdi> loic-m_: ok ;)
[14:26] <bddebian> Heya gang
[14:26] <freeflying> bddebian: hi
[14:26] <bddebian> Hi freeflying
[14:28] <cpscotti> dae gabo!
[14:28] <GaboB> e aii scotinho!!!
[14:28] <GaboB> vamo fludááááá
[14:28] <jmehdi> loic-m_: I try to upload my package on revu again but it tells me "Already uploaded to revu on revu.ubuntuwire.com" "Doing nothing for webstrict_1.4-0ubuntu1_source.changes"
[14:29] <jmehdi> loic-m_: (that's why I increased the version number last time)
[14:31] <cjwatson> runasand: it's short for "et alii", Latin for "and others"
[14:31] <runasand> cjwatson: ah, thanks! :)
[14:32] <loic-m_> jmehdi: you need to force the upload : dput -f ......
[14:33] <jmehdi> loic-m_: so simple ;)
[14:34] <loic-m_>  jmehdi: for PPA it's different AFAIK,  it won't work and you'll just have to bump the changelog, f.e. add ~ppa1 (-0ubuntu1~ppa1), debuild again and upload
[14:37] <Elbrus> runasand: et al usually meant "and others" (from Latin) ... [14:53] * runasand wonders what "et al" means
[14:38]  * Elbrus seems to be late by mere minutes ;)
[14:39] <artfwo> Hello! I have fixed an archive rejection for http://revu.ubuntuwire.com/p/scantailor - would anyone like to review/readvocate? Thanks!
[15:42] <ni|> hello, i've built a working deb file
[15:42] <ni|> and everything appears great on jaunty
[15:42] <ni|> i'm concerned however about it being backwards compatible
[15:43] <ni|> i want to make one deb for the 8.04 up to 9.04 -- is this impossible?  Do i need to run the debuild -b -us -uc on all the version i want to support and provide debs for each version :/
[15:44] <azeem> ni|: launchpad PPAs do that for you I think; at least you can upload source for every version you want to support and get it built there
[15:45] <ni|> azeem: this is a binary that the company i'm working with requested -- its not source sadly
[15:45] <directhex> ni|, a package in a PPA does not "cascade", i.e. a version uploaded to hardy is not written to the jaunty Packages.gz file
[15:46] <ni|> directhex: interesting
[15:46] <azeem> ni|: why do you need to support 8.10?
[15:46] <directhex> ni|, generally speaking, a package is compatible between releases as long as its dependencies are well written and still true
[15:46] <ni|> i mean i only have 3 really
[15:46] <ni|> unfortunatley one of them is qt4
[15:46] <ni|> and qt3 is all that is present in 8.04
[15:46] <directhex> then you have a problem, don't you
[15:46] <ni|> yes i do
[15:47] <ni|> directhex: but i suppose i could do some finagling
[15:47] <directhex> qt 4.4.0 is in hardy-backports
[15:47] <ni|> directhex: you suspect that the important line is the depends line in control
[15:47] <directhex> so you could simply insist that people have backports enabled
[15:47] <ni|> directhex: yes, thats what I was thinking
[15:47] <ni|> this was a painless experience :P
[15:47] <ni|> thanks a lot
[15:48] <directhex> oh, and always make sure you compile your app on the oldest os you plan on supporting, as compatibility rarely goes both ways
[15:50] <ScottK> There is Qt4 in Hardy.
[15:53] <directhex> -backports
[15:53] <directhex> oh, wait
[15:53] <directhex> i'm misreading p.u.c
[15:53] <ScottK> I mean in the release pocket.
[15:53] <directhex> hardy has 4.3.4
[15:53] <ScottK> Even Dapper has some version of Qt4.
[15:54] <directhex> i think the ABI question holds even truer then - make sure you build against the "right" version of Qt4
[15:54] <directhex> assuming some degree of ABi backward-compatibility
[16:06] <imbrandon> assume , hrm , lets break this word down ... ass-u-me .... ass ( out of ) u ( and ) me
[16:07] <imbrandon> lol
[16:51] <savvas> ScottK: it looks like boost1.38 needs similar patches as the ones in boost1.37 to enable python2.6
[16:51] <ScottK> savvas: I'd expect so.
[16:52]  * ScottK hasn't looked
[16:53] <savvas> there is a related bug at debian, but it's marked as wishlist: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=523901
[16:54] <aboudreault> what could be the reason of this message: dpkg-genchanges: warning: ignoring -sd option for native Debian package
[16:55] <savvas> aboudreault: does the source come with a debian/ folder?
[16:55] <savvas> I mean the source from where you downloaded it
[16:56] <aboudreault> no. i took the debian folder in a svn repository, and copied it my original source
[16:57] <savvas> hmm
[16:57] <savvas> ok in debian you have orig.tar.gz which should be the original source as .tar.gz without debian folder
[16:58] <aboudreault> Hmm... maybe because my original source is .tar.bz2 and not .tar.gz ?
[17:00] <savvas> aboudreault: can you execute this and paste it in a paste.ubuntu.com: ls -l
[17:00] <savvas> while in the directory I mean :)
[17:00] <savvas> I need to see the folder/file names
[17:02] <aboudreault> k
[17:03] <aboudreault> in fact... geos-3.1.0 is my directory, and i have geos-3.1.0.orig.tar.bz2 at the same level
[17:04] <savvas> ah ok
[17:04] <aboudreault> (i tried to use a .tar.gz..... same thing)
[17:04] <savvas> bunzip2 geos-3.1.0.orig.tar.bz2
[17:04] <savvas> gzip -9 geos-3.1.0.orig.tar
[17:04] <savvas> mv geos-3.1.0.orig.tar.gz geos_3.1.0.orig.tar.gz
[17:05] <aboudreault> haa... the "-"
[17:07] <savvas> yes, orig.tar.gz needs an "_" between the package name and the version :)
[17:07] <savvas> the rest need "-"
[17:07] <aboudreault> i forgot that. thanks a lot
[17:07] <savvas> np
[17:07] <aboudreault> is there an easy way to delete the "extra" source upload on launchpad ? :P
[17:08] <savvas> you mean upload the same version number again? no, I don't think they allowed that
[17:08] <savvas> just make ~ppa1 to ~ppa2 :)
[17:09] <aboudreault> that will remove the extra .orig.tar.gz ?
[17:10] <aboudreault> i've uploaded the file 3 times. hardy,intrepid, jaunty. didn't notice that it uploaded the full source 3 times.
[17:11] <aboudreault> anyway, that only ~15mb :P
[17:11] <savvas> I don't know about that, ask in #launchpad :)
[17:12] <aboudreault> ok ^^
[17:12] <aboudreault> what is the tool to compare 2 ubuntu version?
[17:13] <aboudreault> dpkg.. kk.
[17:14] <savvas> yep, dpkg --compare-version :)
[17:19] <ScottK> savvas: Python 2.6 stuff is just wishlist in Debian because 2.6 is just in Experimental currently.
[17:22] <savvas> ScottK: ah ok :) the cgal package merge is ready though blocked by this. bug 374440
[17:23] <ScottK> savvas: Does it work with 1.37?
[17:23] <savvas> I will probably have to wait for boost1.38 to be fixed and re-do it if there's a new cgal package in the future
[17:23] <savvas> didn't try it, I'll check in about 30 minutes and let you know :)
[17:24] <ScottK> 1.37 is already moved to Main, so until we hear otherwise, that's not a bad target.
[17:24] <savvas> oki doki
[17:26] <savvas> darn, "No, dcsharp is no longer active."
[17:50] <LucidFox> Can I rejoin u-u-s? My term expired during the Jaunty cycle.
[18:14] <LucidFox> gilir> There is no need to attach Ubuntu dendiffs when merging, since most of it will be a massive upstream diff that isn't of interest
[18:14] <LucidFox> * debdiffs
[18:15] <gilir> LucidFox: about which bug ?
[18:15] <LucidFox> bug #354825
[18:17] <gilir> I think someone ask one for another package, but I'm agree with you :)
[18:20] <james_w> hey gilir
[18:20] <james_w> stop filing sync requests and apply for MOTU already! :-)
[18:20] <gilir> hi james_w :)
[18:20] <LucidFox> gilir> Commented on gpac
[18:21] <gilir> james_w: I think I finish most of the possible sync :)
[18:21] <james_w> heh
[18:22] <james_w> that wouldn't surprise me :-)
[18:22] <gilir> but yes, I should begin my application :)
[18:29] <proq> does anyone know how I would go about contacting the author of wmi?  I need to talk with them about helping port it to jaunty
[18:31] <superm1> proq, wmi - as in windows management interface?
[18:32] <gilir> LucidFox: Thanks, it FTBFS because the package was removed yesterday :)
[18:32] <proq> superm1: yes
[18:33] <superm1> proq, well what portions of it are you interested in?  it's only got certain applicable areas on linux
[18:33] <proq> superm1: I was mostly interested in the winexec tool
[18:34] <superm1> proq, well i'm not familiar with that unfortunately
[18:36] <proq> is there a vc where multiverse package source is checked in?  I would hate to start from the 8.10 sources when something is already underway
[20:08] <ScottK> james_w: I think your proposal (re UUS) is fine, just make sure you pick the right team to not get the per-package upload rights people included (I think it's just motu as IIRC core-dev belongs to motu).
[20:08] <james_w> yeah
[20:08] <james_w> not sure it matters that much
[20:09] <james_w> but I agree
[20:09] <ScottK> Probably not a big deal, but better more correct than not.
[20:09] <soren> IIRC ubuntu-dev also includes per-package people, while MOTU is... Well, MOTU's.
[20:13] <james_w> ScottK: I did actually hint at that in my mail
[21:01] <fabrice_sp> siretart, I saw you  were looking for help with mplayer and mencoder. What kind of help are you looking for?
[21:03] <siretart> fabrice_sp: atm: extending the debian package to build and install mencoder
[21:04] <fabrice_sp> siretart, ok. But it seems Debian package is dropping mencoder.c, so how could we do that?
[21:04] <siretart> next steps: check what lp bugs are fixed by this update (upstream 1.0rc2 -> 1.0rc3), document that in debian/changelog, upload to ubuntu
[21:04] <siretart> fabrice_sp: checkout the master.unstripped branch. it contains mencoder.c
[21:04] <siretart> fabrice_sp: that package will certainly use a different orig.tar.gz because of mencoder.c
[21:05] <siretart> fabrice_sp: or, if that's easier for you, just copy mencoder.c from the upstream rc3 branch in. I'll cleanup the package then
[21:06] <fabrice_sp> siretart, the latest one seem easier :-)
[21:06] <evanrmurphy> Hi all, I'm going through the Patch Systems part of the Packaging Guide (https://wiki.ubuntu.com/PackagingGuide/Complete#Patch%20Systems), but some of the example packages I'm downloading don't appear as described in the guide. For example, in https://wiki.ubuntu.com/PackagingGuide/Complete#Patching%20Without%20a%20Patch%20System, we're dealing with the cron package. The guide says to look for a part in cron's debian/
[21:06] <evanrmurphy> rules about applying and unapplying patches, but it's not in the rules file that came with my apt-get source cron. Am I doing something wrong, or is it possible that the guide is out of date? I'd appreciate your help.
[21:06] <fabrice_sp> so this mean that in the merge diff, I will have that file, right?
[21:06] <fabrice_sp> siretart, ^
[21:07] <siretart> yes, but I'll make sure it will be in the orig.tar.gz for ubuntu
[21:16] <evanrmurphy> Well, if anybody has any suggestions about this, please let me know.
[21:43] <ni|> directhex: you still around?
[21:43] <ni|> i'm using the same deb created by jaunty
[21:43] <ni|> have enabled backports
[21:43] <ni|> all the depends are in the backports as i search through synaptic, yet the system doesn't recongize they are there
[21:43] <ni|> libqtcore4 (and its depends)
[21:43] <ni|> all the qt4 stuff is there
[21:43] <geser> evanrmurphy: not all packages use a patch system
[21:43] <ni|> which is it
[21:44] <ni|> (for my dependencies)
[21:45] <evanrmurphy> geser: Thanks for responding. But cron is the package specifically chosen for this example in the guide, where it's assumed to use a patch system.
[21:47] <geser> evanrmurphy: cron is used as an example for package without a patch system
[21:48] <geser> evanrmurphy: when you read carefully the next example is already for udev and not cron anymore
[21:49] <geser> ni|: what does "apt-cache policy libqtcore4" result? (pastebin please)
[21:52] <evanrmurphy> geser: Sorry for the mistake! I confused the two packages in my question here. In udev I don't see that part in debian/rules about applying and unapplying patches either. As a result, the following Example 1 and Example 2 doesn't seem to work properly on my system.
[21:59] <geser> evanrmurphy: let me guess: you got the udev source from jauny?
[22:00] <geser> evanrmurphy: it looks like the package got change in the meantime. but the udev source from intrepid still uses debian/patches
[22:02] <superm1> siretart_, re: bug 372280, would that mean by the same logic that mythtv could be too?
[22:04] <evanrmurphy> geser: Nice guess. ;) Yes, I'm using Jaunty. Do you know if there's a way for me to apt-get source from Intrepid instead?
[22:06] <kklimonda> hmm.. could someone point me to a better piuparts documentation than manual?
[22:06] <kklimonda> I can't make it do upgrade test for packages..
[22:06] <geser> you could add a deb-src line for intrepid too and tell apt-get source to fetch from intrepid but for one case use "dget -x -u https://edge.launchpad.net/ubuntu/intrepid/+source/udev/124-8/+files/udev_124-8.dsc" is probably faster
[22:07] <kklimonda> according to man all I should have to do is point piuparts to my debs and it will automatically test if they can be upgraded to from version present in repository..
[22:07] <kklimonda> but it doesn't seem to work
[22:07] <kklimonda> (I can paste piuparts.log somewhere)
[22:07] <savvas> james_w: do you have access to commit fixed for packagekit? could you check bug #347327 please? someone posted a fix
[22:07] <savvas> *fixed = fixes
[22:07] <james_w> I used to
[22:07] <james_w> I lost it when it moved to GNOME git
[22:08] <james_w> but I can forward patches
[22:08] <savvas> oh..
[22:08] <james_w> thanks for spotting it though
[22:08] <james_w> I deleted that mail without realising there was a patch attached :-)
[22:08] <savvas> I think it's specific to ubuntu/debian changes launchpad.net/packagekit
[22:09] <savvas> it happens :P
[22:10] <evanrmurphy> geser: Thanks a mil'!
[22:31] <bjfs> Any python packaging mentor around ? ;p
[22:33] <ajmitch> bjfs: there may be some, depending on the problem
[22:33] <ajmitch> otherwise #debian-python on OFTC :)
[22:34] <bjfs> They're silent like the lambs. All I need is to know how to split a source into two packages. One being arch "all" for the application, and another "any" for the module (binding stuff).
[22:35] <bjfs> Currently I'm stuck on having a control file with the two packages described, nothing more ;-)
[22:35] <ajmitch> ah, and you need to split up debian/rules to install the right stuff in the right place?
[22:36] <bjfs> probably so
[22:36] <kklimonda> hmm.. you could also do it using .install and .dirs files..
[22:36] <ajmitch> how is the packaging currently done?
[22:36] <ajmitch> kklimonda: debian/rules should still have the right sections though
[22:36] <kklimonda> bjfs: is it libmimic you have mentioned on #ubuntu-pl ?
[22:37] <bjfs> kklimonda: yes
[22:37] <ajmitch> bjfs: see, POX is responding there also :)
[22:38] <bjfs> I'll try at MOTU first, it is not that complicated
[22:38] <bjfs> but I have no idea on how to split a package into anything
[22:38] <kklimonda> bjfs: why can't you use libmimic from debian experimental? different api/abi?
[22:38] <bjfs> kklimonda: it is not that easy, because that debian package is not what that application needs, it needs a special python module which is already in the source
[22:39] <kklimonda> bjfs: oh - like this..
[22:40] <bjfs> of course I could just switch "all" to "any" and it would make the magic, but I want to split it
[22:42] <bjfs> but since no other app will use that module, maybe I'll just make that "any" :P
[22:42] <bjfs> brainless workaround
[22:43] <kklimonda> well, it isn't that brainless if module is only for this one package.
[22:43] <kklimonda> hmm. I wonder what has happened to my pbuilders.. ~/.pbuilder/ is empty :/
[22:44] <kklimonda> probably reckless rm -rf :/
[22:55] <bjfs> it feels so weird when one joins # full of specialists, no weather talks, just weird talks about insane number of rules on zillion versions ;]
[22:56] <kklimonda> dtchen: if you have some time could you help me with a piuparts? I'm trying to test package upgrade for my vmmouse merge with debian but I must be doing something wrong. According to the piuparts manual it should automatically but for some reason it just doesn't install packages from repository... I have a full log here: http://dl.getdropbox.com/u/163224/piuparts.log
[22:57] <kklimonda> bjfs: that's how #ubuntu channels should be ;)
[23:02] <bjfs> world without PPA's would be boring ;-) another succesful package upload...
[23:03] <Nafallo> i.e. release periods ;-)
[23:25] <ni|> geser: i will paste it now, are you still around?
[23:26] <ni|> pastebin.com/m68ccf486
[23:59] <ni|> awww