[01:08] <freeflying> shadeslayer: ping
[01:08] <freeflying> shadeslayer: do you still need a sponsor upload?
[01:08] <stalcup> what's up with REVU days as of late?
[01:09] <bdrung> lucas: why do you subscribe ubuntu-sponsors to a sync request?
[01:19] <lucas> oops, was a test, actually
[01:20] <lucas> (well, the fact that it needed to be synced was real)
[01:28] <bdrung> lucas: should i blow the whistle on you? i used syncpackage for it.
[01:29] <stalcup> i would blow the whistle
[01:29]  * stalcup hands over a whistle
[01:31]  * bdrung hopes that he has used the phrase correctly.
[01:31] <stalcup> bdrung: since I hate manpages, what is the proper context whilst using syncpackage
[01:31] <stalcup> you did :)
[01:31] <stalcup> do you use the dsc url or the actual dsc?
[01:32] <bdrung> stalcup: i used ack-sync, which uses syncpackage
[01:33] <stalcup> ah
[01:33] <stalcup> hehe, bdrung we should eh?  but when?  :)
[01:34] <bdrung> stalcup: i don't get your question
[01:35] <stalcup> from the mailing list - when should REVU days be?
[01:36] <bdrung> stalcup: asap to get them into the archive, far away in getting the word about the revu day spread
[01:36] <bdrung> stalcup: maybe somewhere in the middle of now and FF?
[01:37] <stalcup> with FF two weeks away, i was hoping we could see a good turn-out for 3 a week
[01:37] <stalcup> that would give us 6 days
[01:38] <stalcup> i am afraid anything older than 6 months is time wasted for some people
[01:39] <bdrung> stalcup: you was thinking about more than one of them?
[01:39] <stalcup> hoping more than thinking
[01:39] <stalcup> we could also ask for a push for 2 or three days
[01:40] <stalcup> ie, tues thru thurs
[01:40]  * stalcup doesn't know what would get the most support
[01:41] <stalcup> if it's just one day, i'm sure we'll miss out on people reviewing
[01:43] <ajmitch> the problem is more getting people willing to review
[01:44] <stalcup> it just seems to get harder every cycle
[01:44] <ajmitch> because the queue doesn't really get shorter
[01:44] <bdrung> ajmitch: i am working on getting the sponsors queue shorter. everything else comes after
[01:45] <stalcup> right, its out right silly long right now
[01:45] <ajmitch> & it's the usual problem of hoping that people will commit to helping with maintenance of the packages that they want pushed through REVU
[01:45] <bdrung> stalcup: let's select three days on three different weekdays
[01:46] <stalcup> i have no problem telling someone their software is crap, even if it is packaged perfectly
[01:47] <bdrung> stalcup: i begin with complaining about the packaging and after they fix it, i send them to debian - no need to test it :)
[01:47] <stalcup> I threw out Tues thru Thurs because no one likes extra stuff on Monday.  Tuedsay they start to let their mind wander, reviweing is the perfect distraction.  By Friday everyone is burned out for the week.
[01:48] <bdrung> stalcup: one thing for improving revu: voting wich application should be in the archive -> count the "affects me too" on the needs-packaging bug
[01:48] <bdrung> stalcup: ok
[01:48] <stalcup> hrm
[01:49] <stalcup> not a bad idea
[01:49] <bdrung> stalcup: that's the reason why i looked at openshot in the previous release cycle
[01:50] <stalcup> in fact, (this brings up an old argument) maybe it should be suggested that only *needs packaging* bugs or some other method should allow new apps into REVU
[01:52] <stalcup> backporting is another laggard
[01:52] <stalcup> brb
[01:52] <bdrung> stalcup: possible. look into debian/changelog, grab lp bug, check if lp bug is a open needs-packaging bug
[03:35] <shadeslayer> freeflying: nah.. im doing it the old debian-> ubuntu way
[04:10] <stalcup> 4
[06:17] <hyperair> Zhenech: ping.
[08:16] <dholbach> good morning
[08:24] <and471> hi guys, I am trying to create a pbuilder environment, but it fails everytime
[08:25] <dholbach> and471: what's the error message can you put it on paste.ubuntu.com?
[08:25] <and471> log is here http://pastebin.ubuntu.com/472094/
[08:25] <and471> dholbach, hey :) log is ^
[08:26] <dholbach> and471: it's weird that it can't download all these packages
[08:27] <dholbach> and471: try adding this to ~/.pbuilderrc
[08:27] <dholbach> MIRRORSITE=http://archive.ubuntu.com/ubuntu/
[08:27] <dholbach> and   sudo pbuilder create --override-config
[08:28] <and471> dholbach, cool I shall try that, just to check, should I have COMPONENTS="main universe multiverse restricted" in my pbuilderrc?
[08:28] <jpds> and471: That mirror looks fine: http://www.mirrorservice.org/DisplayScreen?action=print&media=projection
[08:28] <dholbach> and471: yep
[08:28] <and471> dholbach, jpds, okay trying again :)
[08:28] <dholbach> oh, it was lucid
[08:29] <dholbach> then it's indeed weird
[08:29] <and471> dholbach, it has started failing to download packages again :(
[08:29] <and471> dholbach, is there a way to set a longer timeout or something?
[08:30] <dholbach> I really have no idea why that's happening
[08:31] <and471> dholbach, is my internet connection too sucky?
[08:31] <dholbach> I never thought that'd be a problem - I dunno
[08:31] <jpds> and471: The other main GB mirror is http://ubuntu.datahop.net/ubuntu/ - it's usually gb.archive but I'm taking it down for maintenance.
[08:31] <jpds> (At some point)
[08:38] <\sh> micahg: zend-framework 1.10.7 is on its way....+ c/r on the debian zf package
[09:05] <coolbhavi> hello all is the recent version of libtool having problems with libgtk2.0-dev?
[09:05] <Rhonda> Hmm. I can't upgrade a cowbuilder chroot from lucid to maverick, it complaints about "Unable to connect to Upstart".
[09:05] <Rhonda> How is that meant to work? Is maverick not supported anymore for chroots?
[09:07] <coolbhavi> because i tried to build newest version of xchat and it failed with unhandled argument `/usr/lib/libgdk_pixbuf-2.0.la' and looking at the rebuild failures there are a lot of those errors
[09:08] <tumbleweed> Rhonda: I've got an open bug for that
[09:08] <tumbleweed> psmisc, right?
[09:11] <maxwellian> If we're sending a patch to the original upstream, is it rude not to subscribe to the mailing list?
[09:11] <geser> coolbhavi: that .la file is gone but some other .la files still reference it -> they need to get fixed
[09:12] <coolbhavi> geser, ah okay! thanks!
[09:12] <tumbleweed> Rhonda: err, procps I meant. bug 602896
[09:12] <Rhonda> tumbleweed: Yes, procps.
[09:13] <Rhonda> tumbleweed: Thanks for the headsup, then I can stop investigating further. :)
[09:13] <Rhonda> Alright, will do a --login and apply the patch from there interactively. :)
[09:49] <Zhenech> hyperair, pong
[09:50] <\sh> siretart: I didn't get the attachment of your mail...
[09:50] <hyperair> Zhenech: have you forgotten about ctpl and geany-plugins? =)
[09:51] <hyperair> Zhenech: FF's coming up, and if those two don't get into debian in time, i'll just -0ubuntu1 them into maverick first.
[09:51] <hyperair> do you mind if i do that?
[09:54] <Zhenech> i didnt forget
[09:54] <Zhenech> mind throwing me the source again? :)
[10:00]  * hyperair digs in his email
[10:01] <hyperair> Zhenech: http://bugs.debian.org/579509
[10:08] <hyperair> Zhenech: http://mentors.debian.net/debian/pool/main/c/ctpl/ctpl_0.2.2-1.dsc
[10:08] <Zhenech> hyperair, is the maintainer somewhere on irc?
[10:08] <Zhenech> yeah, got it :)
[10:08] <hyperair> hmm that i'm not so sure..
[10:11] <Zhenech> hyperair, geany plugins is currently the only revdep for that, right?
[10:11] <hyperair> Zhenech: pretty much so.
[10:12] <Zhenech> could you drop the .a file from -dev.install, rebuild the package and see whether geany plugins still build?
[10:28] <hyperair> Zhenech: not at the moment. soffice takes up too much RAM for me to do a build.
[10:28] <hyperair> Zhenech: i'll give it a go tonight
[10:32] <Zhenech> hyperair, i'm vac tomorrow till the 8th…
[10:32] <hyperair> hmm
[10:32] <hyperair> nice timing =p
[10:32] <hyperair> lemme poke my sbuild and see if it still runs.
[10:37] <Zhenech> hyperair, basically the package looks great
[10:38] <Zhenech> i for myself would like to see the .a file away, policy 3.9.1 and done
[10:39] <hyperair> eh, there's a 3.9.1 now?
[10:39] <hyperair> Zhenech: what's wrong with the .a?
[10:40] <micahg> \sh: thanks
[10:41] <\sh> micahg: uploaded already...
[10:42] <Zhenech> hyperair, its old and should not be used when pkg-config is there
[10:42] <hyperair> Zhenech: i see. but what about those who want to compile static apps?
[10:44] <Zhenech> hyperair, dont do that? :)
[10:44] <hyperair> Zhenech: you know, some of those people who want to come up with binaries that run on all distros?
[10:44] <hyperair> Zhenech: removing .a means you can't, any more.
[10:45] <hyperair> well, unless you recompile all your libraries into a separate prefix, which sucks.
[10:45] <hyperair> grr. ftp.tw.debian.org is broken.
[10:46] <Zhenech> hyperair, well… the problem is: when there is an .a it will pull linker flags from there maybe and overlink the binary (shared)
[10:47] <hyperair> oh
[10:47] <hyperair> that would be bad.
[10:52] <Zhenech> yepp, thats why i think .a files should die :)
[11:02] <hyperair> Zhenech: uh hell, it seems my geany-plugins packaging changes have disappeared O-o
[11:03] <Zhenech> great :_
[11:06] <hyperair> Zhenech: lemme just try adding ctpl and no changes and see what happens.
[11:12] <alf__> Hi all! Anyone interested in reviewing glmark2 (a benchmark for OpenGL (ES) 2.0) [LP: #605901] [http://revu.ubuntuwire.com/p/glmark2]
[11:17] <hyperair> Zhenech: it works.
[11:18] <hyperair> Zhenech: i'll prepare the geany-plugins properly later on
[11:56] <quadrispro> slangasek, hi, why the sync of dssi from debian is blacklisted?
[11:57] <quadrispro> I see bug #305268 right now but there is no explanation in the report
[11:58] <Laney> # ... due to orig.tar.gz mismatch:
[11:58] <Laney> dssi
[12:07] <quadrispro> Laney, ahh, thank you
[12:08] <Laney> nps
[12:34] <X3> geser that ntfs-3g 5.22 upstream is compiling away for karmic lucid and maverick
[12:35] <X3> just the x86 binaries are delayed but rest is built
[12:35] <X3> despite it failing locally it worked on ppa
[12:37] <X3> i made it depend on fuse 2.8.1 should work
[13:13] <siretart> \sh: sorry?
[13:19] <\sh> siretart: you send me an email regarding fai + lucid
[13:22] <siretart> wasn't this quite some time ago?
[13:26] <\sh> siretart: 28.07 ian beardslee
[13:26] <\sh> the attachment of his bug wea
[13:26] <\sh> was missing
[13:40] <jetienne> q. if a package is not modified when the package is made, should i had -ubuntu1 or adding nothing is ok ?.
[13:44] <Bachstelze> jetienne: "not modified" from where?
[13:44] <jetienne> Bachstelze: from the original source
[13:44] <jetienne> this is plain compilation to make a package
[13:44] <Bachstelze> then it's -0ubuntu1
[13:45] <Bachstelze> 0 means "not in Debian"
[13:45] <Bachstelze> the fist digit normally is the Debian revision from which the Ubuntu package was created
[13:45] <siretart> \sh: aah, let now I remember, let me recheck
[13:45]  * Rhonda . o O ( har. I'll upload a package with debian revision -0 then! )
[13:46] <siretart> Rhonda: that would cause quite some confusion :-)
[13:46] <Rhonda> policy allows!
[13:47] <siretart> \sh: and you mean you cannot open the attachment? i.e. you don't see ian's mail?
[13:47] <jetienne> Bachstelze: hmm ok
[13:47] <\sh> siretart: I can't read ians mail :)
[13:47] <siretart> ok, I've now tried again slightly differently, does it work for you this time?
[13:48] <Bachstelze> jetienne: though normally if a package is not in Debian, you should get it into Debian first, then let it go into Ubuntu through the usual merge process
[13:50] <jetienne> Bachstelze: ok. i will do ppa for now
[13:50] <jetienne> Bachstelze: how hard it is to be included in Debian ?
[13:52] <\sh> siretart: I only have the headers :( no mail body
[13:52] <Bachstelze> jetienne: not hard, one your package is done, you post a RFS (Request For Sponsor) on the debian-mentors mailing list, and hopefully someone will upload it
[13:52] <Bachstelze> once*
[13:53] <jetienne> Bachstelze: how can i convince them ?
[13:53] <siretart> \sh: is that a display problem of you mail client? can you have a look at the message source?
[13:54] <\sh> siretart: evolution -> open with gedit
[13:55] <\sh> siretart: only envelope + headers -> no body
[13:55] <siretart> \sh: so source in gedit shows you ian's mail?
[13:55] <Bachstelze> jetienne: depends what the package is, I guess, but generally the package description in debian/control is enough to see whether the package should be included or not
[13:55] <Bachstelze> (and the package has to be lintien-clean)
[13:55] <Bachstelze> lintian*
[13:58] <jetienne> Bachstelze: hmm i will try... but from outside it seems quite random
[13:58] <jetienne> Bachstelze: would be cool to know if some criteria on what is ok to include and what is not
[13:59] <Bachstelze> mostly everything is OK, Debian is not Fort Knox
[13:59] <\sh> siretart: just copy the body ;)
[13:59] <Bachstelze> especially if it's a completely new package
[14:00] <jetienne> Bachstelze: do i have to go thru this process at every new versino ?
[14:00] <Bachstelze> a fork of an existing package that does not offer substantial improvements would not be ok, for example
[14:00] <Bachstelze> jetienne: yes, or at least until you become a Debian Developer and get upload rights to the archive
[14:01] <Bachstelze> someone has to upload it for you
[14:01] <jetienne> Bachstelze: ok so it will lag quite a lot behind :)
[14:01] <siretart> \sh: yeah, I can resend it, but I'm curious, is the problem in my or your MUA? is the message now contained in the mail or not?
[14:01] <\sh> siretart: nope..only the header...last mail from you 14:47
[14:02] <jetienne> Bachstelze: ok thanks for your help
[14:03] <\sh> siretart: thinking about enabling bug tracking for the LP fai team...
[14:04] <siretart> isn't the distro fai bugpage enough?
[14:05] <\sh> siretart: as we don't have distro packages for fai in lucid ??? and I'm not quite sure if I would upload fai before FF into maverick...
[14:06] <siretart> \sh: didn't we have a standing freeze exception for fai?
[14:06] <siretart> I remember something like that
[14:06] <\sh> siretart: if you find something, because I don't know and I'm not sure ;)
[14:07] <siretart> I'm sure we had, and I'm confident that we can get it again
[14:07] <siretart> how about uploading your packages as they are to maverick now
[14:08] <siretart> targeting to install lucid
[14:08] <siretart> then we could even consider backporting it
[14:08] <\sh> siretart: hmmm....
[14:08] <\sh> siretart: what was the bug ian wanted to report?
[14:09] <siretart> now idea
[14:09] <siretart> no idea
[14:09] <siretart> that's why I forwarded the mail to you ;-)
[14:09] <\sh> siretart: lol...copy the mail body pls...so I can have a look, eventually fix it and uploading to ubuntu-m release ;)
[14:10] <siretart> I already did?
[14:10] <jetienne> q. is it ok to ask ppa questions here ?
[14:10] <\sh> ah there it is
[14:10] <siretart> k, starbucks now. cultaer
[14:10] <\sh> siretart: have fun :)
[14:50] <bdrung> DktrKranz: when will you release ubuntu-dev-tools 0.101?
[14:57] <DktrKranz> bdrung: should I? :)
[14:58] <bdrung> DktrKranz: yes, especially due to the updated man pages
[14:58] <DktrKranz> bdrung: jokes off, I see there are a lot of changes, maybe we could consider to do soo soon
[14:58] <bdrung> DktrKranz: define soon
[14:58] <DktrKranz> bdrung: I can do it this evening, or at worst tomorrow evening, both for maverick than unstable
[14:59] <DktrKranz> s/than/and/
[14:59] <bdrung> DktrKranz: great. (but isn't it the other way around? unstable and than maverick?)
[15:00] <DktrKranz> bdrung: it's usually uploaded in ubuntu first, then I "merge" it in debian
[15:01] <bdrung> DktrKranz: you can upload it to unstable and then use syncpackage on the uploaded dsc
[15:12] <DktrKranz> bdrung: it's not perfectly in sync, uploaders change a bit
[16:01] <bdrung> DktrKranz: can't we get rid of these changes?
[16:03] <DktrKranz> bdrung: if I put "Ubuntu Developers" as Maintainer, and myself in Uploaders, sure
[16:03] <DktrKranz> that's the only diff, IIRC
[16:03] <DktrKranz> (just because I want a "real" person behind the package)
[16:03] <bdrung> DktrKranz: that's the ubuntu->debian diff: http://paste.debian.net/82046/
[16:04] <DktrKranz> yeah
[16:05] <bdrung> DktrKranz: i like the idea of having "Ubuntu Developers" as Maintainer, and you in Uploaders
[16:06] <bdrung> DktrKranz: if the version is the same, the content should be the same
[16:06]  * DktrKranz looks if there are other packages with *Ubuntu* in maint
[16:06] <DktrKranz> just to be coherent :)
[16:07] <bdrung> DktrKranz: how do you do this check?
[16:09] <Laney> grep-dctrl can do it
[16:10] <DktrKranz> bdrung: projectb database, udd, Maintainers/Uploaders file on Indices, grep-dctrl
[16:10] <DktrKranz> there are several sources
[16:11] <Laney> what is projectb?
[16:11] <DktrKranz> Laney: the monster behind Debian
[16:12] <Laney> something to do with dak?
[16:15] <DktrKranz> yeah, dak interface itself with projectb
[16:17] <DktrKranz> a lot of "Ubuntu" teams: http://pastebin.com/cthitwXP
[16:18] <Laney> I don't think it should be a problem
[16:18] <Laney> just selecting the list where maintainer emails should go
[16:20] <DktrKranz> queued (the thingie which processes the uploads) and dak (when accepting package) will spam a bit
[16:20] <Laney> yes
[16:20] <Laney> I don't know which ML would be appropriate for that
[16:20] <DktrKranz> I don't remember if we have a email addres for such a packages
[16:20] <Laney> maybe a separate LP/alioth team
[16:21] <Laney> LP team with ubuntu-dev as a member would work
[16:25] <DktrKranz> also, ubuntu-devel-discuss would be spammed for bugs reported in debian, so a ubuntu-dev team on alioth could be the answer
[16:26] <Laney> LP is probably better
[16:26] <Laney> as teams can have MLs now
[16:26] <slangasek> quadrispro: because the source tarballs are (have been) different and unsyncable
[16:26] <slangasek> quadrispro: can be unblacklisted once a new upstream version happens
[16:26] <DktrKranz> ah, right
[16:29] <Laney> DktrKranz: I'll register it if you'd like
[16:29] <Laney> although if it's just going to be for a mailing list then maybe a proper one is better
[16:29] <bdrung> DktrKranz: A ML for ~ubuntu-dev
[16:31] <Laney> Can it be made clear that this ML is for maintenance of Debian packages?
[16:31] <DktrKranz> Yeah, could go
[16:31] <Laney> I worry that a mailing list attached to ubuntu-dev will be misleading
[16:50] <DktrKranz> Laney: maybe something like "ubuntu-dev-packages@lists.something" could do
[16:50] <Laney> yep
[16:50] <DktrKranz> and description "Lists for ubuntu-dev maintained packages in Debian"
[16:50] <Laney> I have no idea how to have a lists.ubuntu.com list created
[16:50] <Laney> maybe ldo would be easier
[16:50] <DktrKranz> in LP maybe?
[16:51] <Laney> yeah you can do it with teams
[16:51] <DktrKranz> I don't think an "official" list should be created
[16:51] <DktrKranz> it will be a low traffic one :)
[16:51] <Laney> seems a bit weird to register a team just to have its list though
[16:52] <Laney> oh well, I'll do it
[16:54] <Laney> https://launchpad.net/~ubuntu-debian-maintainers
[16:55] <DktrKranz> I thought multiple MLs could be created for a single team
[16:55] <Laney> I don't think so
[16:55] <DktrKranz> so, one for ~ubuntu-dev could be added as well
[17:00] <Laney> DktrKranz: ubuntu-debian-maintainers@lists.launchpad.net
[17:01] <DktrKranz> bdrung: sounds good for you to have Maintainer Ubuntu Developers <ubuntu-debian-maintainers@lists.launchpad.net> ?
[17:02] <bdrung> DktrKranz: ubuntu-debian-maintainers@lists.launchpad.net is not perfect, but ok
[17:02] <Laney> erm
[17:02] <DktrKranz> it's just a collector to avoid being spammed
[17:03] <bdrung> DktrKranz: i meant the name
[17:03] <Laney> I just thought... will it accept mails from Debian?
[17:03] <DktrKranz> bdrung: suggestions for a better one?
[17:05] <bdrung> DktrKranz: sadly, no
[17:06] <DktrKranz> in the end, name is just a placeholder, what really matters is a functional email address
[17:06] <Laney> we definitely check that emails won't bounce
[17:06] <DktrKranz> or ftpteam will get spammed about it, and file RC bugs ;)
[17:07] <DktrKranz> Laney: I can send one from ftp-master, to see if it bounces
[17:07] <Laney> if you wish
[17:08] <RainCT> Laney: LP mailing lists queue non-member posts for review by a team admin, if that's what you were asking
[17:09] <Laney> RainCT: I was. Can they be made to be open?
[17:10] <RainCT> Laney: No. And I don't recommend it either, you'll get spammed to death
[17:10] <Laney> Debian lists manage fine
[17:12] <DktrKranz> Archive Administrator <dak@ftp-master.debian.org>
[17:12] <DktrKranz> ups
[17:13] <RainCT> Laney: Maybe you can ask some LP guy to set it open for you. iirc they use Mailman behind the scenes.
[17:13] <Laney> RainCT: yep will do
[17:13] <Laney> or whitelist *.d.o
[17:14] <jetienne> q. how to have a dh_make which understand mit license ?
[17:14] <Laney> Write your own copyright file
[17:16] <jetienne> Laney: how do i do that ? do you have pointer or keyword
[17:17] <Laney> jetienne: Look at an existing one on your system — grep MIT /usr/share/doc/*/copyright
[17:19] <jetienne> Laney: thanks
[17:21] <DktrKranz> bdrung: for the time being, maybe a "ubuntu-dev-tools maintainer" could be fine
[17:21] <DktrKranz> +s
[17:22] <bdrung> DktrKranz: as name or email address?
[17:22] <DktrKranz> name
[17:23] <DktrKranz> for email, we need one which doesn't bounce
[17:24] <bdrung> DktrKranz: will we get launchpad unbounced?
[17:25] <bdrung> RainCT: ping
[17:25] <DktrKranz> I could "intercept" those to ftp-master.d.o, but I guess other team members wouldn't be happy to get "subscription" mails
[17:26] <DktrKranz> so, I hope we can whitelist *debian.org addresses
[17:26]  * bdrung hopes too
[17:27] <DktrKranz> there are three, dak@ftp-m.d.o, installer@ftp-m.d.o and *@bugs.debian.org
[17:31] <Laney> what about bug mails
[17:31] <Laney> ?
[17:31] <Laney> They come from the originator, don't they?
[18:06] <Laney> DktrKranz: I don't think we're going to have any luck here
[18:06] <Laney> alioth list might be our best option
[18:36] <DktrKranz> Laney: probably
[18:40] <porthose> DktrKranz, do you have time to sponsor an RC bug fix into debian?
[18:42] <RainCT> bdrung: Sorry, did you want anything or was it so that I see the ML question?
[18:43] <bdrung> RainCT: yes, i want to ask you, if i can replace suspicous-source with a complete rewrite in python?
[18:43] <RainCT> bdrung: sure
[18:44] <bdrung> RainCT: it uses python-magic to determine the file types
[18:44] <bdrung> RainCT: thanks
[18:45] <DktrKranz> porthose: sure
[18:45] <porthose> DktrKranz, http://mentors.debian.net/debian/pool/main/a/ampache/ampache_3.5.4-5.dsc
[18:53] <DktrKranz> porthose: I'd set urgency=medium
[19:01] <DktrKranz> Laney, bdrung: any suggested short name/extended name for an alioth project
[19:04] <bdrung> DktrKranz: short name: ubuntu-dev
[19:05] <bdrung> DktrKranz: i want to add the rewrite of suspicious-source before the release of 0.101
[19:05] <DktrKranz> OK, I'm going to ask for the team creation
[19:06] <Muscovy> I'm trying to import a package to Ubuntu (http://revu.ubuntuwire.com/p/shellinabox) but despite the .dsc file listing the .orig tarball, the tarball is never uploaded. Could anyone help?
[19:06] <tumbleweed> Muscovy: the .changes file needs to list the .orig tarball
[19:06] <bdrung> Muscovy: build the source with debuild -S -sa
[19:06] <Muscovy> Ok.
[19:08] <Muscovy> Thanks, it's uploading now.
[19:10] <porthose> DktrKranz, done :) http://mentors.debian.net/debian/pool/main/a/ampache/ampache_3.5.4-5.dsc
[19:11] <DktrKranz> porthose: did you change just that?
[19:11] <porthose> DktrKranz, yes
[19:11] <DktrKranz> I already adjusted it locally, so I avoid to refetch it :)
[19:12] <porthose> :)
[19:12] <DktrKranz> done
[19:12] <porthose> thx :)
[19:13] <Laney> bdrung and DktrKranz: Isn't pkg- the usual prefix?
[19:14] <bdrung> then pkg-ubuntu
[19:15] <Laney> I wonder if in future it could be expanded for other packages mainained by ubuntu developers
[19:19] <Laney> but, no, they probably shouldn't be isolated like that
[19:19] <DktrKranz> I asked for generic "ubuntu-dev", in case it will be useful for other things than package management
[19:19] <DktrKranz> in case, I'll turn that to pkg-ubuntu, or similar, if asked
[19:20] <Laney> ok
[19:26] <ripps> looks like somebody forgot to upload libcompizconfig to maverick before updating compiz
[19:35] <plars> I have a package that I've submitted to REVU a while back, but nobody seems to have commented on it yet.  The upstream author notified me today that he has a new upstream version.  Would it be more appropriate to update the original package with the new upstream version, or add a new dch entry for the update and upload that, or just wait to see if it goes in, and do it as an update after the fact?
[19:36] <shadeslayer> plars: update old package and upload to revu
[19:36] <plars> shadeslayer: ok, will do. Thanks
[19:36] <shadeslayer> i.e get new tarball + old debian folder
[19:36] <shadeslayer> and go from there ;)
[19:36] <plars> but just keep the old version right?
[19:36] <plars> well
[19:37] <plars> I guess I would have to change the version, since it is a new upstream, but don't add a new changelog entry is what I mean, right?
[19:37] <shadeslayer> plars: ill show you a chagelog hold on
[19:38] <shadeslayer> plars: https://edge.launchpad.net/ubuntu/+source/kde4libs/+changelog
[19:38] <shadeslayer> see how the version keeps getting bumped
[19:39] <plars> (still trying to get there... :)
[19:39] <plars> lp timing out bad for me today
[19:40] <shadeslayer> plars: yeah seems so.. some people complained on #launchpad.. i guess its because of maverick alpha 3
[19:40] <shadeslayer> too much pressure
[19:41] <plars> shadeslayer: I understand how to make new entries, just that I figured it would seem kind of odd to have a brand new package with more than one debian changelog entry in it, especially since one of them references a version that was never uploaded to the archive
[19:42] <shadeslayer> hmm.. id rather have a changelog entry about that package.. since it was uploaded to revu
[19:42] <plars> ok
[19:45] <micahg> shadeslayer: idk about that...that seems weird since REVU isn't an official repo and just a staging ground
[19:46] <shadeslayer> micahg: but when someone views that package, and has also viewed it earlier, then the guy/gal might be in a fix as to what changed
[19:46] <micahg> shadeslayer: isn't there a comment system in REVU?  you certainly can't have a version in the first changelog as if it's released, it would have to be UNRELEASED for the first changelog if anything
[19:47] <shadeslayer> yes, the first entry will have to have UNRELEASED
[19:47] <Laney> Some people prefer both, sup to you/the sponsor
[19:47] <shadeslayer> i thought plars would know about that  :)
[19:48] <shadeslayer> Laney: yeah UNRELEASED is usually followed in the bzr system.. and i find that the best :)
[19:48] <shadeslayer> but then again.. im not a MOTU/Sponsor
[19:49]  * micahg neither :)
[19:50] <shadeslayer> Laney: btw suppose i have contributed towards main more ( like core KDE packages ) will that be considered in MOTU application?
[19:51] <Laney> You can put all of your stuff down
[19:51] <shadeslayer> did a few merges/syncs in universe only
[19:51] <shadeslayer> oh goody
[19:51] <Laney> can't comment on what the DMB will do with it
[19:51] <shadeslayer> hmm.. ok
[19:54] <micahg> shadeslayer: you don't do anything w/the universe KDE pacakges?
[19:54] <shadeslayer> micahg: i try to :P
[19:54] <shadeslayer> but usually get sidetracked into main
[19:54] <micahg> shadeslayer: that counts towards MOTU :)
[19:55] <shadeslayer> yes i know
[19:55] <shadeslayer> i did a few merges and stuff... but then got pulled into main
[19:55] <micahg> shadeslayer: so, you might want to go for kubuntu-dev first and then MOTU later
[19:55] <Laney> but if you're not interested in universe packages, maybe another team is more appropriate than MOTU
[19:55]  * micahg did something similar
[19:56] <shadeslayer> Laney: i am interested.. but i get handed main stuff by #kubuntu-devel :P
[19:56] <Laney> more experience is always good
[19:56] <shadeslayer> like currently me and Quintasan are reviving project neon which provides nightly kde builds
[19:57] <shadeslayer> and then i got my first debian package into sid
[19:57] <shadeslayer> which was syncd to ubuntu..
[19:59] <shadeslayer> Laney: https://edge.launchpad.net/~rohangarg/+related-software << as you can see.. not alot of universe work :)
[19:59] <Laney> perhaps you want kubuntu developer
[20:00] <shadeslayer> hmm.. maybe.. i was thinking of MOTU -> Kubuntu Dev
[20:00] <shadeslayer> but might as well do it the other way around
[20:01] <Laney> such a linear path doesn't have to exist any more :)
[20:01] <shadeslayer> i know.. lex79 was approved as kubuntu dev, but was not a MOTU
[20:06] <Quintasan> shadeslayer: just get me or/and someone "high-ranked" from #kubuntu-devel to attend your MOTU meeting
[20:06] <Quintasan> :P
[20:06] <shadeslayer> lol
[20:07]  * shadeslayer grabs Riddell apachelogger and Quintasan 
[20:07] <shadeslayer> Jontheechidna aint around :P
[20:07] <shadeslayer> maco too! :D
[20:07] <apachelogger> huh?
[20:08] <apachelogger> what is this highlighting in the middle of the night about?
[20:08] <maco> im not high rank in kubuntu
[20:08] <shadeslayer> maco: hows the python confrence
[20:08] <geser> shadeslayer: get them all comment (or even endorsements) on your application page
[20:08] <maco> i updated a kubuntu package successfully once
[20:08] <maco> shadeslayer: python conference?
[20:08] <maco> and unsuccessfully once as well :P
[20:08] <shadeslayer> arent you at one?
[20:08] <maco> no
[20:08] <maco> im at debconf
[20:09] <shadeslayer> from identi.ca feed : ..  im in the python talk .. :P
[20:09] <Laney> shadeslayer: I recommend you do more work on universe packages to see if motu is what you actually want
[20:09] <shadeslayer> Laney: ok
[20:10] <Laney> or just carry on working with kubuntu if that's what you like :)
[20:10] <geser> shadeslayer: that one probably: http://penta.debconf.org/dc10_schedule/events/570.en.html
[20:10] <maco> shadeslayer: well if i was at a python conference, thatd describe ALL of them, now wouldnt it?
[20:10] <shadeslayer> geser: ah
[20:11] <shadeslayer> maco: yep.. hows debconf then? :)
[20:11] <maco> pretty good. im gonna go wander to the hacklab for a bit of poking at qt
[20:12] <apachelogger> debconf \o/
[20:12]  * apachelogger never gets invited to debconf ... supposedly needs to do more work in debian
[20:13] <geser> apachelogger: one needs an invitation for debconf? I assumed one can attend if one wants
[20:18] <shadeslayer> all the fun stuff happens in the US/Europe :P
[20:18] <apachelogger> geser: I am so lazy I only act upon invitations ^^
[20:19] <tumbleweed> shadeslayer: yeah, sucks to be in a neglected part of the world :)
[20:19] <shadeslayer> yep
[20:20] <shadeslayer> particulary india where there is not alot of FOSS movement
[20:20] <apachelogger> ...one must invent one's own fun then
[20:20] <apachelogger> like they did with camp KDE
[20:21] <shadeslayer> bye everyone.. night
[20:23] <dyfet> ogra: ping
[21:24] <vish> do debian/control description changes have to be done by UIF or documentation string freeze , or does the Freeze not matter for changes in /control?
[21:46] <james_w> vish: the freeze is for translators and documenters, so it depends on whether they are going to be translating the strings, including them in documentation or screenshots etc.
[21:54] <vish> james_w: ah , ok. thanks
[23:12] <valavanisalex> Hi all - can anyone help with a package merge issue?