[00:13] RAOF: I've been pounding away at this but can't figure it out. Can you explain how I should use uupdate, i'm getting the same error with it, if i go to the old source tree and do uupdate ../new-tarball.tar.gz [00:14] jgoppert: The simple fallback is: unpack the new tarball, and simply copy the debian/ directory from the old package to the new directory. [00:14] ok, i'll give that a shot [00:31] ok so gdal 1.5 conflicts with gdal 1.6, can i just install the header files to /usr/include/gdal-1.6/* or something instead? [00:35] hm requestsync doesn't work for syncing from contrib does it? [00:35] (for a NEW package) [00:36] jgoppert: Probably not, although this depends on the precise situation. Generally you don't want parallel installable -dev packages (which is where the headers go). [00:37] ok, well i want to package delta3d which depends on gdal1.6, so should i just install the so's? [00:38] RAOF: i guess maybe i could force a statically linked build of gdal and build delta3d against that? [00:40] like just put the gdal source under a 3rd party folder on delta3d, might get kind of ugly though [00:41] superm1: should do, with the -n flag [00:41] Laney, i tried with the -n flag and it still didn't even find it in contrib [00:42] sounds like a bug [00:42] Laney, test@dell-desktop:~$ requestsync -d sid -n --lp libvdpau lucid [00:42] E: The package 'libvdpau' does not exist in the Debian primary archive in 'sid' [00:43] http://packages.debian.org/search?keywords=libvdpau&searchon=names&suite=all§ion=all [00:44] jgoppert: Is there any particular reason why you wouldn't want to simply replace libgda's existing -dev package? [00:45] superm1: interesting, seems to be a bug in the lp import [00:45] works without --lp [00:45] (https://launchpad.net/debian/+source/libvdpau/+publishinghistory shows nothing) [00:46] or its just lagging [00:46] awesome [00:46] well as i look closer we need to have a delta to it anyway [00:47] at least for now [00:47] so maybe i'll just upload it to NEW myself with that delta [00:47] fun [00:48] it's stupid stuff too. the maintainer doesn't want to drop a depends on something that is in contrib (for debian) / restricted (for ubuntu) because the package isn't useful without it he says [00:48] blah [00:48] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558464 [00:48] Debian bug 558464 in libvdpau1 "Please don't put libvdpau1 in contrib" [Wishlist,Open] [01:04] wait what? Rejected: [01:04] libvdpau_0.3-1ubuntu1.dsc: Format is not 1.0. This is incompatible with dpkg-source. [01:04] how do i upload this to launchpad then? it's format 1.8 [01:06] superm1: Whine at #laundchpad-dev until they fix it. [01:06] gah [01:07] Although I didn't know about a 1.8 [01:07] 1.8?!wtf [01:07] * ScottK thought it was 1.0 or 3.0 as valid choices [01:07] anyhow [01:07] 3.0 support is coming [01:07] wgrant has been working on it [01:07] but its not 'flick a switch' - its more complicated than that [01:08] oh it is 3.0, just it says 1.8 in .changes [01:08] debian/source/format says 3.0 [01:09] lifeless, so is there an ETA then? does this means it's gonna fail just as hard on PPAs too? [01:09] it'll fail hard everywhere in LP until all the bits are in place [01:10] maybe for now so i can get this package in i should just revert it back to the old format for the ubuntu delta then [01:10] and hopefully whenever it gets merged and/or synced in the future launchpad will support it by then [01:11] superm1: Will you have orig.tar.gz md5sum problems later if you do that now? [01:11] * ScottK doesn't know enough about the new formats to know. [01:11] well luckily enough dont need to change the orig.tar.gz at all [01:11] so i dont expect so [01:11] .orig.tar.gz should still be the same, but there'll be a diff.gz again instead of .debian.tar.gz [01:12] the main things to watch will be if it uses patches [01:12] not at this point [01:13] then you may get away with uploading it as 1.0 format [01:23] yay. looks like i did get away with it as 1.0 format [01:23] so i'll just hope for now that by next time merging or syncing is necessary this is sorted out [01:24] oh this is probably why it didn't show up in the LP import yet too then [01:29] quite likely :) [01:29] one of those few times that you wish that debian wouldn't move so fast [01:34] it's not like the changes haven't been being discussed for long enough :s [01:35] lots of things get discussed & implemented several months/years later :) [01:35] I guess Debian moving at a normal rate is considered relatively fast? :P [01:36] Debian moves when & where it will [02:24] maco: ping [02:25] nigel_nb: i cant talk right now. i just did a nice clean install of karmic on mum's computer and now it won't bot [02:25] *boot [02:25] maco: kewl, some other day then :) [02:25] * maco throws pointy objects at GRUB [02:26] * nigel_nb stands in GRUB's defence [02:32] RAOF: if i replace libgdal 1.5 with libgdal 1.6 won't that break a lot of dependencies in karmic? [02:34] can anyone help, i want to package delta3d, but it depends on lib gdal 1.6, but karmic has lib gdal 1.5, whats the best course of action? [02:43] jgoppert: Package it for lucid [02:44] ScottK: lucid is still at libgdal 1.5, and i'm getting better at packaging but i'm not a pro yet, do i need a sponsor or something to do that [02:44] jgoppert: Yes, you will, but if we're going to switch, now's the time to do the transition in Lucid. [02:45] do i need to contact the debian maintainer? its got no ubuntu revision [02:46] jgoppert: That would be smart. We want to have the same versions in Squeeze and Lucid as much as we can. [02:46] * jdong grumbles about clock accuracy with handbrake fetch stamps [02:46] it wouldn't have killed them to use md5sums as a decision maker for whether or not to refetch [02:47] ok, build #8 of the evening. gym time while that chugs away [02:49] ScottK: If i am trying to deploy delta3d for a small network is there anyway around moving them all to lucid after the package has been updated? [02:49] jgoppert: You could backport the needed packages into a PPA [02:49] ScottK: Ok that should work. [02:50] ScottK: thanks [02:50] You're welcome [03:06] ScottK: There are like 3 other libraries that delta3d depends on that aren't in ubuntu, should we just add them to lucid? [03:07] jgoppert: Yes. That would have to come first. [03:07] ScottK: Can I recruit help somewhere, or a mentor to double check me and approve my packages? [03:08] all sponsors are responsible for checking and approving package changes [03:08] jgoppert: That's what we do here. You can ask questions here anytime. No need for a formal mentor to be assigned (although there is such a program) [03:08] the debian gmaes team might be helpful as well [03:09] jgoppert: ajmitch has a good point. It's called the Debian Games Team, but it's really Debian/Ubuntu. [03:09] should i package through debian first? [03:09] Ideally. [03:09] bddebian: Are you still doing Debian Games stuff? [03:10] Not as much as I should be but yes [03:10] superm1: My 3.0 branch is approved. It just needs to be merged, which means I need to get a new dpkg everywhere, and blah blah blah urrrrghhhh messy. [03:10] superm1: So it should be ready in a couple of days. [03:10] wgrant: that soon? excellent [03:10] bddebian: jgoppert is interested in getting a game packaged for Lucid (and potentially Squeeze) [03:11] bddebian: He's new, so be gentle. [03:11] thanks ScottK [03:11] Heh [03:11] ajmitch: LP 3.1.11 is meant to be happening on Wed 2200UTC, I believe. [03:12] But I need to check with $CANONICAL_PERSON how the dpkg upgrade on cocoplum is going. [03:12] hopefully without any problems or random segfaults [03:13] * ScottK is struggling to maintain silence on the topic. [03:13] "If you can't say anything nice, don't say anything at all" is an interesting theory, but really hard sometimes. [03:14] ScottK: I've heard of problems with backporting dpkg in the past, it's nothing specific to LP [03:14] ajmitch: No, my struggle is more about how unprepared LP is for this and my thoughts about how reasonable it is they didn't prepare. [03:15] I might also have some thoughts about how this reflects where distro support falls in their priorities, but I'm staying silent. [03:15] no, you're really not [03:15] ScottK: Well, I don't think anybody expected Debian to do it for many years. [03:16] (however I agree with your distro support comment) [03:17] the priorities seem to be enabling new & shiny ways to play with package branches at the moment [03:18] debian didn't expect to do it for years :) [03:18] So ScottK's problem is that LP people can't predict the future? [03:18] It's a release goal for Squeeze [03:18] lifeless: and of course there's the backlash against the change on d-d :) [03:19] ScottK: And release goals are always met... [03:19] ScottK: Hah. Strawman [03:19] Of course they aren't always met. [03:19] OTOH, it shouldn't have been a great suprise someone worked on it. [03:20] * maco ^5 StevenK [03:20] it was a surprise that there's already talk of switching the default format already [03:20] Really, this is Debian's fault for getting 4 ftpmasters in the same room for a weekend [03:21] maco: Heh, for which bit? [03:21] StevenK: cant predict the future [03:21] It took all of not very long at all to implement it. [03:21] wgrant: main problem being that dpkg-source is run outside the chroot? [03:22] ajmitch: That's the buildd side of things, yes. [03:22] But that's lamont's problem lalalala. [03:22] lucky lamont [03:24] * ajmitch would like try & get at least something landed into LP in the next release cycle [03:25] ajmitch: Ubuntu or Launchpad's? :-) [03:25] heh [03:25] LP, I've got stuff ready to upload to ubuntu when I get time :) [03:26] in other news, loggerhead hates me when I try & open 10 tabs of individual revisions [03:27] ajmitch: They have a contractor working on that. [03:28] good [04:06] wgrant, spectacular, thanks [04:12] anyone want to help with a debian sync request? [04:12] or should i file a bug [04:13] pace_t_zulu: File a bug [04:13] StevenK, ty [04:21] virtualbox-ose [04:21] https://bugs.launchpad.net/ubuntu/+source/virtualbox-ose/+bug/490193 [04:21] Launchpad bug 490193 in virtualbox-ose "Please sync virtualbox-ose 3.0.10-dfsg-2 (universe) from Debian testing (main)" [Undecided,New] === ripps_ is now known as ripps [05:09] can someone else take a peek at this buildlog? I must be going crazy. i don't see why it wouldn't be able to find the freetype library: http://launchpadlibrarian.net/36246886/buildlog_ubuntu-lucid-i386.mythplugins_0.22.0%2Bfixes22924-0ubuntu0%2Bmythbuntu4_FAILEDTOBUILD.txt.gz [05:20] superm1: That does look odd. Does it build OK locally (in your pbuilder chroot or similar) [05:21] well the same source builds nicely on the PPA for intrepid, jaunty, and karmic daily. i'm just setting up a lucid pbuilder locally to see [05:22] OK. So you might have found a bug in the libfreetype6 package for Lucid, or something along those lines. [05:22] there's a very small diff from the karmic to lucid freetype [05:22] but i wouldnt expect it to cause this kind of problem [05:22] http://launchpadlibrarian.net/35143239/freetype_2.3.9-5_2.3.11-1.diff.gz [05:23] oh it's a new version too [05:23] so that's gotta be where the problems are lying then [05:37] jmarsden, yeah it was a freetype bug. amazing what a misplaced period does. http://pastebin.com/f29be441d [05:37] i'll upload that to lucid and send a patch to debian [05:39] :) OK, glad you found it. Seems slightly odd that debian/libfreetype6.files needed to be hand edited for the new release at all, really... [05:40] I can see maybe adding some new lines for new files... but why edit that one? [05:46] Ugh... The copyright for so many of these files is written in French. [05:46] (2mandvd data files) [05:48] Ugh, the license terms for photo-libre.fr are: [05:48] "These photos are totally free and copyright free, but they can not be resold or used in any medium for commercial purposes." [05:48] How does "copyright free" mesh with "non-commercial"? [05:48] * LucidFox deletes these files [05:56] ...Gosh, this upstream needs to be educated what "free" as in free software means. [05:57] hahaha [05:57] license.txt for .png files: "All these events have been found on the internet and was under a free license allowing a free non-commercial redistribution. Other came from tuxpaint project (http://www.tuxpaint.org). If you own one or more images and you do not want it to be in this package you can write me at: gibault.stephane@wanadoo.fr and I will remove them." [05:58] i assume they mean gratis all over that [05:58] sounds like multiverse [05:58] Well, it depends on multiverse packages so it will go to multiverse anyway, but not before I clean up this copyright mess from "non-commercial" or unattributed image files. [05:59] The software itself is GPL2+. [06:00] wait a...does it... "i dont have the right to redistribute these, but lets pretend i do and that im giving you the right to do so"? [06:10] maco> I think the author just assumed that "non-commercial" is good enough to bundle with GPL software. [06:10] yeah [06:11] that the GPL is a non-commercial license is a common misconception too [06:13] LucidFox: How does "totally free" mesh with "but you can do X" [06:13] Flannel> Ask the author of photo-libre.fr, I'm confused. [06:14] So... 9 themes distributed under a French-language free license, 9 from a non-commercial "free" photo site, 25 completely unattributed. [06:14] In short, I had to delete 34 out of 43 themes. [06:15] ouchies [07:11] sounds fun [07:24] Okay, 2mandvd uploaded to REVU. [07:47] Is there a way to subscribe to REVU package uploads by mail or RSS? [08:09] maco: got the computer working? [08:09] i think so [08:09] great :) [08:11] how many pointy things did u throw at it :P ? [08:17] maco: will you have the time to mentor me through MOTU? === yofel_ is now known as yofel [08:54] LucidFox: got any spare time? http://revu.ubuntuwire.com/p/jansson :) [08:55] akheron> Just looked at it, was waiting for you to come back. :) [08:55] heh :) [08:56] Why is the -dev package so strangely declared? Contains soname number in the package name, and has Provides and Conflicts for libjansson-dev... [08:56] Why not just name the package libjansson-dev? [08:57] I mimiced it from somewhere [08:57] ^_^ [08:57] from some random debian documentation, I guess [08:57] I don't really know what's the best practice [08:58] the library package has the SONAME in it's name, so why the -dev package doesn't have [08:58] You'll only need Provides/Replaces for transitions. It's better to name the package libjansson-dev and drop the Provides and Conflicts lines. [08:58] ok [08:59] also, I wasn't sure about the document ID for doc-base [08:59] is "libjansson" ok, or does it even matter as long as it's unique [09:00] Doesn't, really. libjansson or jansson will do. [09:00] ok, good [09:02] Any other notes? I'll upload a new one shortly [09:09] akheron> Nothing else I can think of. [09:38] LucidFox: done [09:38] Thanks, looking... [09:38] It seems that my "shortly" equals over half an hour :) [09:41] akheron> The -dev.install file is still named libjansson0-dev.install. [09:41] It helps to build the package after making changes. ;) [09:41] argh [09:42] I did but didn't quite check it [09:53] LucidFox: fixed [09:53] :F [09:55] * LucidFox downloads and builds [10:04] akheron> Advocated! [10:13] <\sh> moins [10:24] LucidFox: thanks a lot! :) [10:46] Hi, I'm using dh_installexamples, and on postinst I'd like to gunzip one of the examples to /etc/my-package. But I've noticed that when the example is small, dh_installexamples doesn't gzip it! Is that true? Is there any standard way to uncompress/view a package's examples? [10:49] alkisg> gzip is done in dh_compress rather than dh_installexamples, so you can call dh_compress -Xfilename to ensure that the file in question is never compressed. [10:49] Thanks, looking... [11:02] Ah, I see where's the limit: "...files in usr/share/doc that are larger than 4k in size..." [11:33] ScottK, I'm going to migrate quassel to dh 7 and --with=kde, and eventually add support for double builds. Would it be better to file both in one debdiff, or wait until the dh 7 version is uploaded and only then work on double builds? [11:35] LucidFox: I'd prefer to see them as separate patches. Also Quassel in git has switched to gettext from translations. Next on my list was to switch to a gettextified quassel. If you could look at that with the dh7 stuff it'd be much appreciated. === neoXsys is now known as neoxsys [11:55] http://revu.ubuntuwire.com/p/linux-libre <-- Wow, that's a slightly oversized diff.gz. [11:56] LucidFox: I think the package is pretty much unsuitable for the archive in any case. [11:56] * LucidFox nods [12:00] * ScottK just left a comment to that effect on REVU. [12:02] LucidFox, OOo's is bigger! [12:02] Seriously? What is in there, tons of big patches? [12:02] LucidFox, OOo is... complicated [12:02] LucidFox, in short, "yes" [12:03] openoffice.org_3.1.1.orig.tar.gz 394,144.4 kB [12:03] openoffice.org_3.1.1-5ubuntu1.diff.gz 96,076.5 kB [12:03] It's a shame that the best free office suite out there in something so out of touch with both GNOME and the Unix philosophy. [12:03] s/in/is/ [12:04] if memory serves, orig is a tar-in-tar of upstream sun OOo (actually 15 upstream tarballs) [12:04] O_O [12:04] * LucidFox headdesks. [12:05] the patch set is a 214 meg diff [12:05] including a uuencoded copy of an entire icon set [12:05] ( ooo-build/src/ooo_oxygen_images-2009-06-17.tar.gz.uu |317713 +++++++++) [12:06] the diff is basically the entire go-oo patchset, including (e.g.) 334,000 lines of VBA test scripts [12:08] LucidFox, building OOo takes about 101 gig of space and 10 hours of core2duo [12:08] * LucidFox O_O [12:08] bah [12:08] 10 not 101 [12:09] oh, and lots of RAM too [12:17] directhex, if the diff includes the entire go-oo patchset, why not just build off go-oo sources? [12:18] LucidFox, no such thing, go-oo is just a patchset. despite claims by some individuals on some gutter press [12:18] LucidFox, it's just a big honkin' patchset [12:18] They do provide a tarbal on go-oo.org, no? [12:18] * tarball [12:19] the tarball contains their build system, but not the ooo source === dyfet` is now known as dyfet [12:45] On postinst, I'm generating a /etc/my-package/my-package.conf file. Upon uninstallation, when is the correct time to remove it? On prerm when "$1"=="purge"? (I'm worried about the /etc/my-package dir being correctly deleted if empty). [12:47] Or should I manually check and remove the /etc/my-package dir on postrm if it only contains my-package.conf? [12:48] Hmmm I don't see prerm called with "$1" == "purge"... Only postrm: http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html [12:51] why not postrm? [12:52] that's when conffiles are usually deleted [12:56] I think when postrm is called, the package files are already removed, [12:57] so I wanted to delete it beforehand, so that dpkg would remove the directory by itself, if that directory was empty (/etc/my-package) [12:57] Well I guess I can delete that directory myself, on postrm... [12:57] http://www.marga.com.ar/~marga/debian/diagrams/remove-purge.png [12:58] I don't know if "Conffiles are deleted" is in the right place there... [12:59] I only want to delete that file on purge, so I guess I don't have much choice... I'll do it on "postrm purge" [12:59] Thanks for the nice diagram! :) [13:32] How can have debuild run "autogen.sh" before running "configure" using CDBS? [13:34] Figured it out, thanks. [13:35] you probably want the DEB_AUTO_UPDATE_* stuff instead, lfaraone [13:35] that's the cdbsey way of doing these things [13:35] Hm. [13:37] Laney: how do I figure out whether I run libtoolize pre or post? [13:37] dunno [13:37] I suck at this stuff [13:37] And it looks like the script also runs "gtkdocize" as part of autogen. [13:37] well, it depends why you want to reautogen [13:38] Laney: upstream does not believe in shipping configure in git. [13:38] as they should [13:38] And their released versions are broken on the most recent version of GTK [13:38] it might be right to just run autogen.sh then - I was thinking you were doing an autoreconf [13:39] alternatively run it before you generate the orig (in your get-orig-source) [13:39] Laney: so I could do that with "DEB_CONFIGURE_SCRIPT := ./autogen.sh [13:39] use a full path [13:40] and make sure your clean target deletes the right stuff [13:41] Laney: hm. now it builds, but "install" is giving me errors. [13:41] Laney: http://paste.ubuntu.com/331694/ [13:47] lfaraone: Looks like it repeats some filenames on the install line [13:47] which causes the error [13:51] ttx: there? [13:52] slytherin: yes [13:52] Laney: hm. but it works when I "make install" it locally. [13:52] Laney: how would I go about fixing that? [13:54] check the autotools files to find out why it happens ¬_¬ [13:54] ttx: Are you planning to drop -gcj from recommends unconditionally in this cycle? There are no arch now where GCJ is main JDK. Also openjdk seems to work well on all arch. [13:55] all as in the ones I have tested, i386, amd64 and powerpc [13:55] slytherin: yes, see https://blueprints.launchpad.net/ubuntu/+spec/server-lucid-java-library-fixes [13:55] great, I will keep an eye [13:55] slytherin: though the change is not acceptable in debian so we need to find the best way of doing it (introduce delta or not) [13:56] hmm [13:56] slytherin: this is discussed in the spec, I'd welcome your input [13:56] slytherin: see 6.1 in https://wiki.ubuntu.com/LucidJavaCleanupSpec [13:58] slytherin: in all cases we get rid of the arch:any trick [13:58] ttx: Will check. [13:58] slytherin: thx [13:59] ttx: By the way, I am not sure how reasonable this request is but in future we should probably have a separate java component in archive reorg. So that we get rid of these dependency problems. === neoXsys is now known as neoxsys === ogra_ is now known as ogra === highvolt1ge is now known as highvoltage === martin456 is now known as m4rtin [14:59] ScottK> bug #490347 [14:59] Launchpad bug 490347 in quassel "Migrate to dh 7 and --with=kde" [Wishlist,New] https://launchpad.net/bugs/490347 [15:06] LucidFox: Diff looks good. I'll try to get it uploaded tonight. Thanks. [15:18] Heya gang [15:28] hi bddebian [15:52] Hi Laney === sommer_ is now known as sommer [16:40] hi i am learning packaging and I couldnt understand the *.ex files.Can anyone please explain it?Please [16:41] shankhs: those are example files, generally you want to get rid of them. [16:41] why? [16:41] You can use them as a template (if that file is needed) [16:42] when are templates neccessary? [16:42] most of them are not required for most packages. [16:42] they are ex(amples) :) [16:42] Daviey: thanx i got it [16:43] great! [16:45] When i see the changelog of hello file(in https://wiki.ubuntu.com/PackagingGuide/Basic ) i dont see any -0ubuntu1 or ubuntu written anywhere.Did I do anything wrong?Please [16:46] i am following https://wiki.ubuntu.com/PackagingGuide/Basic [16:47] My changelog is totally different from this one https://wiki.ubuntu.com/PackagingGuide/Basic [16:47] shankhs: Can you put your changelog's contents on paste.ubuntu.com? [16:49] jpds: http://paste.ubuntu.com/331820/ i tried dch once [16:55] hi [16:58] shankhs: It looks like you're suppose to create the -0ubuntu1 entry, simply change the -1 to -0ubuntu1. [16:58] ok [16:58] jpds: thanx [17:47] dholbach: hi! my ubuntumembers membership expired while I was on vacation. what is the best way to get it back? (my indirect membership via core-dev doesn't seem to give my cloaking, etc) [17:49] jdstrand_: that's weird - just send a quick mail to community-council@lists.u.c and I'll unexpire you [17:50] dholbach: ok, thanks [17:52] dholbach: sent [17:52] jdstrand_: Cloakes are just bad. You cannot be recognized after some years. [17:54] rcbwnka: A cloak is the text that replaces a person's hostname on IRC. Ubuntu members qualify for ubuntu/member/$username [17:55] Who cares ? [17:55] I thought the contributions made should be worth something. Not people taking cover ? [17:56] They appeared 2003, right along with Beagle.EXE and other microsoft things [17:58] rcbwnka: it's a nice touch. [17:59] Do libpam plugins need to be named accoridng to their soname version? (ie libpam-rainbow2 vs libpam-rainbow) [17:59] No, i shouldnt think so [18:00] so name is always "so" though ;) [18:00] so.number [18:01] But, itll make it easy to keep track of. should you not do so your app will never (or should never) see the day of light [18:02] app name: hello-there. Libname1: hello-there.1.x.x [18:02] Or better yet... [18:03] app name: hello-there. Libname1: hello-there-1.1.x.x [18:03] app name: hello-there. Libname2: hello-there-2.1.x.x [18:03] As specific as possible [18:04] rcbwnka: I mean should the package be named "libpam-rainbow2" or "libpam-rainbow"? [18:06] well, It seems to be a new version that will diverge enough from the original "rainbow" ? [18:06] To be a mayor version upgrade/release ? [18:07] Otherwise just call it the same. [18:07] Client / server ? [18:08] Then dont change the name, add a min-client-version. [18:09] rainbow six was a bit fun btw [18:11] lfaraone: seems ok to you ? [18:12] Write down what ever scheme you go for. [18:15] DktrKranz: ping === jdstrand_ is now known as jdstrand [18:49] randomaction: pong [18:50] DktrKranz: I'm going to request a sync of xotcl, are you ok with this? [18:50] bug 399157 [18:50] Launchpad bug 399157 in xotcl "Please merge xotcl 1.6.3-2(universe) from debian unstable(main)" [Wishlist,Incomplete] https://launchpad.net/bugs/399157 [18:53] randomaction: sure [18:53] ok, I'll convert this bug === ssweeny_ is now known as ssweeny === micahg1 is now known as micahg === Tonio__ is now known as Tonio_ [20:13] hello [20:20] where can I contact the developer of vmware-package package? [20:35] well, anyways [20:35] trying to install vmware-package 0.22 I'm getting: vmware-package: [20:35] Depends: libstdc++5 but it is not installable [20:37] TLF: there's a bug filed about it (bug 459286) [20:37] Launchpad bug 459286 in vmware-package "can not find dependencys" [Undecided,New] https://launchpad.net/bugs/459286 [20:37] oh, thanks, ubottu [20:40] anyway, this package was removed from Debian and will likely be removed from the next Ubuntu release === jono_ is now known as jono [21:06] TLF: That needs an ancient version of gcc that we aren't supporting anymore. It should have been removed already. [21:08] ScottK: and it is not possible to update the package? [21:11] TLF: No. It's not a Free software package, we only have binaries, no source [21:11] ScottK: oh, I though it was a open source program to install the binaries (vmware= [21:12] Right, but the binaries have to be built against a recent GCC and we don't have that [21:13] oh [21:13] that's ok then :) [21:14] from what I can see, vmware-package itself doesn't have the libstdc++5 dependency, which is partly why it didn't get picked up [21:49] bye [22:08] g [22:21] Hi [22:24] i'm trying to build a package an have the following error : http://pastebin.com/d7eebf6e1 but my log file is http://pastebin.com/d673c4a7a i really don't see where i do an typo error [22:24] someone can give me a clue ? [22:26] surfzoid: 1 too many spaces before the date [22:26] whoa is it so strict !! [22:26] oki [22:26] it can be :) [22:26] try it, I may be wrong [22:26] ajmitch: thanks [22:27] the other problem can be using tabs instead of spaces before the * [22:28] usually there's a blank line after the line with the version information, though I'm not sure if it's required or not [22:28] well, i discover the creasy stric build world :-) [22:31] ajmitch: is there a tool or an scite plugin who check debian file syntax or at least colour them ? [22:33] there are tools like dch which add the changelog entries, I use emacs however which has some modes for editing changelogs [22:33] this is an know format like verylog ? [22:34] sorry? [22:34] yes debian.changelog use an specif format or this a know one [22:35] it's a specific format documented in debian policy [22:35] if you take spec file for rpm, you can use shell syntax/format and color [22:36] http://www.debian.org/doc/debian-policy/ch-source.html#s-dpkgchangelog has the details, it's fairly basic [22:36] so i will play more with luky :-) [22:37] hey seem okay with your few tip, thanks a lot ajmitch :-) [22:38] debian world sound like an egg :-) [22:39] there are lots of useful tools around for packaging though [22:40] yes, using a simple text editor (my favorite) is no easy [22:42] bye and again thanks === NCommander is now known as Guest64268 [23:17]