[00:00] It's an obscure and complex corner case that is handled perfectly adequately in the package name in ubuntu [00:00] 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] maxb: I am maybe a perfectionist but I just think there should be two layers of depency. [00:01] it's like dpkg does just half of the job [00:02] I remain unconvinced, sorry. [00:06] why gxine_0.5.903-4ubuntu1~ppa1~jaunty1 is below gxine_0.5.903-4ubuntu1 ? I did something wrong here [00:06] That's the special significance of ~ [00:07] that's the purpose of ~ [00:07] ~ is a generic "less than" marker [00:07] 1.0~1~1 < 1.0~1 < 1.0 [00:08] ok [00:08] + is the reverse [00:10] 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] maxb: my bad [00:10] I forgot the number mistake [00:11] those version numbers hurt my eyes [00:12] ajmitch, agreed. "cvs"? :o [00:13] a backport of a ppa version of an ubuntu version of a backport from lenny? lulz === jtechidna is now known as JontheEchidna [00:13] 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] "cvs from a year and a half ago" :O [00:13] with whipped cream and a cherry on top [00:14] JontheEchidna, don't miss the NMU, that's added lulziness [00:14] directhex: it's missing an x.y.xisreallya.b.c [00:14] hehe [00:14] ajmitch, don't make me wave the behemoth at you [00:15] 10.0.1.218+10.0.0.525ubuntu1~hardy1+really9.0.124.0ubuntu2 [00:15] where's the epoch?! [00:16] 3:3.3.8really3.3.7-0ubuntu11.1 [00:16] ajmitch, howzat? [00:17] starting to get there === jtechidna is now known as JontheEchidna [02:28] ajmitch: We really don't want to do an epoch if Debian doesn't. [02:29] I'm pretty sure I recognize directhex's example as my work. [02:32] ScottK: I know, we were joking [02:32] OK. [02:58] should I create pv on a whole disk device or on a partiton ? [03:30] 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:30] Debian bug 286672 in mail-notification "mail-notification: Can't use SSL/TLS" [Normal,Open] [03:31] bucket529: Without looking, I'd say that there is no difference between our policy on such things and Debian's. [03:33] 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] 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] We have the same policy as Debian on this. [03:34] ScottK: So the key is 'links against', not 'includes code' ? [03:34] In Ubuntu it would be decided by an archive administrator (like ftp-master in Debian). [03:34] Yes. [03:34] Upstream's statement that it includes no code from openssl is not the real issue. [03:35] ScottK: Thanks for the clarification. [03:36] 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] ScottK: Ah. [03:39] bucket529: gnutls [03:40] 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] lifeless: That's mentioned in the Debian bug as an option, but some porting is required. [03:45] 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] bucket529: indeed. [03:48] 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] s/ad/add [03:50] calc: Thanks. [04:12] oh goody, a new tool for me to package up for karmic [04:12] * ajmitch looks for an ITP bug [04:15] 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] pangloss: Individually. It's actually probably easier and it's better in the long run in case you're wrong. [04:20] ScottK, Thanks === nhandler_ is now known as nhandler === santiago-pgsql is now known as santiago-ve [04:50] 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] Should I get a response after subscribing ubuntu-universe-sponsors to the bug? [04:56] Yes, although native packages probably aren't right. [05:43] ScottK: Since I am the developer of the software, should I then keep the debianization in a separate git repo? [05:44] hansfbaier: yes. [05:44] You don't want to have to make a new release everytime you change the packaging. [05:44] That or just exclude it when you roll your upstream tarball. [05:46] ScottK: I include it in my upstream tarball [05:46] Right, that's what makes it a native package. [05:46] Don't do that. [05:47] 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] hansfbaier, A couple examples where it is easier: [05:47] ScottK: So since I use git, probably git-buildpackage would be best, wouldn't it. [05:47] 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] 2) the case where a distro is under some freeze, and one wants to backport a patch [05:48] ScottK: What do you use, then? [05:48] hansfbaier: mostly svn. [05:48] ScottK: Where should the repo be located, is there any preference? [05:49] I'm also very good with diff and patch. [05:49] I'm old and probably have a workflow that isn't at all typical. [05:49] But that doesn't change the basic principle. [05:49] ScottK: The packaging repo, that is. [05:49] It's really up to you. [05:49] ScottK: Ah thanks. [05:50] In my svn layout I have it exactly where it unpacks to. I just exclude it when I roll the tarball. [05:51] ScottK: So in your svn you have the debian/ dir, but you exclude it in the upstream tarball? [05:51] yes. [05:52] Then I let the packaging continue to evolve in trunk even though I include a snapshot of the packaging in the tag. [05:52] ScottK: What are native packages for, exacly, something that is innate to the distro? [05:52] Yes, exactly. [05:52] s/exacly/exactly/ [05:52] ScottK: I see. [05:52] Some people do use them as you were considering, but it's really suboptimal. [05:53] ScottK: I have 4 branches in my repo, one for karmic, one for hardy, one for jaunty and one master [05:53] ScottK: Which differ in packaging [05:53] Is the upstream source the same for all of them? [05:54] ScottK: Not really, since karmic needs some workarounds for the bugs in Vala 0.7.2 [05:54] You can still manage that and not have a native package. [05:54] ScottK: And hardy comes with vala 0.5.7 and needs some backporting therefore. [05:55] ScottK: That is where git-buildpackage would come in. [05:55] I know in pkg-clamav on alioth (Debian) they have upstream clamav and packaging all in the same git repo. [05:55] Probably. [05:55] ScottK: generating debian-diffs, right? [05:55] ScottK: So I probably have to read more on git-buildpackage. [05:56] Since they are uploading directly and not looking for sponsorship they are interested in tools to produce a package ready for upload. [05:56] However, once you have that, a debdiff is trivial to get to. [05:58] ScottK: Thank you very much for the feedback. [05:59] hansfbaier: You're welcome. [05:59] persia: Thanks too. [06:15] is anyone free to review remuco-server? http://revu.ubuntuwire.com/p/remuco-server === hggdh is now known as ger === foursixnine is now known as santiago-ve [07:41] any motu around to sponsor bug 368855? [07:41] Launchpad bug 368855 in cherrypy3 "formatwarning() definition from cherrypy3 incompatible with Python 2.6" [Undecided,In progress] https://launchpad.net/bugs/368855 === Tonio__ is now known as Tonio_ [07:52] good morning [07:53] good morning [07:53] hiya nixternal [07:54] howdy [08:03] 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] link the Debian bug to the existing bug in LP [08:15] good morning [08:21] good morning [08:25] morning === Nafallo_ is now known as Nafallo [08:56] good morning/night [09:00] 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] toabctl: maybe you have to apply the patch first? [09:14] runasand, and how to do that? i thought, debuild will do it for me... [09:17] that is a good question ;p [09:18] toabctl: have you read what the cdbs-doc says about patching? using dpatch etc [09:19] runasand, thanks. i'll read the docs. [09:19] it says something about an include-line you should add to debian/rules [09:19] at least.. :) === Tonio__ is now known as Tonio_ [09:27] toabctl: You are including simple-patchsys.mk, yes? [09:27] maxb, ye [09:27] yes [09:27] hmm [09:27] Personally I find the simple-patchsys too simple, so I can't really help much more than that [09:28] toabctl: is that a warning or an error? [09:28] to me it sounds like simple-patchsys just lets you know that the patch is not applied [09:28] dholbach, yes, i think so === quadrispro is now known as quadrispro-acero === quadrispro-acero is now known as quadrispro-acer1 === quadrispro is now known as quadrispro-u90 === quadrispro-u90 is now known as quadrispro [09:39] dholbach, here is my build-process. is it fine now? http://paste.ubuntu.com/171376/ [09:41] did you figure it out, toabctl? [09:41] maxb> What's wrong with simple-patchsys? [09:41] That you have to name patches in order? [09:42] Well mainly that it's bound to cdbs, to be honest :-) [09:42] runasand, i think, it was only a message that the patch was not applied. it wasn't an error [09:42] ah [09:43] I use CDBS for simple common scenarios and dh 7 when I need more fine-grained control [09:43] mostly [09:44] ! [09:44] simple, and CDBS, are not two concepts that I would use together :-) [09:44] toabctl: ah :) [09:44] Heh. [09:45] Well, it allows ffor very short debian/rules files [09:45] maxb, im new to debian packages and cdbs and simple patch system are great for me.. [09:46] maxb, i don't know much about makefiles and all that stuff. so cdbs is good to start. [09:46] toabctl: yep, looks good to me! :) [09:47] dholbach, and what to do now? [09:47] can i test the buildprocess with pbuilder? [09:48] toabctl: yep [09:48] toabctl: or with simply running debuild [09:49] 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] Is there a way to automatically install build-dependencies for a given source package or unpacked package directory? [09:49] maxb> Same with dh 7 [09:50] Indeed, I favour traditional dh [09:50] although at least it doesn't hide away build steps... hmm [09:50] LucidFox: sudo apt-get build-dep for a package in the archive or /usr/lib/pbuilder/pbuilder-satisfydepends in the source tree [09:50] sudo /usr/lib/... [09:50] ooh, running pbuilder-satisfydepends [09:50] clever! [09:50] Is pbuilder-satisfydepends used on a .dsc? [09:50] LucidFox: no, just in the source tree should be fine [09:51] And won't it leave pbuilder-satisfydepends-dummy installed? [09:51] /usr/lib/pbuilder/pbuilder-satisfydepends-gdebi then :) [09:51] should be faster too [09:52] pbuilder's dependency resolution used to be really slow before they swithed to the pbuilder-satisfydepends-dummy system [09:57] There's IRC for emacs? O_O [09:58] LucidFox, i'm waiting for emacs to get a decent text editor [09:58] Old joke :p [09:58] LucidFox, the old ones are the best [09:58] ^_^ [09:58] * LucidFox switches back to Eclipse [09:58] LucidFox, and since i can't use duke nukem forever jokes anymore... [09:59] You mean Duke Nukem Dead Forever? [09:59] whatever happened to eclipse packaging effort? what i saw made it sound like a new tarball is the coming of the apocalypse [09:59] directhex> There was a preliminary 3.4 package in December 2008, last I know [10:00] I've heard that the Eclipse build system is the stuff of nightmares [10:00] The Eclipse plugin system is a mess. [10:00] I updated my home installation recently and broke SVN support. [10:01] 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] p2? [10:02] That piece of evil regression-laden mess that replaced the Update Manager [10:02] Oh. [10:02] Yes LS [10:02] * :S [10:03] and DEPENDENCY HELL [10:03] in all caps [10:05] although I only use Eclipse when I actually need a full-featured IDE. [10:05] 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] It's totally only worth it for the code assist, refactoring, etc. [10:06] * LucidFox nods [10:06] yes, I can't imagine writing Java without it [10:07] silly overly verbose language :-) [10:07] I like it. [10:08] Oh, I use it a lot too, and its.... ok [10:08] I'm actually thinking of rewriting my website in Java from PHP [10:08] I often want to beat Sun around the head with a cluestick though [10:09] What for? [10:09] Little stupidities like: there's no way to do mkdir, and find out why it fails, if it fails [10:10] oh [10:10] 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] (short of spawning an extra thread) [10:11] 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] These are not huge impenetrable stumbling blocks. They are just hideous warts [10:18] 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] Ewwww, JSP [10:19] maxb, doesn't java have a binfmt wrapper? [10:19] LucidFox, i can easily say something more "ewww" than JSP. watch this: [10:20] 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] i tell a lie, i still fail to grasp the central asp.net paradigms [10:22] Wicket is indeed rather lovely [10:22] perhaps packaging something would help. i wonder if i could find a dfsg-free wiki or blog to package [10:25] 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] LucidFox, well, i did ASP in you yoof, but ASP and ASP.NET only share a name, nothing else [10:26] YES [10:26] Just like ADO and ADO.NET [10:27] mok0: hi! are you around? [10:27] aye [10:27] bug #193393 [10:27] Launchpad bug 193393 in ubuntu "Please sync aften package from debian-multimedia.org" [Wishlist,In progress] https://launchpad.net/bugs/193393 [10:27] i uploaded the package to REVU [10:28] quadrispro-acer1: ah, a revu request... :-) [10:28] yeah [10:28] quadrispro-acer1: I will take a look at it later [10:29] ;) ok tr [10:29] * thx === fta_ is now known as fta [10:30] I thought packages from debian-multimedia.org could be uploaded directly to NEW? [10:31] Hello, can someone review sabily-keyring: http://revu.ubuntuwire.com/details.py?package=sabily-keyring [10:32] LucidFox: I think its's not "legal", because debian-multimedia isn't debian, so we need to review them before uploading [10:32] 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] 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] directhex: sorry for the late: congrats! and welcome aboard :) [10:35] quadrispro-acer1, thanks [10:37] 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] for new packages, that is [10:39] directhex> yes, that's bsically it === dpm_ is now known as dpm [10:45] well, I'd at least advise you to review the licenses and debian/copyright [10:48] That goes without saying, james_w :) [10:48] well, judging by some of the things that end up in NEW, I'm not so sure :-) [10:49] ^_^ [10:52] hi [11:11] hmm, the new REVU workflow proposal looks really promising to me, I really like it [11:11] hmm? workflow proposal? [11:11] got a link? [11:11] * Toadstool high fives whoever worked on this [11:11] hyperair: https://wiki.ubuntu.com/REVUWorkflowProposal [11:12] Toadstool: I agree, it looks nice :) [11:15] speaking of reviewing, it's been so long since I didn't do any... I feel rusty :) [11:15] I would if I could :] [11:39] oh right... I can't advocate packages, nevermind [13:17] if the packaging is changed from debian native to normal, it should be shown correctly in revu, right? [13:18] 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] 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] jmehdi: have you fixed the copyright-issues and stuff? and what about the warning/notice that's shown on revu? [13:28] aboudreault: fire ahead ;) [13:31] 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] loic-m_: I've added a copyright at the beginning of the java files, should I add something else? [13:35] jmehdi: only thing I see is that you're saying "please refer to the copyright file". It's not the same [13:36] nothing in Ubuntu policy requires a copyright notice in every source file [13:36] loic-m_: I did the same thing as the gnome-do team did [13:36] jmehdi: ok [13:36] there's no reason for that to cause a rejection at the revu stage [13:36] some *upstream* organisations require this, e.g. GNU, but it would be crazy for Ubuntu to do so [13:37] 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] 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] loic-m_: that's not Ubuntu's problem [13:37] loic-m_: all we need is clear and consistent licensing [13:38] cjwatson: it is when the original uploader moves away and someone has to update the package [13:38] 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] loic-m_: what does that have to do with copyright status? [13:38] loic-m_: you do not need this information as a packager [13:38] cjwatson: spending 10+ more hours tracking a svn because else you can't also maintain it in Debian it a pain [13:38] loic-m_: what does that have to do with copyright status? [13:39] cjwatson: I've seen packages rejected from DD because the copyright in the source files is severely outdated (missing names) [13:40] 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] cjwatson: and people in Debian dropping their ITP because upstream didn't want to correct it [13:40] loic-m_: as a Debian developer, you need to reproduce copyright notices from upstream [13:40] loic-m_: you don't need to do better than upstream [13:41] loic-m_: *shrug* those people are wrong and should have been persistent [13:41] cjwatson: I'll need to read debian-policy again ;) [13:41] see e.g. http://lists.debian.org/debian-policy/2009/03/msg00270.html [13:41] "We do not require people to wade through $VCS commit logs or mailinglist [13:41] threads to find out who wrote each single line of code." [13:41] Good morning [13:42] just through all the source files, when AUTHORS is out of date [13:43] directhex: All you need to go through the source files for is difference licenses. [13:43] https://edge.launchpad.net/~ubuntu-6had <-- What the heck? [13:43] 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] 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] LucidFox: uuuuhm :p [13:44] 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] LucidFox: seems to me that Joey Hess might be justifiably annoyed about that [13:45] I'm not aware that anyone from Ubuntu helped him to write dh7 at all [13:46] _Andrew: the dctrl-tools package has useful search tools [13:46] <_Andrew> thanks [13:46] http://img76.imageshack.us/img76/3616/ubuntu.jpg -- ^_^ [13:49] runasand: haha. wave the magic wand [13:49] Hobbsee: yeah ;p [13:49] <_Andrew> The package "funguloids" says it depends upon "ogre-plugins-cgprogrammanager" however there is no such package? [13:49] O_O [13:49] runasand: "IT support. have you tried turning it off and back on again?" [13:50] Hobbsee: \o/ [13:50] Hobbsee: the it crowd rocks :) [13:50] :) [13:50] indeed! [13:50] Hobbsee, i had to do that to a car once. [13:50] Hobbsee, i had to reboot the engine to make the stereo stop sounding like a bad Am radio [13:50] hah. nice! [13:51] Hobbsee, not really :| [13:51] 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] _Andrew: There is such a package, it's just never built, IIRC. [13:53] * runasand wonders what "et al" means [13:53] Is it still required that changelog for a new package only contain one entry? [13:53] runasand: probably nothing, but I sometimes use it as "and all" ;) [13:53] loic-m_: think so [13:53] kmdm: ah :) [13:53] _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] tsk. unbuildable packages [13:54] <_Andrew> I think the bug I filed (284750) changes that [13:55] It's non-free/multiverse anyway [13:55] tsk. non-free [13:56] _Andrew: Yes. That would do it. [14:02] loic-m_: do you see any other problems with my webstrict package? === _neversfelde is now known as neversfelde [14:11] jmehdi: your changelog should only had one entry AFAIK [14:12] 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] jmehdi: keep the top entry (1.4...), just copy/paste in it the entries from 1.3... (unless you droped the patches) [14:14] loic-m_: should I keep the version? (1.4-0ubuntu2) [14:14] loic-m_: to upload again on revu should I put 1.4-0ubuntu3? [14:14] :) ScottK [14:18] jmehdi: no, keep everything at 0ubuntu1 since only the upload to Ubuntu repositories (= not REVU uploads) counts in Ubuntu [14:18] loic-m_: ok, that's what I thought [14:18] jmehdi: (that's different than on Debian) [14:19] jmehdi: I didn't have the time to really check, but you seem to have addressed all of persia's concerns [14:19] loic-m_: ok, is it correct: http://pastebin.ubuntu.com/171631/ [14:20] 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] loic-m_: ok, and how is made the final approval? [14:21] jmehdi: looks ok to me [14:21] jmehdi: you need to convince two MOTU to review and advocate your package [14:22] loic-m_: ok [14:22] 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] 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] 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] jmehdi: yes, in a comment it's good [14:24] loic-m_: ok [14:24] jmehdi: changelog un-necessary > unnecessary [14:25] loic-m_: ok ;) [14:26] Heya gang [14:26] bddebian: hi [14:26] Hi freeflying === Gaboooo is now known as GaboB [14:28] dae gabo! [14:28] e aii scotinho!!! [14:28] vamo fludááááá [14:28] 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] loic-m_: (that's why I increased the version number last time) [14:31] runasand: it's short for "et alii", Latin for "and others" [14:31] cjwatson: ah, thanks! :) [14:32] jmehdi: you need to force the upload : dput -f ...... [14:33] loic-m_: so simple ;) [14:34] 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 === asac_ is now known as asac [14:37] 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] Hello! I have fixed an archive rejection for http://revu.ubuntuwire.com/p/scantailor - would anyone like to review/readvocate? Thanks! === azeem_ is now known as azeem [15:42] hello, i've built a working deb file [15:42] and everything appears great on jaunty [15:42] i'm concerned however about it being backwards compatible [15:43] 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] 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] azeem: this is a binary that the company i'm working with requested -- its not source sadly [15:45] 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] directhex: interesting [15:46] ni|: why do you need to support 8.10? [15:46] ni|, generally speaking, a package is compatible between releases as long as its dependencies are well written and still true [15:46] i mean i only have 3 really [15:46] unfortunatley one of them is qt4 [15:46] and qt3 is all that is present in 8.04 [15:46] then you have a problem, don't you [15:46] yes i do [15:47] directhex: but i suppose i could do some finagling [15:47] qt 4.4.0 is in hardy-backports [15:47] directhex: you suspect that the important line is the depends line in control [15:47] so you could simply insist that people have backports enabled [15:47] directhex: yes, thats what I was thinking [15:47] this was a painless experience :P [15:47] thanks a lot [15:48] 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] There is Qt4 in Hardy. [15:53] -backports [15:53] oh, wait [15:53] i'm misreading p.u.c [15:53] I mean in the release pocket. [15:53] hardy has 4.3.4 [15:53] Even Dapper has some version of Qt4. [15:54] i think the ABI question holds even truer then - make sure you build against the "right" version of Qt4 [15:54] assuming some degree of ABi backward-compatibility [16:06] assume , hrm , lets break this word down ... ass-u-me .... ass ( out of ) u ( and ) me [16:07] lol === cjwatson_ is now known as cjwatson [16:51] ScottK: it looks like boost1.38 needs similar patches as the ones in boost1.37 to enable python2.6 [16:51] savvas: I'd expect so. [16:52] * ScottK hasn't looked [16:53] there is a related bug at debian, but it's marked as wishlist: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=523901 [16:53]