[00:02]  * ScottK wonders if dtchen has graduated from the ranks of the young whipersnappers to the old and grumpy?
[00:03] <dtchen> grumpiness seems proportionate to the number of patches in debian/patches/
[00:05] <_16aR_> dtchen: lol
[00:07] <directhex> really? what's the threshhold from "normal" to "bah"?
[00:11] <_16aR_> Anyone already in the REVU group for package upload can review any package ?
[00:11] <jdong> directhex: you'd get a kick out of this... MonoDevelop 1.9.1, middle-pasting with an empty clipboard == NullPointerException
[00:11] <jdong> :D
[00:12] <directhex> jdong, srsly? that's been reported upstream?
[00:13] <jdong> directhex: I just experienced it and I don't feel like restarting X at this very moment to reproduce :)
[00:13] <jdong> (no innuendo intended)
[00:15] <dtchen> directhex: roughly, "when my eyes bleed"
[00:16] <dtchen> directhex: now, i can sustain quite a bit of "pos_adj = (pos_adj * runtime->rate + 47999) / 48000;", but there is a limit.
[00:17]  * directhex declares said limit to be "twelvety"
[00:20] <jdong> directhex: http://paste.ubuntu.com/113834/
[00:20] <jdong> confirmed.
[00:20] <jdong> you also can't undo pastes :D
[00:20] <directhex> jdong, and this is alpha 1?
[00:21] <jdong> alpha 2, 1.9.1
[00:21] <jdong> the latest tagged version with tarball
[00:21] <jdong> the mono stack was compiled from mono's project website sources
[00:22] <directhex> jdong, i think you should head to gimpnet
[00:29]  * nhandler remembers that today is the day MC nominations end. That means next week is a vote
[00:30] <EagleScreen> I have been learning basic Debian/Ubuntu packaging, I would like to become a MOTU member :D
[00:30] <nhandler> EagleScreen: Look at the channel topic for a link that explains how to get started
[00:30] <EagleScreen> yes, i am reading
[00:31] <EagleScreen> i am reading about REVU now
[00:34] <nhandler> EagleScreen: If you are just starting, you should try some other tasks like patching bugs before you try to package something from scratch
[00:36] <EagleScreen> i haven't got any program packaged from scratch for now..
[00:37] <EagleScreen> i know make patches, and rebuild source packages, i have some packages from another deb-based distributions which could be in Ubuntu
[01:14] <EagleScreen> is REVU only for entirely new packages?
[01:14] <ScottK> Yes
[01:15] <EagleScreen> what about one package that was in hardy but not in intrepid and jaunty by the moment?
[01:18] <nhandler> EagleScreen: Why did it get removed from the repositories?
[01:19] <ScottK> And is it in Debian?
[01:19] <EagleScreen> I supuse becouse it comes from Debian, and it was out of Debian archive temporary
[01:20] <EagleScreen> now it is in Debian unstable
[01:20] <EagleScreen> i am talking about reportbug-ng
[01:21] <EagleScreen> it has been ported from Qt3/KDE3 to Qt4/KDE4 and now uses more python modules as python-debianbts, python-debianbts is in jaunty.
[01:22] <EagleScreen> may be if it is now in Debian usntable, it will automatically merged to Ubuntu.
[01:22] <EagleScreen> but i am not sure
[01:24] <ScottK> What package are we discussing?
[01:25] <EagleScreen> i told you reportbug-ng
[01:26] <ScottK> Ah.
[01:26] <ScottK> Missed that.
[01:26] <ScottK> Why do we want it back?
[01:27] <EagleScreen> i think it is a good package, someone can manage his Debian bugs while it is using Ubuntu
[01:27] <EagleScreen> i have uploaded it to me ppa
[01:27] <EagleScreen> waiting for a dependency to built to can use it in intrepid
[01:29] <EagleScreen> many people whose contribute to Ubuntu contribute also to Debian and they will want to have these kind of packages
[01:29] <ScottK> reportbug-ng got removed because it was a horrid disaster.
[01:30]  * ScottK does his Debian work just fine without it.
[01:30] <ScottK> Has it really gotten so much better?
[01:30] <EagleScreen> the new version is good, it works well
[01:42] <EagleScreen> python-debianbts es un paquete virtual? qué significa eso?
[01:44] <EagleScreen> aptitude tell me that python-debianbts is a virtual package, what does it mean? reportbug-ng depends on python-debianbts and it is not listed in repository
[01:46] <sven777> hi I have another question - the FAQs say that packages uploaded to REVU need to have 2 MOTU advocates.  Does this happen automatically or do I need to do something to make it happen?
[01:46] <Hobbsee> EagleScreen: http://www.linuxtopia.org/online_books/linux_system_administration/debian_linux_guides/debian_linux_faq/ch-pkg_basics.en_007.html
[01:48] <nhandler> sven777: MOTUs go through the queue when they have time. However, asking in here on Fridays is a good way to get advocates
[01:48] <EagleScreen> it is the same as meta-package?
[01:48] <sven777> nhandler - oh ok.  Thanks much for that info.  :)
[01:51] <Hobbsee> EagleScreen: no.
[01:54] <EagleScreen> i have uploaded python-debianbts to my ppa, but it is not listed by synaptic, any idea?
[01:55] <Hobbsee> how long ago did you upload it?
[01:55] <EagleScreen> minutes ago
[01:55] <EagleScreen> but it is built yet
[01:56] <EagleScreen> i will wait sime time, may be it will appear later
[01:56] <Hobbsee> it takes a while to actually public
[01:56] <nhandler> EagleScreen: Is your PPA in your /etc/apt/sources.list file? And did you do an apt-get update?
[01:56] <Hobbsee> er, publish
[01:57] <EagleScreen> yes, ofcourse i have installed various packages from my ppa
[01:59] <nhandler> EagleScreen: Ok, just making sure
[02:06] <anakron> Hi all
[02:08] <EagleScreen> hi
[02:08] <EagleScreen> my package finally appeared :D
[02:08] <anakron> wich one
[02:09] <nhandler> Glad to hear that EagleScreen
[02:09] <anakron> im a bit newbie...how i can be maintainer of a package
[02:09] <nhandler> anakron: Ubuntu (for the most part) doesn't have individual package maintainers like Debian does. We maintain them as a team
[02:10] <anakron> yes i know
[02:10] <nhandler> You can "Maintain" the package by patching bugs, keeping it up-to-date, and forwarding changes/bugs upstream
[02:10] <EagleScreen> but now i have version problem: reportbug-ng cannot be installed because depends on python-debianbts <= 0.3 and available is 0.3~intrepid1~ppa2, i will have to build it again with an upper version :(
[02:11] <anakron> keeping it up-to-date >>> sync and merge?
[02:11] <nhandler> If it is in Debian, yes
[02:11] <anakron> and...how you can k-i-u-t-d if a package is from...gnome
[02:11] <EagleScreen> i am trying to sync reportbug-ng
[02:12] <anakron> like the last version of gdesklets
[02:12] <anakron> that come with some bugs fixed
[02:12] <nhandler> anakron: Is it also in Debian?
[02:12] <EagleScreen> if I sync a package from Debian.. must I upload it to REVU??
[02:12] <anakron> yes, but the new version is not in debian
[02:13] <nhandler> anakron: I would contact the Debian Maintainer and see if they plan on updating their package. Chances are, this will not happen until after February 14 (lenny release)
[02:13] <anakron> ok
[02:41] <anakron> someone can say me an app written in python
[02:42] <anakron> tell me some of them
[02:46] <Hobbsee> anakron: http://www.google.com.au/search?q=application+written+in+python&ie=utf-8&oe=utf-8&aq=t&rls=com.ubuntu:en-US:unofficial&client=firefox-a
[02:46] <anakron> thanks
[02:46] <anakron> im trying to find an example
[02:46] <anakron> for fix a bug
[02:52] <anakron> Scottk?
[02:52] <anakron> ping Scottk
[02:52] <ScottK> Yes?
[02:53] <anakron> we were talking about a bug of catfish
[02:53] <ScottK> Any of the packages that the pythonistas or pythoneers teams are subscribed to are written in Python.
[02:53] <anakron> and you ask for it in python channel
[02:53] <anakron> yes, i was looking for one that i use
[02:53] <ScottK> No, I suggested you ask your question in #python.
[02:53] <anakron> but i cant access
[02:55] <ScottK> Try /join #python in your IRC client.  Works here.
[03:22] <EagleScreen> reportbug-ng is finally working well for me in intrepid
[03:55] <ScottK> I'm fairly certain that's a package we only want to get from Debian.
[07:09] <didrocks> morning
[09:57] <DktrKranz> RAOF: do you plan to update gnome-do to latest release?
[10:03] <zMoo> hi, iulian
[10:05] <zMoo> The proposal for a new format of debian/copyright (http://wiki.debian.org/Proposals/CopyrightFormat) does't seem to be stable
[10:05] <zMoo> do you really think I should use it?
[10:06] <zMoo> Now, everyfiles of the package are licensed under the GPL v3
[10:07] <zMoo> (I'm taliking about the "swac-play" package)
[10:14] <fta> anyone working on updating the googleearth-package for google earth 5?
[10:14] <fta> can't find anything in debian
[10:15] <fta> hm, it's maintained in a private bzr branch (not on lp)
[10:15] <iulian> zMoo: Well, I recommend it.
[10:16] <fta> does this mean we can't update it?
[10:18] <zMoo> iulian: so I put something like "http://wiki.debian.org/Proposals/CopyrightFormat?action=recall&rev=143" for the field "Format-Specification" ?
[10:19] <zMoo> you think, the format will not evoluate anymore?
[10:19] <liw> I doubt the format will change all that much, but it's also not time yet to push for it to be adopted, I think
[10:20] <iulian> zMoo: If that's what it says there, yes.
[10:20] <zMoo> ok
[10:20] <zMoo> I just have to find the number of the current revision
[10:21] <zMoo> iulian: another problem.
[10:21] <zMoo> I can not see any value for the GPL3+ license
[10:23] <zMoo> I used the GPLv3+ as recommended in http://www.gnu.org/licenses/gpl-howto.html
[10:23] <iulian> zMoo: Just mention GPL-3+.
[10:24] <zMoo> :)
[10:24] <iulian> Take a look at http://packages.debian.org/changelogs/pool/main/g/git-cola/current/copyright for an example.
[10:26] <iulian> zMoo: License keywords:  GPL-3+
[10:26] <iulian> GNU General Public License, version 3 or later
[10:39] <directhex> i support iulian on this. the copyright format is nice even for human-readability
[11:31] <zMoo> iulian: the new package for swac-play is ready :)
[11:42] <iulian> Great.
[11:45] <zMoo> iulian: It's time to eat. See you
[12:39] <khashayar> mok0: New upload http://revu.ubuntuwire.com/details.py?package=pencil fixes all (but one) problem; if you find the time :-)
[12:40] <mok0> khashayar: that's great
[12:40] <mok0> khashayar: I'll take a look later todayt
[12:40] <khashayar> mok0: Thanks!
[12:40] <khashayar> mok0: Do you think you could take a look at http://revu.ubuntuwire.com/details.py?package=rtirq as well. It should be an easy one ;-)
[12:41] <mok0> khashayar: ok, will do
[12:41] <khashayar> Cheers!
[12:42] <nhandler> khashayar: I should be free around 23:00 UTC to give the packages another review if you want
[12:47] <khashayar> nhandler: Thanks. I'll try to make new updates before 23:00 UTC, then, if need be.
[12:51] <savvas> what does this mean for dpkg --compare-versions: lt-nl ?
[12:53] <Hobbsee> man dpkg?
[12:53] <Hobbsee> oh
[12:53] <Hobbsee> it's less than - something
[12:54] <Hobbsee>  otherwise. There are two groups of
[12:54] <Hobbsee>               operators, which differ in how they treat an empty ver1 or ver2. These treat  an  empty  version  as
[12:54] <Hobbsee>               earlier than any version: lt le eq ne ge gt. These treat an empty version as later than any version:
[12:54] <Hobbsee>               lt-nl le-nl ge-nl gt-nl. These are provided only for compatibility with control file syntax: < << <=
[12:54] <Hobbsee>               = >= >> >.
[12:56] <savvas> Hobbsee: could you give me an example? or does lt-nl mean < ?
[12:57] <loic-m> Hobbsee: I can understand what you're quoting, but it's worded only slightly better than a quantum mechanics article ;)
[12:58] <savvas> true :P
[12:59] <loic-m> I'm sure the man page author was just short of throwing a bit of xml at it
[13:00] <fta> savvas, "a lt b" is equal to "a lt-nl b" if both a and b are not empty/null/undefined
[13:01] <fta> if either a or b could be empty/missing, use the -nl variant to be sure that dpkg --compare-versions won't fail, so you get a predictable result
[13:02] <fta> very handy for scripts
[13:02] <Hobbsee> loic-m: indeed...
[13:03] <Hobbsee> loic-m: that'll teach me not to answer questoins close to midnight
[13:04] <loic-m> Hobbsee: hehe
[13:21] <zMoo> hi, iulian
[13:21] <khashayar> mok0: About the wrong street address in LICENSE (wrt the rtirq package): This file is part of the upstream tarball. Do I need wait for a new release, or can I mention this somewhere in the packaging before upstream fixes it with a new LICENSE?
[13:30] <iulian> zMoo: Hiya
[13:37] <piratenaapje> $visitor->language = reset(explode(',', $_SERVER["HTTP_ACCEPT_LANGUAGE"]));
[13:37] <piratenaapje> wow php is vies spannend
[13:37] <piratenaapje> Hmm, something tells me this is not the channel I wanted to paste that in
[13:37] <zMoo> iulian: I've just uploaded a new package. I think, this time, is the good one :)
[13:38] <iulian> zMoo: Excellent.  I will have a look at it.
[13:38] <zMoo> iulian: it's really pleasant to work with you
[13:38] <iulian> Of course.
[13:57] <iulian> zMoo: debian/copyright:  Please replace <http://www.gnu.org/licenses/> with /usr/share/common-licenses/GPL-3.
[13:58] <zMoo> iulian: arf :)
[14:03] <cody-somerville> What is the argument to pass to debuild to set the Distribution field in the changesfile?
[14:08] <zMoo> iulian: Done \o/
[14:14] <iulian> zMoo: I've just advocated it.
[14:16] <zMoo> iulian: \o/ Houra
[14:17] <zMoo> iulian: I've reported all changes on the other package swac-scan
[14:17] <khashayar> mok0: Whenever you feel that urge of re-revuing, rtirq is now moved to http://revu.ubuntuwire.com/details.py?package=rtirq-init :-)
[14:18] <mok0> khashayar: ah, but you don't need to rename the source package
[14:19] <mok0> khashayar: I meant just changing the name of the binary package, in debian/control...
[14:20] <mok0> khashayar: it's actually best to keep the source package name the same as upstream's tarball (except for general Debian policy on package names)
[14:20] <khashayar> Ah, I see :-p
[14:20] <khashayar> I'll do that then. Any way to remove rtirq-init from revu?
[14:20] <mok0> khashayar: You understand now? It's a one-line change in control
[14:21] <mok0> khashayar: I can nuke it :-)
[14:21] <khashayar> Yes, I get it. Thanks. Please nuke :-)
[14:21] <iulian> zMoo: Yes, I've seen that.  I'm reviewing it now.
[14:22] <mok0> khashayar: anyways I'm busy looking at pencil, so take your time
[14:22] <khashayar> Cool.
[14:22] <zMoo> iulian: Excellent!
[14:23] <iulian> zMoo: Reviewed and advocated.
[14:24] <zMoo> iulian: Thank very much
[14:26] <RainCT> heya
[14:28]  * iulian prods RainCT.
[14:34] <zMoo> hi RainCT & pochu. My packages have been advocated by iulian! I offer a free collection of bielorussian words to the second advocate! :]
[14:41] <RainCT> zMoo: is compat level 7 necessary for some reason?
[14:42] <zMoo> I don't think so
[14:43] <RainCT> Why do you use it then? This is a very minor issue, but using high compat levels for the sake of doing so just increases the difficulty to backport a package
[14:43] <zMoo> my debin/compat was generated by dh_make :)
[14:43] <zMoo> *debian/compat
[14:44] <zMoo> Is it a good answer?
[14:44]  * zMoo => []
[14:44] <RainCT> Rather, no. And you blindly trust dh_make?
[14:44] <RainCT> :P
[14:44] <RainCT> hehe
[14:45] <RainCT> (If you don't change this now, I'll survive anyway ;))
[14:45] <zMoo> I just have to restart my laptop, and I change it
[14:45] <RainCT> zMoo: Format-Specification in debian/copyright is missing the revision number
[14:46] <khashayar> RainCT: I though it was recommended to use compat = 7, standards version = 3.8.0. Won't there be lintian warnings otherwise?
[14:46] <khashayar> (I'm just asking because in all my packaging efforts I set those versions :-/)
[14:47] <RainCT> khashayar: No. Standards version should always be the latest, but the same doesn't apply to compat. You can choose between any compat level (well, that it number 4 or above, 1/2/3 are deprecated) depending on which new features you need
[14:48] <zMoo> RainCT: for the revision, I did the same thing like iulian in http://packages.debian.org/changelogs/pool/main/g/git-cola/current/copyright
[14:48] <khashayar> RainCT: I see. I guess 6 should be good figure then, as that's what hardy's using. Correct?
[14:48] <zMoo> and I did find the revision number of the document
[14:48] <zMoo> *didn't
[14:49] <iulian> I believe the revision number doesn't matter so much since the specification is not pushed.
[14:50] <RainCT> khashayar: Yes, 6 should be acceptable (but you could get it even lower, or use a higher one if you want some new behaviour introduced with a later version.. see  man debhelper  for information on all levels). But as I said, this is just a nit-pick, it's good to consider but isn't really a must.. Using level 7 won't kill cats or anything :)
[14:50] <khashayar> RainCT: Good to know. Learning something new every day :-)
[14:51] <RainCT> iulian: the specification says there must be the revision, as I understand it
[14:51] <mok0> khashayar: comment ready for you, for pencil
[14:52] <iulian> RainCT: Ah, well, then append the revision number to that url, zMoo.
[14:52] <RainCT> zMoo: I can't find anything else to complain about, will have a look at the resulting .deb now :)
[14:53]  * RainCT updates cowbuilder
[14:59]  * henrik-hw0 thanks mok0
[15:00] <mok0> henrik-hw0: it would be good to get a second advocate quickly, so we can build your cdemu stuff without funny business
[15:01] <mok0> Any MOTUs ready to give a 2nd advocation of libmirage?
[15:01] <mok0> MOTUs: ^
[15:03] <mok0> Tip to ppl seeking review: if you know your package falls in the special area of one of the special Ubuntu distros (Kubuntu, Ubuntu Studio, etc.) try to look for a MOTU in that area
[15:04] <henrik-hw0> mok0: indeed. especially since that package contains the parts reusable by other projects as well.
[15:04] <mok0> henrik-hw0: good point
[15:07] <zMoo> RainCT: I think, I have to use compat V7 (I use a new fonctionnality of dh_clean in my debian/rules)
[15:18]  * pochu wonders who has applied for the Council vacant :)
[15:20]  * RainCT is happy at archive reorg :)
[15:20] <pochu> hi RainCT
[15:20] <pochu> me too :)
[15:21] <jpds> How isn't?
[15:21] <jpds> Who*
[15:21] <RainCT> hehe
[15:23] <mok0> We really should put the newly uploaded packages from REVU onto a bzr repo
[15:24] <mok0> RainCT: you think that revu could stash things away in a bzr repo?
[15:24] <RainCT> mok0: That's already done automatically
[15:25] <mok0> RainCT: really? where?
[15:25] <RainCT> mok0: VCS for everything spec? :P
[15:25] <RainCT> Or do you mean a repo for packages *before* they enter Ubuntu?
[15:25] <mok0> RainCT: I didn't know it was already working
[15:25] <Laney> maybe that could be a new use for revu-uploaders
[15:26] <mok0> RainCT: actually , yes I did
[15:26] <Laney> bzr push lp:~revu-uploaders/mycoolnewpackage
[15:26] <RainCT> Uhm.. I guess I should cancel my team deletion request then :P
[15:26] <mok0> Sometimes there's a trivial thing you'd like to fix before advocation, like a spelling mistake, and it's kinda cruel to ask for another upload just for that
[15:27] <mok0> RainCT: perhaps you should
[15:27] <Laney> just an idea
[15:27] <Laney> LP allows users to set the "state" of branches too
[15:28] <RainCT> yes, that's an interesting idea
[15:28] <Laney> Although, I don't know if we need revu-uploaders for it.
[15:28] <Laney> People can just push to their own space
[15:29] <mok0> Laney: sure, but it would be nice to have all branches collected in 1 place
[15:29] <Laney> mok0: Yeah, the revu website
[15:29] <Laney> or you could propose for merging into some central "pleaes review me" place
[15:29] <mok0> Laney: yeah... I guess...
[15:30] <zMoo> RainCT: the new package in online (I didn't change the compat version number)
[15:30] <Laney> or revu could support bzr directly
[15:30] <RainCT> zMoo: okay
[15:30] <zMoo> *is online
[15:30] <mok0> Laney: I like that last idea
[15:31] <Laney> Actually I like the idea of using LP's code review facilities
[15:31] <RainCT> it would be great if LP supported branches owned by several teams (eg, the uploader + MOTU) :P
[15:31] <mok0> Laney: but I think the crucial thing is that MOTUs should have write access to the place where people put their branches, so we can fix small issues
[15:31] <mok0> RainCT: exactly
[15:32] <Laney> hmm
[15:32] <mok0> In that sense, ppl should just ask for their personal branches to be merged into the MOTUs repo
[15:33] <Laney> but then if it gets merged they can't modify it any more
[15:33] <mok0> Laney: no, but they can upload their fixes to their own place and those could be merge
[15:33] <mok0> d
[15:34] <mok0> or pulled
[15:34]  * mok0 is no bzr wizard
[15:34] <mok0> yet
[15:35] <Laney> I dunno, it seems like it would be easier for everyone to just be able to push
[15:35] <mok0> Laney: I just advocated a package with a spelling mistake in the description, it would be nice to just be able to fix it
[15:35] <Laney> to the same place
[15:35]  * RainCT thinks we should better wait for the spec to be fully implemented before looking how REVU could do something with bzr
[15:36] <mok0> Laney: Hm, so the repo belongs to revu-uploaders, who everybody is a member of?
[15:36] <Laney> mok0: You could
[15:36] <Laney> fix the mistake, upload and then advocate your version
[15:36] <mok0> RainCT: of course, just brain fscking here :-)
[15:36] <Laney> RainCT: Hm, I dunno. It doesn't really deal with new packages
[15:37] <Laney> I think all of the machinery for doing actual packaging in bzr is there, unless I'm mistaken
[15:37] <mok0> Laney: true, but it would be eazier if you had your copy from bazaar, you could just push your mods
[15:37] <Laney> it would
[15:37] <mok0> Laney: ...and the uploader could pull your mods
[15:38] <Laney> moreover, the uploader wouldn't even be able to push their own changes until merging yours
[15:38] <jpds> Do we VCS everything or just the debian/ dir?
[15:38] <Laney> (without --overwrite?)
[15:38] <Laney> usually just debian/
[15:38] <mok0> OK, that requires a watchfile
[15:38] <Laney> (with SVN, I think bzr has some crazy looms thing)
[15:38] <mok0> looms?
[15:39] <Laney> mok0: See https://wiki.kubuntu.org/NoMoreSourcePackages
[15:39] <Laney> It's the new way of doing patches
[15:40] <Laney> s/new/bzr/
[15:40] <mok0> Laney: Yeah. I'm not so hot on using it for patches, though
[15:40] <Laney> yeah, and that will have to wait until this gets done anyway
[15:41] <Laney> you can still do it the normal way
[15:41] <mok0> Laney: but as a way of interacting with uploaders of new packages, I think it would be cool
[15:42] <Laney> certainly
[15:44] <jpds> Laney: That loom thing looks so cool.
[15:44] <Laney> yeah - it's basically another view on quilt patches, which is good
[15:45] <mok0> Hm, Laney, in the document you URL'ed above, it says: "For packages uploaded via a revision control build request, there would be no source package, instead the buildd needs to check out the required revision control branch and build the binaries and source package from that." That implies that upstream's source is also in there
[15:45] <Laney> mok0: I think there's a loom for the upstream source
[15:45] <Laney> and everything else sits on top of it
[15:45] <Laney> i.e. upstream is basically "patch 0""
[15:45] <mok0> Laney: I see
[15:45] <mok0> Cool
[15:46] <Laney> so to update to a new upstream version you just touch that loom, then carry on up the stack fixing the looms as they generate conflicts
[15:50]  * RainCT uploads a new ubuntu-dev-tools version
[15:50]  * mok0 wonders if Debian can be persuaded to work on LP for new packages that start their life in Ubuntu
[15:50]  * Laney giggles
[15:51] <Laney> alioth supports bzr, though
[15:51] <mok0> Laney: ok, so the whole branch could migrate there
[15:51] <jpds> RainCT: Remeber to bzr tag it.
[15:51] <RainCT> jpds: how is that done?
[15:52] <jpds> RainCT: bzr tag -r NN 0.6N
[15:52] <jpds> Where NN is revision of upload.
[15:52] <RainCT> and the 0.6N?
[15:52] <RainCT> ah ok
[15:52] <RainCT> :P
[15:52] <jpds> RainCT: Whatever version you uploaded ;-)
[15:52] <jpds> RainCT: i.e bzr tags
[15:54] <Laney> jpds: Does debcommit -r work with bzr?
[15:54] <jpds> Laney: Never used that.
[15:54] <Laney> mmk
[15:54] <RainCT> jpds: wow, what it you who has tagget all past uploads?
[15:54] <Laney> it's supposed to commit and tag
[15:54] <jpds> Laney: Manpage claims to.
[15:54] <jpds> RainCT: Yep.
[15:54] <RainCT> debcommit rocks, you should use it :)
[15:55] <Laney> does it create a new blank changelog entry?
[15:55] <Laney> (that would be sexy)
[15:59] <RainCT> iulian: have you tried if swac-play works?
[16:00] <RainCT> (it's not installable on Hardy and I would like to avoid starting a VM now..)
[16:00] <RainCT> s/Hardy/Intrepid
[16:02] <RainCT> nice, edge.'s +archive package has Ajax :)
[16:03] <RainCT> *package = page
[16:03] <RainCT> :(
[16:04] <jpds> The evil green flash?
[16:05] <RainCT> yes
[16:05] <RainCT> And it is evil indeed.. The fact that it is Ajax is cool :P
[16:08] <mok0> Huh? What green flash?
[16:09] <RainCT> mok0: https://edge.launchpad.net/~do-testers/+archive/ppa
[16:09] <mok0> ah
[16:09] <mok0> heh
[16:10] <RainCT> mok0: ah, I asked you yesterday if you have already touched anything in index.py
[16:10] <RainCT> (in REVU)
[16:10] <mok0> I haven't pushed anything yet
[16:10] <RainCT> mok0: but modified? (so that I don't do many changes there which will then conflict with yours :P)
[16:11] <mok0> RainCT: I can pull?
[16:11] <RainCT> mok0: sure
[16:12] <mok0> ah, merge
[16:13] <RainCT> uhh
[16:13] <mok0> Ah, the only real change I've done is so that you get a line number on the listing
[16:13] <mok0> I can push that and you can see if you want to use it
[16:14] <RainCT> mok0: Not sure what you mean, but okay
[16:14] <mok0> RainCT: on the webpage, in each table the package is numbered from the top, starting with 1, so you can easily see how many there are
[16:15]  * RainCT doesn't like that :P
[16:15] <mok0> RainCT: adds another column to the html table, on the left hand side
[16:15] <mok0> RainCT: why?
[16:15] <RainCT> just adding   (X)   next to the section name should do the job
[16:15] <mok0> RainCT: right
[16:15] <mok0> that's better
[16:15] <RainCT> I don't seen any use for it and it clutters the interface
[16:16] <Laney> It would imply that REVU is a queue too, at least to me
[16:16] <RainCT> (adding it on every line, that is)
[16:16] <mok0> True
[16:16] <RainCT> And today I'm doing some sort of typo in every line I write XD
[16:16] <mok0> Well, it's taught me a bit about how this template thing works :-)
[16:17] <RainCT> that's always good :)
[16:18] <RainCT> zMoo: seems like iulian is away.. You're sure the .deb works fine, right?
[16:18] <zMoo> yes
[16:18] <zMoo> RainCT
[16:18] <zMoo> I'll try again
[16:19] <bddebian> Hi folks
[16:19] <mok0> RainCT: I am thinking that perhaps adding some SQL tables might eliminate the need for doing these complex queries, but how to keep the info consistent, if it's duplicated?
[16:20] <Laney> urgh, don't duplicate in a database
[16:21] <RainCT> mok0: where is it duplicated?
[16:21] <RainCT> zMoo: Uploading :)
[16:21] <mok0> RainCT: Don't know, yet :-)
[16:21] <RainCT> lol
[16:22] <mok0> RainCT: for example, if a package is advocated, I'd like to use that to bump the rung of the package
[16:23] <mok0> sorry, the rung of the sourcepackage
[16:23] <mok0> not the upload
[16:26] <RainCT> mok0: that still wouldn't allow us to remove the advocation table (advocates are associated to comments, which is good that way, and remember that they can also be added/removed after being given)
[16:26] <RainCT> jpds: can we get ubuntu-dev-tools backported to Intrepid?
[16:27] <mok0> RainCT: yes, but the advocation is not really a property of the comment, it's a property of the package
[16:27] <jpds> RainCT: Sure, file a request and I'll do it.
[16:27] <zMoo> RainCT: in fact I should add gstreazmer0.10_plugins-good in the dependences (it's not mendatory, but it'll be better)
[16:28] <zMoo> *dependances
[16:29] <RainCT> zMoo: oh. you can get a new revision in once the package has been accepted.
[16:29] <zMoo> RainCT: I did't see "Uploading"
[16:29] <zMoo> in fact, this dependance is not mendatory
[16:30] <RainCT> zMoo: it should be a Recommends then
[16:30] <zMoo> yes
[16:30] <RainCT> jpds: do I need to write something particular in the description?
[16:30] <zMoo> "<RainCT> zMoo: Uploading :)" Houra \o/
[16:31] <jpds> RainCT: "It builds, works, runs and has all dependencies in intrpeid."
[16:34] <mok0> Hm how do I get back a file from bzr that I've deleted?
[16:35] <RainCT> mok0: bzr revert <file>
[16:35] <mok0> thx
[16:37] <RainCT> jpds: bug 325812
[16:39] <jpds> RainCT: ACKed.
[16:40] <RainCT> jpds: Great. And now an archive-admin does the backport?
[16:40] <jpds> RainCT: Yes.
[16:41] <mok0> RainCT: When I try to bzr pull, it tells me the branches have diverged, but when I do bzr merge it says "nothing to do"
[16:41] <RainCT> mok0: are you merging the right branch?
[16:41] <mok0> RainCT: perhaps not
[16:41] <RainCT> bzr merge lp:revu
[16:42] <mok0> RainCT: ah, that worked, now I have all your mods
[16:42] <mok0> RainCT: some of the files have "+N" others only "N" what does that mean?
[16:43] <RainCT> mok0: N is new. Not sure what the + is
[16:43] <mok0> Oh, my bad, it says "M" not "N"
[16:44] <RainCT> mok0: M = Modified
[16:44] <mok0> Ok, you added a bunch of "flot" stuff
[16:44] <RainCT> If there's an * it means that the permissions were modified. For the +, I don't know.
[16:44] <RainCT> mok0: Yep, that's for the graphics (and includes jQuery so we can add more fancy stuff anytime)
[16:45] <mok0> heh cool
[16:46] <mok0> RainCT: so I should just do the bzr merge lp:revu often, to keep up with your version?
[16:47] <RainCT> mok0: Yep. If you do now   bzr merge --remember lp:revu   afterwards   bzr merge   will be enough
[16:52] <mok0> RainCT: Mind if I change the format of the data field to RFC2822 format?
[16:52]  * Laney applies for things
[16:52] <mok0> s/data/date/
[16:52] <Laney> thanks james_w \o
[16:53] <james_w> Laney: no problem
[16:53] <RainCT> mok0: what's the difference?
[16:53] <mok0> RainCT: e.g. 27 Jan 2009 14:48
[16:53] <Laney> that's my birthday
[16:53] <mok0> RainCT: same as in changelog
[16:54] <mok0> Laney: :-) congrats
[16:54] <Laney> heh
[16:56] <khashayar> mok0: Thanks (re: pencil comments)
[16:56] <iulian> RainCT: What do you plan to do with ~revu-uploaders?
[16:56] <RainCT> iulian: it was discussed that it may be useful to do something with bzr in the future
[16:57] <RainCT> mok0: and how is it now? :P
[16:57] <iulian> RainCT: Ah, cool.
[16:57] <mok0>   	 January   27  13:57
[16:57] <RainCT> mok0: ok, feel free to change it, as long as you tell me how to update the DB :P
[16:58] <mok0> RainCT: it's just a change in index.py
[16:58] <RainCT> mok0: ahh ok
[16:58] <RainCT> mok0: Sure, do so. But remember to also modify this in the other files which show a date.
[16:58] <mok0> RainCT: ok, sure
[16:59] <zMoo> iulian: is everything ok with the second package? http://revu.ubuntuwire.com/details.py?package=swac-scan
[17:00] <zMoo> the package is absent from the list of advocated packages
[17:00] <mok0> RainCT: another bzr question... now that I've merged your latest updates, I need to commit it, but that will create a dump log message like f.ex. "merging changes from trunk" or something. How do you do this?
[17:01] <mok0> RainCT: and what will happen to that commit if you merge my branch?
[17:01] <walrus17> Hello, could someone contact someone from #ubuntu and say that unban me
[17:01] <mok0> RainCT: will that dumb merge message be a part of trunk's log, then
[17:01] <RainCT> zMoo: you've done a new upload, so you've lost the advocation
[17:01] <Laney> walrus17: No. Go to #ubuntu-ops
[17:01] <RainCT> mok0: bzr commit -m "message.."
[17:01] <walrus17> Okay thank you
[17:02] <zMoo> RainCT. I see. Thanks
[17:02] <mok0> RainCT: oh, I know, my question is will "message" eventually be part of trunk's log if my branch gets merged?
[17:03] <RainCT> mok0: iirc when you merge something the merged revision(s) will be in bazaar as "sub revisions" and you'll still be able to read their log messages (although they aren't displayed on Launchpad's interface)
[17:08] <mok0> RainCT: I was wondering about that, because it "pollutes" the history with a bunch of meaningless "merge from trunk" messages
[17:14] <RainCT> mok0: oh, don't worry because of that
[17:14] <RainCT> REVU has already enough meaningless commit messages as that a few more from you would make a difference *G*
[17:23] <sven777> if anyone feels like being generous, I'm still in need of advocates for my new package : http://revu.ubuntuwire.com/details.py?package=lmalinux   :)
[17:34] <porthose> iulian: I have made the requested changes to bug #269079, would you mind having a look at it when you have time.  Thanks :)
[17:42] <iulian> porthose: Sure.  I know that you know how to count.  Don't get me wrong.  I have just tried to explain.
[17:43] <jpds> Laney: I'm still waiting for huats 4000 friends to +1 him on the motu-council list.
[17:45] <RainCT> iulian: using multiple monitors works fine, at least using NVIDIA's configuration program
[17:49] <Laney> jpds: Probably waiting for his CC application. World domination ahoy
[17:49] <Laney> didrocks: I just notice that an SRU I did was in the release notes too \o/
[17:50] <nschembr> I checked with #ubuntu without any luck. I'm running ubuntu server without xwindow. I'm looking to  install xterm so I can push a xterm to a third box. I have no  need to install x11 and will never run x on this box. apt-get  wants to install the world.  Is there a way to force the  install without all of the dependencies.
[17:50] <nschembr> one package at a time.
[17:51] <didrocks> Laney: congrats ;)
[18:03] <LaserJock> anybody know of a good versioning scheme for git?
[18:04] <broonie> You mean for commit IDs?
[18:04] <jdong> dates?
[18:04] <henrik-hw0> superm1: ping!
[18:04] <porthose> Iulian:  Thank you for explaining it  :)
[18:04] <jdong> sha1sums sure aren't gonna help :D
[18:04] <LaserJock> jdong: yeah, but you can have a lot of commits in 1 date
[18:04] <superm1> henrik-hw0, pong
[18:04] <jdong> LaserJock: well number 'em up from 1 ;-)
[18:04] <broonie> LaserJock: git describe may work for you.
[18:04] <LaserJock> jdong: yikes
[18:04] <broonie> depending on how the repo is tagged.
[18:05] <henrik-hw0> superm1: Did have a talk with Keybuk.
[18:05] <jdong> LaserJock: well that's what I've seen done; and due to the way git names revisions I don't think there's a better idea than that :(
[18:05] <jdong> the obvious downside is that two independent packagers will surely end up with version number clashes
[18:05] <LaserJock> broonie: seems to work for some branches but not others
[18:06] <broonie> LaserJock: Yes, it works well if there's a tag in the history (in which case it gives a commit count since that tag).
[18:06] <broonie> plus the tag
[18:06] <LaserJock> ah, nifty
[18:06] <iulian> porthose: I've just uploaded it, thanks.
[18:06] <iulian> RainCT: Eh?
[18:06] <superm1> henrik-hw0, and what did you determine?
[18:06] <broonie> eg, my current Linux git branch is v2.6.29-rc3-573-g580406a
[18:06] <henrik-hw0> superm1: looks like the udev rules will have to stay for now.
[18:08] <henrik-hw0> superm1: udev gets the hw event and tries to modprobe. however modprobe fails. unknown cause.
[18:08] <RainCT> iulian: err, that was for Laney
[18:09] <iulian> Heh, OK.
[18:10] <superm1> henrik-hw0, so why does modprobe work the second time?
[18:10] <henrik-hw0> superm1: if you mean the udev rules i load the module by name rather than by modalias.
[18:11] <superm1> henrik-hw0, sounds like a bug in the module then?
[18:11] <henrik-hw0> superm1: it sure does.
[18:11] <superm1> henrik-hw0, well if you can file a bug with that upstream, and keep an eye on it to see when it gets fixed, and add some comments in the udev rule i can ack the package then
[18:17] <henrik-hw0> superm1: i don't have much hope in upstream giving a reply. :/ i want to check with "rtg" first. perhaps we should talk after that?
[18:18] <superm1> henrik-hw0, well if upstream isn't going to be responsive to bugs in their software, that's a good reason to not include their software in ubuntu though.
[18:19] <superm1> henrik-hw0, so i would recommend at least filing the bug with them.  we can talk more about it after you talk to rtg
[18:19] <henrik-hw0> superm1: ok.
[18:19] <superm1> but i think as long as the bug is filed and documented why the udev rules are necessary that packaging is otherwise in good shape
[18:23] <porthose> iulian: Thank you very much :)
[18:28] <savvas> fta: thanks for your answer about lt-nl before, I forgot to reply :)
[18:29] <savvas> the dpkg manual could surely be updated in that section
[18:30] <RainCT> Any python wizard around? If I have a list of numbers, how can I get those between which there is a minimum difference of 5 (eg, [1, 3, 7, 15, 20] would become [1, 7, 15, 20])?
[18:34] <maxb> I can't think of a one-liner, but as a for loop appending into a new list it's triival
[18:35] <RainCT> maxb: Yep, I was wondering if there's some inbuild way.
[18:35] <hyperair> maxb: how abnout a loop removing the elements from it
[18:36] <maxb> It's problematic in that you need to refer not to the previous entry, but the previous entry that you accepted
[18:36] <hyperair> wait, i think i can come up with one
[18:38] <RainCT> got it, almost
[18:38] <RainCT> [b.remove(x) for x in b if (x - b[b.index(x)-1]) < 5]
[18:38] <hyperair> for i in xrange(1, len(a)-1).     while (abs(a[i]-a[i-1])<5):             del a[i]
[18:38] <hyperair> i got this
[18:39] <hyperair> hmm that's interesting O_o
[18:48] <RainCT> maxb, hyperair: thanks
[18:48] <hyperair> RainCT: not at all, you came up with your solution yourself
[18:49] <RainCT> hyperair: well, but you gave me the needed inspiration :P
[18:49] <hyperair> um thanks
[18:49]  * hyperair wonders how my stumbling around could have given RainCT inspiration
[18:50] <RainCT> yeah.. I'm that weird *g*
[18:50] <hyperair> lol
[18:51] <Laney> RainCT: What's the final version?!
[18:56] <Laney> how do I find out how many packages are in universe/multiverse?
[18:56] <RainCT> maybe synaptic will tell you
[18:57] <Laney> synaptic knows, yeah
[18:57] <Laney> so where does it get that from!
[18:57] <RainCT> counting them, probably :P
[18:57] <RainCT> python-apt may also be able to do that
[18:57] <Laney> no, synaptic knows the section
[18:57] <Laney> I should be able to use grep-dctrl or something
[18:58]  * Laney pokes
[18:58] <pochu> apt-cache dump | grep universe may do the trick (haven't tried)
[18:58] <pochu> a bit hackish though ;)
[19:01] <Laney> laney@chicken:/var/lib/apt/lists$ grep Package archive.ubuntu.com_ubuntu_dists_jaunty_universe_source_Sources | wc -l
[19:01] <Laney> 11799
[19:01] <RainCT> Laney: I get over 30.000 here.. Muahaha :P
[19:02] <Laney> are you counting binary packages?
[19:02] <RainCT> ah, yes :P
[19:03] <Laney> http://identi.ca/group/motu
[19:03] <Laney> go go go!
[19:05] <iulian> Hmm, I look nice in that picture.
[19:06] <iulian> I'm not that fat but it's fine.
[19:07] <Laney> I took every MOTU and created the geometric mean. That's what came out.
[19:07] <iulian> Ah-ha, great :)
[19:19] <hyperair> Laney: what came out?
[19:20] <Laney> http://identi.ca/avatar/1073-96-20090205190348.jpeg
[19:23] <RainCT> Laney: [keys.remove(x) for x in keys[1:-1] if (x - keys[keys.index(x)-1]) < 10]
[19:24] <rugby471> question : I am trying to patch an image in a debian package. The package is using the cdbs patch system, I can create a uuencoded patch, but do use the patch system (cdbs) to patch the image, or do I go by the instructions on this page (ie. create uuencoded files and simply add a uudecode in the build section of debian/rules) https://wiki.ubuntu.com/PackagingGuide/Howtos/BinaryFilesInDiff
[19:24] <RainCT> rugby471: patch an image?
[19:25] <rugby471> ie. in the gconf-editor package
[19:25] <rugby471> there are some outdated images in the source package
[19:25] <rugby471> that I want to replace with newer ones
[19:25] <rugby471> I will propose the patch to upstream after
[19:25] <rugby471> but for the moment I want to replace them for Jaunty
[19:26] <RainCT> rugby471: then include an uuencoded version i debian/ and in debian/rules remove the original image and install the new images (after uudecoding) into their location
[19:26] <rugby471> kl
[19:26] <rugby471> thanks
[19:26] <RainCT> (remove the original image from debian/<pkgname>/.. that is)
[19:26] <RainCT> yw
[19:26] <rugby471> see ya RainCT !
[19:27] <hyperair> RainCT: i shudder to think how inefficient that code is =\
[19:27] <hyperair> RainCT: but it doesn't matter if you're handling small lists
[19:27] <RainCT> lol
[19:29] <hyperair> RainCT: how about replacing "for x in keys[1:-1] if (x - keys[keys.index(x)-1]) < 10" with "for i in xrange(1, len(keys)-1) if (keys[i] - keys[i-1]<10"
[19:29] <hyperair> RainCT: then you won't have the overhead of keys.index(x)
[19:35] <RainCT> hyperair: that won't work
[19:36] <hyperair> RainCT: why not
[19:36] <hyperair> uh i forgot a trailing ) it seems
[19:36] <hyperair> but yeah why won't it wokr
[19:37] <RainCT> hyperair: it gives "out of range"
[19:37] <RainCT> the size of the list changes as some items are removed..
[19:39] <hyperair> ah right
[19:39] <hyperair> shit
[19:51] <RainCT> jpds: Okay, the charts on REVU show the month and the year now :)
[19:52] <jpds> RainCT: Real cool.
[20:27] <nschembr_> I checked with #ubuntu first but no luck. I'm running ubuntu server. I want to install xterm without installing X11. Is there a way to use dpkg to install the base package and the dependances one at a time.
[20:28] <jpds> nschembr_: Try #ubuntu-server.
[20:28] <nschembr_> jpds: ok thank you
[21:24] <Laney> ooh, hdbc 2.0
[21:38] <Laney> guh, some of the deps are still in NEW. Debian is weeeeeeeeeeird that people upload packages in that state
[21:43] <pochu> well, it will just depwait ;)
[21:46] <jpds> maxb: Cannot wait till they merge the dev teams.
[21:47] <maxb> ?
[21:47] <jpds> Your bug report against u-d-t ;-)
[21:47] <RainCT> heh
[21:48] <maxb> well, that'll simplify other things, but I'm not a member of either so it doesn't really matter for that bug report :-)
[21:49] <pochu> which bug are we talking about? :)
[21:49] <jpds> bug #325923
[21:49] <pochu> ah I was looking here :) https://bugs.edge.launchpad.net/ubuntu-dev-tools/+bugs
[22:04] <ScottK> Laney: Since Debian does binary uploads they can do that.
[22:07] <Laney> ScottK: I know they can, I just don't know why they would
[22:07] <directhex> ScottK, doesn't make it any less icky
[22:24] <ScottK> Well it makes the total time in New shorter if you do it in parallel instead of in series
[22:26] <Laney> the package with the deps is not in NEW
[22:26] <Laney> the deps themselves are
[22:26] <ScottK> Understand.
[22:27] <Laney> uploading it before they cleared just broke the package
[22:28] <ScottK> Sure.
[22:28] <Laney> hence the weirdness
[22:28]  * Laney will poke
[22:31] <surfaz> dtchen, 13.3 mb is the size of debdiff
[22:31] <surfaz> ... :(
[22:33] <dtchen> surfaz: right, don't worry about the size of the debdiff
[22:34] <surfaz> but also incluides po files changes
[22:34] <surfaz> and Mac OS X and Windows changes
[22:34] <surfaz> I do not know how to separate it
[22:36] <surfaz> I upload it?
[22:36] <dtchen> surfaz: ah, you can exclude OS X and Windows changes
[22:36] <surfaz> how?
[22:37] <dtchen> are those changes localised to specific directories, or are they #ifdef'd in the source alongside *nix?
[22:38] <dtchen> see also filterdiff(1), which is in the patchutils package
[22:47] <surfaz> now 4 mbs
[22:48] <surfaz> I use diff instead of debdiff
[23:08] <surfaz> done