[00:02] cool. Any idea how I pull a source package out of the debian NEW queue? POX says he uploaded a new versions to debian, but that was only half an hour ago, and normally I pull stuff from the mirrors [00:04] warner, no cvs ? [00:04] warner: See kirkland's mail. [00:04] err vcs [00:05] iulian: got it [00:07] warner: I'm heading to bed now. I'll take a glance at them tomorrow morning. [00:07] Night. [00:07] am I correct in thinking that once a package is advocated-for and "uploaded to NEW", that any subsequent fixes should bump the -0ubuntu1 version number? [00:07] thanks! [00:07] (I may upload a new tahoe that relaxes the pycryptopp version requirement) [00:07] Excellent. [00:07] (to allow it to run with the pycryptopp that was just synced) [00:09] xnox: xiphos (from mentors) has changes outside debian/ : http://paste.ubuntu.com/260098/ [00:10] xnox: there are also some lintian warnings: http://paste.ubuntu.com/260099/ [00:10] xnox: especially this should be fixed: W: xiphos: binary-or-shlib-defines-rpath ./usr/bin/xiphos /usr/lib [00:13] * slangasek eyes a package in NEW that has license detail broken out for all the auto-generated autotools files [00:13] would someone be so kind as to explain to me my chances of getting my packages into karmic, and what i should be doing right now to improve those chances [00:14] slangasek: Yikes. That must have taken ages. [00:14] soren: dunno, but it's ugly clutter [00:14] I hope no one's recommending detailing those in debian/copyright [00:14] given that the copyright doesn't attach to the binaries [00:14] slangasek: thanks for all the input on libcgroup, I'm making those changes now [00:15] jbernard: sure thing [00:15] warner: per kirkland's mail we should post a sync-request for foolscap. Having glanced at https://wiki.ubuntu.com/SyncRequestProcess , I think the best way to do this is for you to run requestsync and then change https://bugs.launchpad.net/foolscap/+bug/419510 to reference the newly created sync-request ticket. [00:15] Launchpad bug 419510 in foolscap "please update to foolscap-0.4.2" [Undecided,New] [00:16] zooko: ack [00:16] ok, I got the debian .dsc, and am I'm figuring out how to run requestsync now [00:17] kirkland: am I correct in assuming that I must run 'requestsync foolscap*.dsc' ? [00:17] or does it just take a package name [00:18] warner: http://manpages.ubuntu.com/manpages/karmic/en/man1/requestsync.1.html [00:18] got it, apparently it takes a package name [00:18] = a .dsc [00:18] which is unfortunate, because the new version of foolscap is still in incoming.debian.org, and requestsync isn't seeing it yet [00:21] so I guess I have to wait for the next dinstall run, at 01:52UTC, in about 90 minutes [00:25] openQRM-Matt: hey - still around? [00:25] mathiaz: yep [00:26] openQRM-Matt: the orig.tar.gz has different md5sum from the one published on sf [00:26] yes, e.g. we have debian/ in our svn in the original sources, the package sources are created with the "debsource" target [00:28] mathiaz: since we keep everthing in the svn the package is based on the current latest svn. [00:29] openQRM-Matt: does that mean that openqrm_4.5.orig.tar.gz is not 4.5 but an svn snapshot instead? [00:29] mathias: also every change applied for the packaging enhancements + fixes are directly commited upstream from either the team or myself [00:30] mathiaz: yes, it is post 4.5 including the packaging fixes [00:31] openQRM-Matt: the diffstats says a lot of other stuff has been changed too. [00:31] openQRM-Matt: so the it doesn't include *only* packaging fixes. [00:32] mathiaz: sure, we are working on it heavily, anyway the changes are "almost" only in the packaging because the newer stuff is removed by "debsource" target [00:35] openQRM-Matt: a diffstat between the official 4.5 release tarball from sf and the 4.5.orig.tar.gz from revu shows: [00:35] openQRM-Matt: 1830 files changed, 95602 insertions(+), 113404 deletions(- [00:35] openQRM-Matt: I'm a bit confused by these numbers [00:36] openQRM-Matt: hm nm [00:36] openQRM-Matt: I was wrong [00:36] mathiaz: this is all what we have changed for the ubuntu packaging. Please check our svn commits in the last weeks, they were lots of changes which are directly commited upstream to our svn [00:38] openQRM-Matt: now that I've correctly setup the directories, I end up with: 835 files changed, 5424 insertions(+), 23226 deletions(-) [00:39] mathiaz: still a lot, i know, parts of it is the new Amazon Cloud integration ... but I am sure you want to have especially this feature in karmic :P [00:39] openQRM-Matt: oh - I'm not discussing the changes. [00:39] openQRM-Matt: I'm concerned that this is *not* 4.5 [00:40] openQRM-Matt: it seems more to be an svn snapshot from the next release [00:40] openQRM-Matt: and thus should be named so [00:40] mathiaz: ok, right, this is not exactly 4.5 but 4.5 + aws + ubuntu packaging changes [00:40] mathiaz: we can name it 4.6 if you want ... will require some more changes and a rebuild [00:41] openQRM-Matt: oh well - that would be even better [00:42] mathias: do we still have time for that ? [00:42] mathiaz: i mean i have time :) just worried about the FF [00:42] openQRM-Matt: right. [00:43] openQRM-Matt: hm... would it make sense to call this 4.6~beta1? [00:43] mathias: anyway, i can freeze the svn as you uploaded it and release 4.6, then we just need to update the version number [00:44] mathiaz: i am fine with beta since there are many serious changes e.g. because of the FHS compliance [00:44] openQRM-Matt: ok - so I'll rename to 4.6~beta1 [00:45] openQRM-Matt: and you'll iron out everything to make a proper 4.6 release in the comming week [00:45] openQRM-Matt: ? [00:45] mathiaz: :) yep, sounds good [00:46] openQRM-Matt: is there one single place to rename 4.5 to 4.6beta1? [00:47] openQRM-Matt: what would be required to change to 4.6-beta1 or something like that? [00:47] mathiaz: dch should be enough, openQRM will still display 4.5 but i can fix this as soon as you want [00:47] openQRM-Matt: ok - I'll just update dch then [00:47] openQRM-Matt: and we'll fix the rest after FF [00:48] mathiaz: great, testing the dch update here [00:48] openqrm (4.6~beta1-0ubuntu2) jaunty; urgency=low [00:48] mathiaz: right ? [00:49] openQRM-Matt: 4.6~beta1-0ubuntu1 [00:49] openQRM-Matt: karmic [00:49] mathiaz: eh, karmic, of course :) [00:50] mathiaz: and 4.6~beta1-0ubuntu1 instead 4.6~beta1-0ubuntu2, stupid me, getting late here [00:51] kirkland: so, you said that you synced pycryptopp-0.5.14 from debian into ubuntu a little while ago. Is there an equivalent to incoming.debian.org where I could look at the packaging you used? [00:51] In about 10 minutes, slangasek will be leading a Packaging Training session in -classroom about Feature Freeze and Freeze exceptions. With FF coming up tomorrow, this would be a good session to attend [00:51] nhandler: will the FF at the beginning or end of day? [00:51] nooooooo [00:52] requestsync is broken [00:52] Laney: then you have to do it by hand. [00:52] NOOOOOOOOOOOOOOOOO [00:52] bdrung: I don't know. iirc, it has happened around late afternoon UTC in the past, but there is no set time [00:53] I think a few people in -devel at least are treating it as Thursday 0 UTC. [00:53] nhandler: ok, then i hopyfully get promoe in ( https://bugs.launchpad.net/ubuntu/+bug/419576 ) [00:53] Launchpad bug 419576 in ubuntu "Sync promoe 0.1.0-1 (universe) from Debian unstable (main)." [Wishlist,New] [00:54] bdrung: I'll look now and ACK it if it looks good [00:54] nhandler: thanks [00:56] openQRM-Matt: openqrm-4.6~beta1 uploaded to karmic [00:56] nhandler: in 17 hours i could probably subscribe ubuntu-archive directly [00:56] openQRM-Matt: now it will have to go through the archive admins [00:56] mathiaz: Yeaaaahhh ! [00:56] bdrung: :) [00:57] mathiaz: Thank you so much ! Will care about the follow ups [00:57] bdrung: And that package is very new. /me needs to go hunting for the .dsc since pull-debian-source won't work on it yet [00:57] nhandler: http://incoming.debian.org/promoe_0.1.0-1.dsc [00:57] psh [00:57] i'll upload it myself instead [00:58] much easier than copy and pasting [01:02] nhandler: it is really new. the upstream release is two days ago and the package was uploaded to Debian 11 hours ago. [01:02] nhandler: gone throught NEW in one day is very fast. [01:03] bdrung: That is very true. I've had packages take several months to get through Debian NEW. [01:03] nhandler: the normal waiting time was one till two month. [01:04] bdrung: But they also just got some new ftpmasters, so that might explain the faster times [01:04] yes [01:08] matthiaz: Just want to check if you still need me the next hours ? otherwise I would go to bed now and be back tomorrow, Really excited :) [01:09] openQRM-Matt: nope - you can go to bed [01:09] bdrung: ACK'd [01:09] nhandler: thanks [01:10] mathiaz: thanks man, have a greate day === zooko is now known as zooko2 === zooko` is now known as zooko [01:18] what's the ubuntu council's irc chan? [01:22] do they have an own channel? [01:22] I'm not sure [01:23] or someone in charge of the mailing lists is who i'm really after [01:23] binarymutant: https://lists.ubuntu.com/ [01:24] bdrung, is there no irc chan for the group in charge of that? [01:24] canonical sysadmins channel [01:24] i forget what it's called [01:24] directhex, ty [01:25] #canonical-sysadmin [01:25] isn't it? [01:25] * Laney doesn't dare join to check [01:27] i hear they keep deathclaws at the gates! [01:29] ScottK: I'm interested why you appear to have filed lots of requests for new package syncs that were synced from Debian a couple of days ago [01:29] ScottK: not a criticism, but it seems to indicate some flaw in the tools that it didn't notice the packages were already in [01:30] if you pass -n to requestsync it doesn't check [01:30] afaik [01:31] that might be it [01:48] hm, another question.. tahoe functions correctly with python2.4/2.5/2.6, however there are a bunch of deprecation warnings when run under 2.6 (some of which originate in the dependencies, so are harder to fix) [01:49] would it be reasonable to hardwire the /usr/bin/tahoe shbang line to #!/usr/bin/python2.5 ? and do.. something, to the debian/control file, to express this requirement? [01:50] warner: I think the package would be less likely to pass NEW if it hard-coded python2.5; the deprecation warnings from the deps should be treated as bugs in those deps, and should in any case not stop the package from using python2.6 [01:51] * warner nods [01:51] I guess it's just noisy, and that's ok [01:54] and, for the tahoe-lafs package (which I imagine would go into "universe"), should the Maintainer: be ubuntu-devel-discuss, or motu-devel? I've received conflicting suggestions. [01:56] 'update-maintainer' these days seems to only use ubuntu-devel-discuss [01:57] ok, I'll go with that.. thanks [01:57] and the changelog references https://lists.ubuntu.com/archives/ubuntu-devel/2009-May/028213.html === micahg1 is now known as micahg [03:01] james_w: IIRC I was using p.q.d.o to check package status between Ubuntu and Debian. [03:01] I certainly didn't know they were already in. [03:01] Apologies to kirkland for having to try to sync them. === warner is now known as warner_away === santiago-pgsql is now known as santiago-ve [05:02] is licensecheck in ubuntu-dev-tools? [05:03] porthose: devscripts. It's a debian tool. [05:03] aah ok thx ScottK [05:08] hello anybody home? [05:10] ding dong [05:10] beep beep [05:10] hehehe [05:11] HONK!!! [05:11] ;) [05:11] i just want to ask something common for you guys [05:11] This channel is a question-free zone, sorry [05:11] there may only be silence, and humour, here. [05:12] where to ask question about packing deb? [05:12] what ch [05:12] * Hobbsee was joking [05:12] you got me [05:12] would be a bit silly if no questions could be asked here [05:12] ok are you ready for the question? [05:12] deb questions are welcome [05:12] hehe Hobbsee is on a roll :) [05:13] ok [05:13] * Hobbsee is about to go grab some lunch, but there are others around too [05:13] porthose: yup [05:14] i was packing cclfox(cybercafe timer) but it needs liccls which a separate lirary that also needs libfox.. is there a way to link this? [05:14] libccls [05:14] library [05:56] scriptwarlock, if libccls and libfox are need at build time use the Build-Depends: field in debian/control, if they are not required at build time use the Depends: field [05:57] ok im opening the control let me try it [06:04] how important is the dh_shlibdeps [06:07] scriptwarlock: It is generally useful, to set up dependencies on any shared libraries your package needs for you, automagically. You will discover any mistakes regarding missing depends when you test build your package in a pbuilder or similar chrooted test build environment :) [06:08] yeah right im not thinking of commenting this, hehhe.. [06:09] and heres the error: dpkg-shlibdeps: failure: no dependency information found for /usr/local/lib/libccls.so.0 (used by debian/mkahawa-srv/usr/bin/mkahawa). [06:09] dh_shlibdeps: command returned error code 512 [06:09] make: *** [binary-arch] Error 1 [06:10] that my problem since libccls contains libfox1.6-dev and libfox1.6-0 === warner_away is now known as warner [06:38] good morning === porthose is now known as porthose|AFK [08:36] sebner: ahem, "Format-Specification: http://dep.debian.net/deps/dep5" is not what http://dep.debian.net/deps/dep5 says to use ;) [08:43] sebner: sorry, I have to reject monobristol - your debian/copyright doesn't include a warranty disclaimer, which has to be attached to all object-code distributions of GPL works (GPLv3, §4 as referenced by §6) [08:44] sebner: if you upload with this fixed, I'll accept it w/o a freeze exception on the grounds that it was all-but-ready by the deadline [09:02] slangasek: How do you interpret this line from specification - "Note that the unwieldy length of the URL should be solved in future by hosting the specification at a shorter URL (including the specification version)." [09:03] slytherin: it means "we know the current URL you have to specify, is ugly, nostra culpa, but do it anyway" [09:03] slangasek: is it me or do the examples in DEP-5 suggest that you don't need the warranty disclaimer for the GPL? [09:03] I though it meant that now that the specification is available at http://dep.debian.net/deps/dep5 you should use that url. [09:03] james_w: [09:04] i.e. the "Simple" example [09:05] james_w: yep, looks like Yet Another Bug [09:05] I'll beat it with a very large hammer this weekend [09:05] cool, thanks === micahg1 is now known as micahg [09:32] Can someone help me with a pbuilder problem I have? -> http://forums.linuxmint.com/viewtopic.php?f=32&t=19782&p=183234#p183234 === Quintasan_ is now known as Quintasan === warner is now known as warner_sleep [09:41] sluimers: hopw is linuxmint related to ubuntu? [09:42] I'm trying to get pbuilder to work so I can put a program on my PPA, which is ubuntu related [09:43] and hope to put it on ubuntu universe later if I figure out how [09:43] And linux mint itself is related to ubuntu as ubuntu is to debian [10:00] do I need a FFe for a new package synced from Debian now? [10:02] pochu: yes [10:07] is FF already in effect? [10:07] yes [10:08] geser: stupid, isn't it? :P === sebner changed the topic of #ubuntu-motu to: Karmic Feature Freeze is in effect now! | Want to get involved with the MOTU? https://wiki.ubuntu.com/MOTU/Contributing | Sponsor queue: http://is.gd/2y76G | http://qa.ubuntuwire.com/ftbfs | http://qa.ubuntuwire.com/debcheck === dholbach_ is now known as dholbach [10:22] I thought it started tonight :( [10:30] sluimers: but you are not using ubuntu mirror in your pbuilder configuration. And nobody uses Ubuntu mirror when setting up pbuilder for Debian. [10:30] okay [10:30] then I'll ask in linuxmint again [10:31] sluimers: as I said problem is that you are using a linuxmint error when trying to setup ubuntu pbuilder. Simplest thing you can do is use Ubuntu mirror. [10:34] okay thanks [10:36] any motu release member can look at this FFe request? bug 419482 [10:36] Launchpad bug 419482 in ubuntu "[FFe] Please sync libmimic (NEW) 1.0.4-2 from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/419482 === happyaron_ is now known as happyaron === torkel_ is now known as torkel [12:55] pochu: ping pong [12:56] * pochu wants a ping pong table again [12:56] stani: yo [13:14] hi pochu, so what looks the best to you, getting phatch in ubuntu now or doing an early FFE? [13:16] stani: we already need a FFe :( [13:17] stani: should be easy to get it approved if we ask for it soon though [13:17] stani: what's needed to get it uploaded into Debian? [13:19] phatch didn't seem to start [13:19] POX said do a debuild and then install the packages to reproduce it === keylocker is now known as leleobhz [13:21] pochu: from POX: http://paste.pocoo.org/show/136440/ [13:21] stani: it worked for me when I started if from sources, so something's wrong in bin/phatch probably, I'll try to debug it today [13:22] i.e. after work [13:22] POX: ok, thanks [13:23] pochu: as we need a FFE already (I hoped today was not yet so), it is better to see tonight with POX [13:23] dholbach: If you didn't see, I managed to get a session together last night (special thanks to slangasek) [13:28] kjkjkjkjkjkjkj [14:00] hi folks [14:00] huhu sistpoty|work :) [14:00] hi sebner [14:01] sistpoty|work: FF is already in effect. I changed the topic so this should be clear :) [14:01] excellent, sebner :) [14:04] sistpoty|work: heh, just discovered that you are in motu-release. Let's see when you'll get some cookies :P [14:04] heh [14:05] sebner: well, a new nexuiz upstream release is about to be uploaded, so if there were an FFe once it's in unstable, I'm quite sure I'd severely test it :P [14:06] sistpoty|work: uhhh, finally new upstream version? I'm the MOTU who volunteers gladly and I suppose you take the motu-release part :D [14:07] hm... I'm doing s.th. wrong... I guess I should advocate bug fixing right now ... *g* [14:07] sistpoty|work: heh, true *but* we are speaking about _nexuiz_ :D [14:07] heh [14:08] sistpoty|work: I'm wondering if it's coincidence that they make new upstream releases always towards our FF? O_o [14:08] hah [14:08] Hello sistpoty. [14:10] hi iulian [14:12] sistpoty|work: please let me know if you hear something new about nexuiz :) [14:12] sebner: sure, will do [14:12] :) [14:12] Just did my first post FF look at apt-cache unmet and it looks suprisingly good. [14:13] :) [14:17] sebner: maybe you'd like to upload a no-change rebuild of fteqcc? (if I understand it right, that could work around bug #408528) [14:17] Launchpad bug 408528 in launchpad-foundations "Packages build but fail to upload due to email address issue" [Undecided,Confirmed] https://launchpad.net/bugs/408528 [14:19] It does sound like it would. [14:20] thanks for confirming my idea ScottK === cprov-afk is now known as cprov [14:30] sistpoty|work: Please add a comment on the bug if it works. I will do same for lucene2. [14:30] slytherin, sistpoty|work, ScottK: You will work around the issue as long as the Changed-By is different. === highvolt1ge is now known as highvoltage [14:30] So yes, a no-change rebuild will fix it. [14:31] excellent, thanks wgrant [14:38] Folks: pycryptopp-0.5.14 was synced from Debian yesterday and it is in the karmic queue: https://launchpad.net/ubuntu/karmic/+queue . A few hours ago feranick changed this ticket to mark the ticket as invalid for ubuntu: https://bugs.launchpad.net/ubuntu/+bug/419519 [14:38] Launchpad bug 419519 in ubuntu "please sync pycryptopp-0.5.14 from Debian" [Undecided,Invalid] [14:39] Why would this ticket be considered invalid for ubuntu? [14:39] It should have been marked fix released [14:39] But it doesn't have much practical effect either way. [14:40] Okay, just curious. [14:40] Is it "released" when it is in the queue, or only after it has been archived? [14:40] syncs are closed when the sync is done [14:41] there is no process to auto-close them when the package actually lands in the distro [14:41] I see, thanks. [14:41] and due to the volume of syncs doing that by hand would send us all batty [14:41] Is there anything I can do to encourage Archivists to include pycryptopp from the queue into Karmic? [14:42] zooko: if it's in the queue, just wait. [14:42] Okay. [14:42] There's nothing needed, unless there is a technical reason to reject it, it'll get in. === menesis1 is now known as menesis [15:37] should i be closing the [needs-packaging] tickets i opened for packages that are now in karmic? [15:38] yes please, if the package is in karmic [15:40] ideally you should have closed in your changelog [15:41] geser: Close in changelog doesn't (I don't think) actually work. [15:41] Or did they fix that? [15:41] I meant the lp: #xxx closing [15:42] Close in changelog (at least used to) only close bugs against the package in question and since needs-packaging bugs are packageless (by definition) they couldn't be closed that way. [15:42] Yes. [15:42] oh, doesn't REVU inform about missing bug in the changelog? [15:42] geser: I have the correct syntax in the changelog. [15:43] than ScottK is probably right [15:48] Cool, closing now then. Thanks! [16:08] How would I proceed if I need to adjust /etc/php5/apache2/php.ini to make a packaged php application work? [16:08] sed /etc/php5/apache2/php.ini -iorig -e 's/^safe_mode *=.*/safe_mode = Off/;'? [16:09] in the debian/rules file? [16:11] flohack: no, you mustn't adjust another packages config files [16:11] flohack: can't you fiddle with safe_mode throught the apache config? [16:12] flohack: then you could just drop a file into sites-available... [16:13] sistpoty|work: Any hint how I can set that in an apache config file? [16:14] flohack: I must admit, I'm not entirely sure if it's possible... (nor how it's done) [16:14] Is is allowed to drop a file in /etc/php5/apache2/conf.d ? [16:14] flohack: http://us2.php.net/manual/en/ini.php [16:15] flohack: yep [16:15] flohack: google just told me: php_admin_flag safe_mode Off [16:15] (with the first hit for apache2 config php safe_mode) [16:15] sistpoty|work: I tried 'php safe mode apache'... [16:16] heh [16:16] flohack: BTW safe_mode is deprecated in PHP 5.3 [16:17] micahg: Is there a replacement? Or a workaround....btw I currently have no idea what it actually does...would have to look that up [16:19] flohack: the manual isn't too specific [16:19] http://us3.php.net/manual/en/features.safe-mode.php [16:20] It's a security measure that never quite worked right per the manual [16:36] Daviey: regarding your question about generating debhelper input files, try groff, which generates debian/groff-base.files (ugh, I know, one of these days I'll convert it from dh_movefiles to dh_install) [16:37] it does this because some of the file names are version-dependent and I don't want to have to bother updating the list by hand for each new upstream version [16:38] Daviey: the '%: %.in' rule in debian/rules is responsible for this (I might have to change that when I move to dh(1) ...) === ShadowChild is now known as lukjad007 [16:57] The cdbs manual says updating generated autotools files at build time is "*strongly* discouraged". Is an acceptable alternative to run "cdbs-edit-patch 90-update-autotools" and then "autoreconf", generating a patch that does the updating? [16:58] mzz: yes, that's what the desktop team does in a lot of cases [16:58] mzz: one patch for the change to configure.ac (for example), another patch for the autoconf stuff [16:58] in most cases you'll just have to regenerate one of them and it's clear where each part comes from [16:58] yes, that's what I was doing. Thanks, just making sure I wasn't missing some trick. [16:59] and yes, autoreconf is a bit of a sledgehammer. Perhaps I should run just the autotools I actually need? [16:59] sounds good [16:59] thanks again :) [16:59] ROCK ON! [17:00] in an ideal world we'd just use distributed version control and didn't bother with autogenerated files and tarballs, just upstream check outs and no patch systems :) [17:01] (perhaps I should leave well enough alone though. Just trying to get rid of some "dependency on .... could be avoided" warnings) [17:02] mzz: that's very likely a patch that you can submit upstream afterwards [17:02] oh, another one. This thing uses boost. Is the correct approach to just depend on libboost-dev, and not manually on libboost1.x-dev for the highest x it still works with? [17:02] you mean build-depends? [17:02] err, yes, of course. [17:03] there's a few other folks in here who have more experience with boost than I do [17:03] geser or scottK maybe? [17:03] dholbach, is the MC meeting in one hour? [17:03] RoAkSoAx: I sent you an email about it - unfortunately not, we can't make quorum :-( [17:04] RoAkSoAx: if you could respond with times that usually work for you, we'll work something out real real quick [17:04] I'm sorry [17:04] ah, it would help if I read. "This package is a dependency package, which depends on Debian's default Boost version" in karmic. So just using whatever version libboost-dev gives me seems to be correct. [17:04] mzz: Generally I think it's better to explicitly build-depend on a specific version of boost so you don't change accidentally. Since we don't do binNMUs most of the reasons Debian has an unversioned libboost-dev don't apply to us. [17:04] ahh [17:05] * sistpoty|work heads home... cya [17:05] dholbach, ok awesome, I just saw the email >) [17:05] ScottK: obvious next question: which version? The latest and greatest or the default one? [17:05] mzz: I'd use 1.38. [17:05] Failing that, the one that works. [17:05] ScottK: forgot to mention this is currently a jaunty package. Iiuc libboost-dev is still an actual package there? [17:05] Yes. It is. [17:06] For Jaunty I'd use 1.35. [17:06] but I guess I can just pick libboost1.38-dev there too, and it'll do the right thing on both jaunty and karmic. [17:06] That was the supported version there. [17:06] That works too. [17:06] err, no, libboost1.38-dev doesn't exist there, 1.37 is the latest. I'll just stick to 1.35 for now. Thanks! [17:07] OK. I guess I rembered wrong. [17:10] well, I thought I'd seen 1.38 there too, and I'm actually using a jaunty system, I guess you're mainly working on karmic, not jaunty :) [17:14] ScottK: hmm, libmimic's copyright has [17:14] libmimic is under LGPL (see also /usr/share/common-licenses/LGPL): [17:14] This library is free software; you can redistribute it and/or [17:14] modify it under the terms of the GNU Lesser General Public [17:14] ... [17:14] * ScottK looks again. [17:14] is that ok? [17:14] it's before the license (yeah, unusual) [17:14] ScottK: http://packages.debian.org/changelogs/pool/main/libm/libmimic/libmimic_1.0.4-2/python-libmimic.copyright [17:15] pochu: It's fine. I completely missed it because it's well hidden. [17:15] yeah :) [17:15] ok, thanks for looking at it [17:15] Please comment in the bug. [17:16] ok [17:17] done === goshawk_ is now known as goshawk [20:09] Hi there, I'm trying to build something in PPA. I've got a build error -> http://launchpadlibrarian.net/30909504/buildlog_ubuntu-jaunty-i386.ika_0.62~15_FAILEDTOBUILD.txt.gz [20:09] the erorr -> /usr/bin/ld: cannot find -lwx_gtk2_xrc-2.8 [20:10] I don't understand what I'm missing here [20:10] I've got libwxgtk2.8-dev in my build-dependency [20:10] It compiles fine on my own compputer [20:17] guys, what is the naming convention for git versions? I'm creating x264 package from git commit 448b1387254bbf186b83db0fd393477ea1d01a55 [20:18] sluimers: guessing from jaunty's package content, it looks like it should be wx_gtk2u_xrc-2.8? === micahg1 is now known as micahg [20:24] * sluimers slaps his head [20:24] Thanks === warner_sleep is now known as warner [21:00] x1250: You can't use commit identifiers because they aren't monotonically increasing. I generally use date, link 0.5.0~git20090827. [21:00] There is not, however, a hard and fast rule. [21:01] ScottK, thanks [21:08] wow, lp (as viewed by firefox) just made some funny effects when changing the bug state, but didn't actually want me to confirm what I just did [21:09] * sistpoty suspects higher magic going on [21:29] did I miss feature freeze for the NEW queue already? [21:30] Yes [21:31] (see topic) [21:32] bummer [21:33] hm, so I'm just SOL until 10.04 yes? [21:34] Unless you come up with a really good reason for an FFe. [21:36] * sistpoty believes we should advertise ()ReleaseSchedule better [21:36] which is hard to for a game, I guess I'll just try and get it into debian for the 10.04 sync [21:36] well i knew feature freeze was today, but not when today it would happen [21:37] Generally freezes start at the start of the day they are announced for. [21:37] * ScottK has gotten hit by that before too. [21:37] good to know [21:38] if I want to maintain two versions of a package, lets say, ffmpeg, then I should have two working directories? one for karmic, with its own control, changelog, etc, and another one for jaunty? And should I change "karmic" to jaunty in the jaunty changelogs? [21:38] lamalex: funny, that reminds me of the argument some students bring up when failing a test (and having e.g. 39 out of 100 points and 40 means you succeed): "I'm missing just one point" [21:38] lamalex: the regular answer then is: "no, you're missing 61 points" === Richie is now known as YDdraigGoch [21:39] iulian, nhandler, and vorian: Please scrawl your opinion in Bug #419569 so we can get it overwith. [21:39] Launchpad bug 419569 in linux-rt "Please consider linux-rt to be bound by the kernel release process." [Wishlist,New] https://launchpad.net/bugs/419569 [21:56] if im going to just go for debian, should I still file a needs packaging bug? [21:59] lamalex: no need for that then === Richie is now known as YDdraigGoch [22:10] hello everyone, I guess you're dealing with multiverse as well, or should I ask somewhere else? (regarding an overdue critical security update) [22:11] zeco1: This is the place for multiverse too, although most of us give a higher priority to our time for free software. [22:12] great, thanks. It's about this situation here (Sun Java 6 update 15 not available in Jaunty and below since Aug 5) https://bugs.launchpad.net/ubuntu/+source/sun-java6/+bug/409559 [22:12] Launchpad bug 409559 in sun-java6 "version 1.6.0_15 is available " [Undecided,Confirmed] [22:13] It seems that this matter might need some extra attention since the people who were discussing it up to now were either unable or unwilling (count me in the former camp) === cprov is now known as cprov-afk [22:14] can anyone here point me to a guide on getting a new package into debian? [22:15] http://www.debian.org/doc/debian-policy/ ? [22:16] This is better: http://www.debian.org/doc/maint-guide/ [22:16] thank you much :) [22:17] anyone had success using snakefood to check runtime dependencies for python packages? it looks promising, but i haven't quite figured it out yet: [22:18] micahg: those are more for how to build my feb [22:18] s/feb/deb [22:18] i already know how to do that, but im not sure how to get my packages into debian's archive [22:18] hmm [22:18] * micahg doesn't remember where the pag eis... [22:19] do you know if i should be looking at Debian Maintainer or New Maintainer? [22:20] or neither [22:20]