=== kiko is now known as kiko-afk
=== pochu_ is now known as pochu
=== tuantub_ is now known as tuantub
=== marvelous is now known as wonderful
=== danbhfive1 is now known as danbhfive
[01:50] <blizzkid> lo all. I saw there is python-twitter but couldn't find one for identi.ca, so I hacked python-twitter for identi.ca. Would this be something interesting to include in Ubuntu?
=== cprov is now known as cprov-zzz
=== keylocker is now known as leleobhz
[05:32] <micahg> can someone verify that I did this sync request bug properly before I subscribe ubuntu-main-sponsors? bug 400410
[05:32] <ubottu> Launchpad bug 400410 in nmap "please sync nmap to version 5 from debian unstable" [Wishlist,New] https://launchpad.net/bugs/400410
[05:38] <StevenK> The Debian maintainer just requested one ...
[05:38] <micahg> ah, didn't see the bug, sorry, I filed this as a wishlist a month ago
[05:39] <micahg> wait, was it this bug 415730
[05:39] <ubottu> Launchpad bug 415730 in nmap "[Wishlist] Nmap 5 in Karmic (dup-of: 400410)" [Undecided,New] https://launchpad.net/bugs/415730
[05:39] <ubottu> Launchpad bug 400410 in nmap "please sync nmap to version 5 from debian unstable" [Wishlist,New] https://launchpad.net/bugs/400410
=== wonderful is now known as vorian
[05:40] <micahg> no, I didn't see it
[05:40] <micahg> StevenK: so, should I do anything with the bug I filed?
[05:44] <StevenK> micahg: I'll sort it out, hold on
[05:44] <micahg> ok
[05:44]  * micahg was hoping to get a sync bug right after messing up so many times :)
[05:46] <micahg> ah
[05:46] <micahg> now I see it
[05:46] <StevenK> micahg: Fixed
[05:47] <micahg> thanks
[05:49] <micahg> good thing I asked
[05:49] <micahg> would've screwed up another sync request
[06:12] <qiyong> is there spanish ubutnu channel?
[06:14] <Flannel> qiyong: #ubuntu-es
[06:15] <qiyong> Flannel: thanks
[07:58] <dholbach> good morning
[08:22] <stochastic> what does it mean to 'ack' a bug?
[08:23] <dholbach> acknowledge, approve
[08:23] <stochastic> i.e. upload a fix?
[08:32] <directhex> stochastic, depends on the type of bug
[08:33] <stochastic> directhex, can you explain, or is there a page definition somewhere?
[08:35] <directhex> stochastic, usually acks are used in ubuntu for bugs requiring sponsorship - i.e. the bug gets ack'd to say "yes, this should happen"
[08:35] <\sh> moins
[08:36]  * stochastic thinks he understands now
[08:38] <stochastic> so it would be kosher to ask if a motu could ack Bug #325004 and Bug #415680  ??
[08:38] <ubottu> Launchpad bug 325004 in denemo "Upgrade denemo package from 0.7.7 to 0.8.6" [Undecided,Confirmed] https://launchpad.net/bugs/325004
[08:38] <ubottu> Launchpad bug 415680 in tap-plugins "upgrade to new upstream version 0.7.1" [Undecided,New] https://launchpad.net/bugs/415680
[08:42] <directhex> stochastic, the second one, i'd say yes. the first one it looks like there's still ongoing discussion with dholbach
[08:42] <stochastic> directhex, okay thanks for clarification
[08:43] <directhex> i'll test-build tap-plugins
[08:43] <dholbach> I didn't assign denemo to myself, so if you want to go ahead and grab it, just do it
[08:46] <juanje> dholbach: Hi :-)
[08:46] <juanje> dholbach: Do you mind to check the changes to the package we are reviewing the other day? http://revu.ubuntuwire.com/p/nautilus-md5sum ;-)
[08:47] <directhex> dholbach, nah, still needs looking over. i'll take care of tap-plugins since it looks like a simple upload
[08:51] <directhex>   Uploading tap-plugins_0.7.1-0ubuntu1.dsc: done.
[08:51] <stochastic> thanks directhex
[08:51] <directhex> stochastic, ^^
[08:51] <stochastic> directhex, ^^ ;P
[08:54] <directhex> that's my good deed for the month. i think i need a lie down
[08:58] <stochastic> dholbach I'd love to sort out any issues still left on the denemo bug, should you have the time.
[08:58] <frandieguez> Hi to all, I have a question regarding the creation of deb packages. I'm making a virtual package for 32 and 64 bits platforms, but for 64 bits doesn't exist one package. Does exist a standarized method for solve this issue at debian/control file?
[08:59] <directhex> frandieguez, is it a missing build-dep or a missing binary package?
[08:59] <frandieguez> @directhex the main problem is that I have made a package for easy-installing of Chipmunk program
[09:00] <frandieguez> The problem is that at 64 bits platforms the program doesn't work
[09:01] <frandieguez> So, I can't do a package for chipmunk for 64 bits platform and the virtual package that has to include the chipmunk package isn't consistent
[09:04] <directhex> if the app doesn't work on amd64, why make a package for it for amd64?
[09:08] <frandieguez> @directhex let me explain. I have made a package that collects programs for my pupils like (gcc, gdb, netbeans.... and others), this packge is a virtual package that depends over the rest
[09:09] <directhex> metapackage. a virtual package is something else
[09:09] <directhex> probably your easiest option is to Recommend: the package which isn't on all arches
[09:10] <directhex> recommends are pulled in when they can be
[09:10] <frandieguez> @directhex additionally I have made a package for chipmunk program http://www.dcc.uchile.cl/~lmateu/CC41C/chipmunk.html
[09:10] <frandieguez> @dorectjex good point!
[09:12] <frandieguez> @directhex that works perfectly!
[09:17] <directhex> stochastic, ftbfs on itanium
[09:18] <stochastic> directhex, yes I see, but previous versions also ftbfs on itanium
[09:18] <stochastic> so I assume it's an issue with the code, I will forward the log upstream
[09:18] <directhex> please do
[09:22] <slytherin> frandieguez: when defining dependencies you can specify architectures like this ' gcc [!amd64], netbeans [!sparc]'
[09:27] <frandieguez> @slytherin with [!amd64] parameter you mean "install gcc package unless you are on amd64 platform", isn't it?
[09:28] <slytherin> frandieguez: right.
[09:28] <slytherin> in simply words, no dependency on gcc on amd64 platform
[09:28] <frandieguez> thanks, this solution is more elegant
[09:31] <slytherin> frandieguez: you can also specify multiple arch like this - [amd64 sparc] (only on amd64 or sparc) or [!amd64 !sparc] (all platforms other than amd64 or sparc).
[09:49] <stochastic> can any motu with a spare minute take a look at http://revu.ubuntuwire.com/p/a2jmidid ?
=== j^_ is now known as j^
=== dholbach_ is now known as dholbach
=== Guest60921 is now known as santiago-ve
=== ShadowChild is now known as lukjad007
[11:33] <dholbach> juanje: done
[11:36] <dholbach> stochastic: replied
[11:48] <juanje> dholbach: :-)
[11:48] <juanje> dholbach: Thanks :-)
[11:49] <j^> anything that can/needs to be done to get oggvideotools accepted? http://revu.ubuntuwire.com/p/oggvideotools
=== keylocker is now known as leleobhz
[12:24] <juanje> dholbach: I agree with your comments. I've already changed the package and I did the upload again. There is something else we need to do to have the package accepted?
[12:25] <dholbach> I'll take another look
[12:26] <juanje> dholbach: thanks :-)
[12:38] <dholbach> juanje: approved it, now you need a 2nd ACK
[12:40] <stefanlsd> juanje: whats the url?
[12:40] <juanje> dholbach: Thanks :-)
[12:40] <juanje> stefanlsd: http://revu.ubuntuwire.com/p/nautilus-md5sum
[12:41] <logari81> what is the normal process for removing a part of an upstream tarball, just manually removing it from the orig.tar.gz? should the exclusion also be considered in a get-orig target or in the watch file?
[12:42] <juanje> dholbach: thank you so much. I've learned a lot of datails to have a look with this package. I'll check the others I have in queue :-)
[12:42] <dholbach> super :)
[12:44] <slytherin> logari81: What do you mean by manually? It is preferred that get-orig-source will give you the correct .orig.tar.gz as it is supposed to go in distro. So yes you should handle removal there.
[12:47] <juanje> dholbach: one question about your last comment
[12:47] <dholbach> fire away
[12:48] <juanje> dholbach: the Standards-Version is not the debian-policy version?
[12:48] <juanje> the package's version I mead
[12:48] <dholbach> it is
[12:48] <juanje> I mean
[12:48] <logari81> slytherin: ok, I am trying to find an example package corresponding to such a case, just to be sure
[12:48] <dholbach> seems we have debian-policy and lintian out of sync :)
[12:49] <juanje> dholbach:  I just checked with rmadison and told me there is 3.8.2.0
[12:49] <slytherin> I believe there is already 3.8.3 of policy
[12:49] <juanje> in karmic
[12:49] <juanje> ops
[12:50] <juanje> dholbach: so then I should put 3.8.2 or 3.8.3 for karmic?
[12:50] <dholbach> just leave it
[12:50] <dholbach> like it is
[12:50] <juanje> ok
[12:51] <juanje> dholbach: but for the other packages? just to know the good one
[12:52] <dholbach> I hope somebody will sync/merge debian-policy
[12:52] <dholbach> then we should be good again
[12:54] <juanje> me too :-P
[12:54] <juanje> :-)
[13:14] <juanje> Could anyone review this package http://revu.ubuntuwire.com/p/mount-systray ?
[13:14] <juanje> thanks
[13:14] <juanje> :-)
=== kiko-afk is now known as kiko
[13:15] <slytherin> juanje: usually Friday is the day when you can go announcing about your packages on REVU.
=== proppy1 is now known as proppy
[13:23] <juanje> slytherin: ohhh... I didn't know. I'm sorry. I've announced my packages here sometimes but nobody say nothing, I guess that was because I did the worng day... I didn't know it was a special day for that. I'm sorry
[13:24] <stochastic> dholbach, replied/fixed issues on Bug #325004
[13:24] <ubottu> Launchpad bug 325004 in denemo "Upgrade denemo package from 0.7.7 to 0.8.6" [Undecided,Confirmed] https://launchpad.net/bugs/325004
[13:24] <dholbach> stochastic: I'll take a look when I get back from lunch
[13:24] <dholbach> maybe somebody else has the time to check it beforehand?
[13:25] <stochastic> dholbach, I'm not in that big of rush, I'm off to bed now (but I'm worried about feature freeze so don't forget about it please :)
[13:25] <dholbach> alright :)
[13:25] <dholbach> sleep tight
[13:32] <iulian> Oh look, it's dholbach!
[13:50] <slytherin> juanje: no need to be sorry for that. :-)
[13:55] <jbernard__> iulian: thanks for the lua-iconv upload, I really apprecite it
[14:04] <iulian> jbernard__: Don't mention it. :)
[14:46] <dholbach> nxvl, nhandler, james_w: do we need to reschedule tomorrow's Packaging Training session too?
[14:46] <james_w> reschedule?
[14:47] <dholbach> https://wiki.ubuntu.com/Packaging/Training
[14:47] <james_w> I don't see one scheduled?
[14:47] <dholbach> there was one
[14:47] <dholbach> DktrKranz'
[14:49] <DktrKranz> yes, but I can't host it, I'll travel tomorrow
[14:50] <dholbach> ok
[14:50] <DktrKranz> sorry for the short notice, but it has been a surprise for myself too
[14:51] <dholbach> no worries Luca
[14:51] <dholbach> who of any of the release teams would like to talk a bit about freezes, release schedule and stuff?
[14:51] <dholbach> 18:00 UTC
[14:52] <dholbach> I can't because I'll be in the ubuntu global jam meeting at the same time
[14:53] <dholbach> any other packaging related topic will do too
[15:05] <Sam-I-Am> howdy
[15:06] <Sam-I-Am> wandered over here from #ubuntu-server with some packaging questions...
[15:06] <Sam-I-Am> when building a package from source, what determines which files get copied from the original source tree into debian/build ?
[15:06] <bddebian> Heya gang
[15:07] <maxb> Sam-I-Am: Fundamentally, it's whatever files get copied by the execution of debian/rules targets
[15:08] <maxb> Often debian/rules will delegate to debhelper dh_* commands for most of that
[15:08] <Sam-I-Am> yeah...
[15:08] <Sam-I-Am> so openldap copies most of its tree into debian/build... except 'contrib'
[15:08] <Sam-I-Am> stuff is getting built in contrib... just back in the main source tree which is a problem
[15:09] <Sam-I-Am> trying to move that into debian/build
[15:11] <maxb> Hrm... "debian/build" ? What is that?
[15:11] <maxb> The usual directories are debian/tmp and debian/$(BINARY_PACKAGE_NAME)
[15:11] <Sam-I-Am> the directory which gets the openldap source for building
[15:11] <Sam-I-Am> at least with openldap
[15:11] <maxb> Hrm. Quirky buildsystem
[15:12] <Sam-I-Am> y.. yeah
[15:12] <Sam-I-Am> i dont think i'm about to change that part :)
[15:23] <Sam-I-Am> maxb: i'm still not sure how its copying those files
[15:23] <Sam-I-Am> its not obvious to me
[15:35] <logari81> how should I interpret the two licenses contained in the following header:
[15:35] <logari81> http://pastebin.ubuntu.com/255767/
[15:35] <logari81> are they combined with an OR or with an AND condition?
=== korn_ is now known as c_korn
[17:09] <jtimberman> Can a second MOTU advocate take a look at CodeRay, trying to get it in for Karmic. http://revu.ubuntuwire.com/p/coderay
[17:12] <Ampelbein> jtimberman: i'll have a look
[17:12] <jtimberman> Thanks!
[17:18] <Ampelbein> jtimberman: uploaded.
[17:18] <jtimberman> Awesome!
[17:24] <pochu>                                They both like KDE, they both work
[17:24] <pochu> for Canonical, they both like Karaoke and they just started
[17:24] <pochu> a Country band.
[17:24] <pochu> One of the above is not true.
[17:24] <pochu> heh
[17:36] <logari81> I am packaging a library (getfem) which in its orig.tar.gz contains the sources of another library (superlu) in a separate directory. I ve realized though, that superlu exists in ubuntu as a standalone package. I am wondering if I can/should delete the superlu folder from the original tarball. Since the superlu version provided with getfem partly suffers from missing copyright headers it would be nice if I could get rid of it.
[17:37] <logari81> I ve tried to find a similar case looking for *-dfsg source packages but I couldn't find a similar example
[18:28] <fabrice_sp> bddebian, in case you didn't noticed: I'v just uploaded again aptoncd. It should be ok this time :-)
[19:26] <bddebian> fabrice_sp: Uploaded, thanks!
[19:27] <fabrice_sp> really?
[19:27] <fabrice_sp> thanks a lot bddebian !
[19:27] <fabrice_sp> you're my hero! :-)
[19:27] <bddebian> No, thank YOU :)
[19:29] <fabrice_sp> by the way, how can I take over the actual maintainer? Asking him to orphan the package, or through Debian Bug #484637 ?
[19:30] <ubottu> Debian bug 484637 in aptoncd "aptoncd: should this package be removed?" [Important,Open] http://bugs.debian.org/484637
[19:34] <bddebian> fabrice_sp: If he is OK with you taking it over, it's just a matter of changing yourself to the maintainer and noting it in debian/changelog.  You could probably close #484637 with that changelog entry too if you wanted.
[19:34] <geser> fabrice_sp: ask in #debian-devel on OFTC, they should know better their processes than us :)
[19:35] <fabrice_sp> geser, you're right. Sorry about that 'debian' noise :-)
[19:40]  * DktrKranz cheers bddebian, our brave ftp-assistant!
[19:41] <jtimberman> mathiaz: ping
[19:44] <bddebian> heh
[19:56] <mathiaz> jtimberman: hey
[19:57] <jtimberman> mathiaz: saw your comments on merb.. for the rules file, can those items be handled in the next release? as is the rules bundles the packages just fine. I can add the readme.source of course.
[19:59] <mathiaz> jtimberman: did you try to remove all the rules from the file?
[19:59] <mathiaz> jtimberman: to me it seems that all the code in the rules file is pretty much a cut'n paste from the pkg-ruby-rb cdbs class
[20:02] <jtimberman> mathiaz: per suggestion from one of the debian-ruby-extras folks i copied an existing package (couldn't say off hand at this point which one :))
[20:13] <mathiaz> jtimberman: right - it doesn't seem trivial
[20:14] <mathiaz> jtimberman: so we can defer it to a later release
[20:14] <jtimberman> great
[20:14] <jtimberman> I'll upload w/ the README.source added
[20:14] <mathiaz> jtimberman: great. thanks
[20:20] <jtimberman> mathiaz: should be uploaded in a moment
[20:47] <mathiaz> jtimberman: is it normal that merb requires rails?
[20:48] <jtimberman> No.
[20:48] <mathiaz> jtimberman: when installing one of merb package rails gets pulled in
[20:48] <jtimberman> Really??
[20:48] <mathiaz> jtimberman: yop
[20:48] <mathiaz> jtimberman: http://paste.ubuntu.com/255899/
[20:49] <mathiaz> jtimberman: but it's not  problem with the merb packaging
[20:49] <jtimberman> Hmm.
[20:49] <mathiaz> jtimberman: it's probably one of its dependency that recommends rails
[20:49] <jtimberman> Yeah.
[20:49] <mathiaz> jtimberman: and recommends are installed by default
[20:49] <mathiaz> jtimberman: this can be fixed post-FeatureFreeze
[20:49] <jtimberman> what packages did you specify to install?
[20:50] <jtimberman> 'merb'?
[20:50] <mathiaz> jtimberman: http://paste.ubuntu.com/255900/
[20:50] <mathiaz> jtimberman: ^^ one of this package is probably recommending rails
[20:50] <mathiaz> jtimberman: merb-core and merb-slices
[20:50] <jtimberman> ok
[20:53] <jtimberman> http://paste.ubuntu.com/255903/
[20:54] <jtimberman> mathiaz: and http://paste.ubuntu.com/255904/
[20:54] <mathiaz> jtimberman: hm - interesting
[20:54] <jtimberman> yeah what is a 'ruby 4.2' ?!
[20:56] <jtimberman> thats bizarre, that looks like a binary program package, but its a completely different version than 'ruby'
[20:56] <mathiaz> jtimberman: http://paste.ubuntu.com/255906/
[20:57] <mathiaz> jtimberman: http://packages.ubuntu.com/karmic/ruby
[20:57] <mathiaz> jtimberman: This package is a dependency package, which depends on Debian's default Ruby version (currently 1.8.x).
[20:57] <jtimberman> Indeed. Weird that the version is 4.2.
[20:59] <mathiaz> jtimberman: yeah - it's just that the numbering scheme isn't related to the actual version of ruby it depends on
[20:59] <mathiaz> jtimberman: it basically is a meta-package
[21:00] <jtimberman> yeah. So this rails...
[21:01] <mathiaz> jtimberman: so what's left now is stompserver and chef
[21:02] <mathiaz> jtimberman: we'll look at the rails depency later - first focus on getting all the package in the archive in time for FeatureFreeze
[21:03] <jtimberman> Yes.
[21:03] <jtimberman> mathiaz: sounds good to me :)
=== lukjadOO7 is now known as lukjad007
[21:28] <fabrice_sp> ScottK, I'm fixing openturns for bug #411189. Should I subscribe u-u-s, or you will take care of my debdiff?
[21:28] <ubottu> Launchpad bug 411189 in openturns "Please remove boost1.35 source and all binaries from Karmic" [High,In progress] https://launchpad.net/bugs/411189
[21:32] <fabrice_sp> i've subscribed u-u-s. Have to go now. Bye
=== cprov is now known as cprov-afk
=== j^_ is now known as j^
[22:48] <ScottK> Good.
[22:48]  * ScottK is on vacation right now.
[23:45] <stochastic> if a script is licensed under http://creativecommons.org/licenses/by/3.0/ would that be able to be included in the repositories?
[23:50] <jtimberman> mathiaz: got stompserver updated
[23:51] <james_w> stochastic: yes, though it's not a great code license
[23:52] <mathiaz> jtimberman: great - I went through a first review of chef
[23:52] <jtimberman> mathiaz: going through it now, thanks :)
[23:55] <mathiaz> jtimberman: stompserver looks much better now
[23:55] <jtimberman> mathiaz: :)
[23:55] <mathiaz> jtimberman: thanks for sorting out the options with absolute path
[23:55] <mathiaz> jtimberman: one last important bit is to use the upstream tarball
[23:55] <jtimberman> Yeah, only trouble was determining the most elegant consistent way to do that.
[23:55] <jtimberman> it should be in there?
[23:55] <mathiaz> jtimberman: there isn't any diff.gz file
[23:56] <mathiaz> jtimberman: http://revu.ubuntuwire.com/p/stompserver
[23:56] <mathiaz> jtimberman: the only files are stompserver_0.9.9-0ubuntu1.tar.gz and the .dsc
[23:57] <mathiaz> jtimberman: what should be available is a .orig.tar.gz, .diff.gz and .dsc
[23:58] <jtimberman> ooh... orig.tar.gz, not orig.tgz?
[23:59] <mathiaz> jtimberman: what you need is stompserver_0.9.9.orig.tar.gz (which is the upstream tarball)
[23:59] <mathiaz> jtimberman: http://rubyforge.org/frs/download.php/31579/stompserver-0.9.9.tgz.
[23:59] <jtimberman> yeah, i have stompserver_0.9.9.orig.tgz (not .tar.gz)