[00:08] <persia> lifeless: That helped some.  DragAcceptFiles had no matches.  Drag and SDL_ACTIVEEVENTS have 85 common matches.  Thanks.
[00:09] <lifeless> de nada
[03:33] <wgrant> http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20100407-lucid.html is now updating hourly from the in-progress archive rebuild.
[03:40] <wgrant> Now http://qa.ubuntuwire.org/ftbfs/test-rebuild-20100407/.
[03:42] <micahg> wgrant: I'm curious, were the rebuilds on udd not sufficient?
[03:47] <wgrant> micahg: An LP rebuild was started yesterday.
[03:48] <wgrant> lucas' don't cover them.
[03:50] <wgrant> (I don't know why it was started; I just organised the report)
[03:56] <micahg> wgrant: ok
[04:16]  * ScottK thinks it's because there's a item in the Beta release checklist to do it.
[04:16] <wgrant> Maybe London's a bit cold and needs a buildfarm of heaters.
[04:22] <lifeless> very cold - gulf stream moved, no ?
[05:02] <fabrice_sp> Linux000: got 5 minutes?
[05:07] <Linux000> Sure
[05:07] <Linux000> fabrice_sp: Sure
[05:07] <fabrice_sp> cool :-)
[05:08] <fabrice_sp> Linux000: it's about the DEP-3 header: it has to go into the patch you created, not as the header of the debdiff
[05:09] <Linux000> Ahh, then I've probably been uploading patches wrong too, the patch is the debdiff, right?
[05:10] <fabrice_sp> oh: I've just seen that you didn't do a patch with your change, but a direct source change. As the package uses quilt, you need to create a patch for that
[05:10] <fabrice_sp> the debdiff is a kind of patch, yes :-) I was speaking about the change in glock.py
[05:11] <Linux000> Okay, so how would I make the patch for this?
[05:11] <fabrice_sp> do you know how to use quilt?
[05:12] <Linux000> not really
[05:14] <fabrice_sp> ok. You first need to add a patch to the list pf patches managed by quilt. This is done by running 'quilt new <patch-name>'
[05:14] <fabrice_sp> as patch-name, check in debian/patches what are the name that are used
[05:14] <fabrice_sp> and use something similar
[05:15] <alkisg> Hi all. I'm the developer of a project with various files; shell scripts, images, desktop files etc, and it also has some python modules & executables. Could someone propose to me a similar package that I could use as a template to package mine?
[05:16] <fabrice_sp> Linux000: for example fix_glock_error.diff
[05:17] <Linux000> fabrice_sp: Thanks, trying to be short is not a strong point
[05:17] <fabrice_sp> Linux000: what do you mean?
[05:18] <fabrice_sp> alkisg: I don't have any in mind right now
[05:18] <alkisg> Thank you. Someone else?
[05:18] <Linux000> the name I was going for was to long for comfort
[05:19] <fabrice_sp> Linux000: ok :-) The name doesn't need to be long, as you will have a header in the patch that will explain it
[05:20] <Linux000> okay
[05:22] <fabrice_sp> alkisg: aubio ?
[05:22] <alkisg> fabrice_sp: no, no audio
[05:23] <alkisg> aah, aubio? heh
[05:23] <alkisg> OK, looking...
[05:24] <alkisg> (basically what I'm looking for is a simple, nice packaged package that also has some python modules included - I can mostly do the rest of the stuff...)
[05:25] <Linux000> pychess has python modules, if you need an example of that
[05:25] <ScottK> alkisg: If it's just the python stuff, pypolicyd-spf.
[05:25] <ScottK> Although if I were doing it now, I'd use debhelper 7 and not CDBS.
[05:26]  * alkisg is using debhelper 6 atm...
[05:27] <ScottK> Then pypolicyd-spf is not a bad basis for Python stuff.
[05:27] <alkisg> Thank you all, /me looks...
[05:27] <ScottK> You could also look at pyspf for an example of multiple binary packages.
[05:28] <alkisg> Hmm yeah, that would be useful as well, I do need 2 binary packages.
[05:29] <Linux000> fabrice_sp: I have the new patch in quilt and my source, do I add the file(glock.py) to the patch, then patch it, or vice-versa
[05:32] <fabrice_sp> yes: you first need a clean glock.py file, and then, you can add you file, patch it again, and use quit refresh to add the modifications to the patch
[05:32] <Linux000> great
[05:34] <fabrice_sp> when done, you just have to add at the beginning of the patch, the header you want
[05:37] <fabrice_sp> Linux000: by the way, origin should point to the svn commit entry with
[05:37] <fabrice_sp> s/with//
[05:37] <Linux000> should this patch also have the changelog updated?
[05:40] <fabrice_sp> you should name the patch in the changelog, like 'fix_glock_error.diff: fix .... (LP: #534761)'
[05:40] <fabrice_sp> with the LP: stuff, the bug report will be fixed as soon as the fix will be uploaded and accepted into the archive
[05:40] <fabrice_sp> makr as fixed, I mean
[05:41] <Linux000> fabrice_sp: Where can I find the svn, and with what?
[05:42] <fabrice_sp> Linux000: http://code.google.com/p/pychess/source/browse/
[05:42] <fabrice_sp> and browsing by source, you will find the commit that makes this change. Let me check
[05:46] <fabrice_sp> Linux000: seems to be this one: http://code.google.com/p/pychess/source/detail?r=1653
[05:47] <Linux000> Okay, I see now, that goes in as origin, also, how do I get the file from quilt? I can't seem to find it.
[05:49] <fabrice_sp> you don't have it created in debian/patches ?
[05:49] <Linux000> from the root of the source tree, I ran '
[05:49] <Linux000> '
[05:49] <Linux000> sorry
[05:49] <Linux000> i ran quilt new glock_error_fix.diff
[05:50] <fabrice_sp> then you ran "quilt add lib/pychess/System/glock.py" ?
[05:50] <Linux000> yes
[05:51] <fabrice_sp> made modifications to the file and ran quilt refresh ?
[05:51] <Linux000> yes
[05:51] <fabrice_sp> so it should be in debian/patches
[05:51] <fabrice_sp> hmm, what is the value of QUILT_PATCHES variable?
[05:52] <fabrice_sp> by default, patches goes into patches and not debian/patches, IIRC
[05:52] <Linux000> How would I find that?
[05:52] <Linux000> NVM, I found it, it was under patches, not debian/patches
[05:53] <fabrice_sp> ok: that's why you need to set QUILT_PATCHES to debian/patches next time
[05:53] <Linux000> understood
[05:53] <fabrice_sp> so you need to move the patch to debian/patches
[05:53] <fabrice_sp> and update the series file
[05:54] <Linux000> Ok
[05:54] <fabrice_sp> and delete the roo patches directory, to avoid having it in the debdiff twice
[05:55] <Linux000> so, that patch file gets the headers and is uploaded to lauchpad?
[05:57] <fabrice_sp> you can upload the patch to launchpad, or generate a debdiff between your package and the actual one and uplaod it to launchpad. The latter is prefered from a sponsor point of view as it's less work :-)
[05:57] <Linux000> debdiff the compiled package, right?
[05:59] <fabrice_sp> the source package
[05:59] <Linux000> Good, my computer just got wiped (some mountall error in lucid) so I have no cdbs, devscripts, or anything
[05:59] <fabrice_sp> what sponsors do is download the actual source, review and apply the debdiff, and if ok, upload the resulting source package
[06:00] <Linux000> ok, I thought the built packages were uploaded to the repository
[06:00] <fabrice_sp> Linux000: I have a dual boot for that reason :-) (and looking after kvm right now)
[06:01] <Linux000> I had windows, so I lucked out and got ubuntu back, I needed a reminder as to why I use ubuntu:)
[06:02] <fabrice_sp> :-)
[06:02] <fabrice_sp> no windows at all here: only live-usb's to recover things :-)
[06:02] <fabrice_sp> (and dual boot now!)
[06:02] <fabrice_sp> with karmic
[06:04] <Linux000> Well, I wish I could get rid of windows, but I also program some WAGO PLC's and they need windows to program, and oddly enough, my debian touchscreen wants a windows IDE
[06:05] <Linux000> How would I get the debdiff of the source?
[06:06] <fabrice_sp> you have to generate a dsc file first with debuild -S
[06:06] <Linux000> ahh, okay
[06:06] <fabrice_sp> and then debdiff the 2 dsc files
[06:06] <Linux000> I don't have to sign it, right?
[06:06] <fabrice_sp> no
[06:09] <Linux000> this will have to wait until tomorrow, to late for me, it should be up around 4~5 CST
[06:09] <fabrice_sp> np: I have to go to work now :-)
[07:06] <micahg> siretart: will you be looking into the vlc build failure, bjsnider gave me a patch earlier which I was going to try over the weekend to port it to xul192
[07:09] <siretart> micahg: I just noticed the build failure, but am currently very short on time
[07:09] <siretart> micahg: if you could just fix it, that would be really great!
[07:09] <micahg> siretart: ok, so I'll take it then
[07:09] <siretart> thanks
[07:15] <micahg> siretart: critical?
[07:16] <dholbach> good morning
[07:18] <siretart> micahg: without having it fixed, we cannot do any updates, including security and other important updates. I consider that pretty critical
[07:19] <micahg> siretart: it's a universe package...that's the same for any other FTBFS
[07:19] <siretart> micahg: oh, are severities now distro global (again)? did I miss something? - anyways, feel free to downgrade
[07:20] <micahg> siretart: maybe I'm missing something idk
[07:20] <siretart> I wanted this bug to appear at the top of the vlc bugs
[07:21] <micahg> siretart: does MOTU have different severity settings as opposed to triagers (like status)?
[07:21] <siretart> micahg: I hope not
[07:22] <micahg> siretart: it would seem then it's not severe until we need an update...I'm going to throw up a test build tonight
[09:53] <xteejx> bug 559054, can someone take a look at this please, think there's dependency problems with the new metacity package
[09:55] <xteejx> may affect upgrading users to beta 2
[09:57] <joaopinto> xteejx, I believe that is a known issue already being looked at
[09:57] <xteejx> ahh ok joaopinto, didn't see a duplicate in LP thought it wasn't made aware
[11:56] <pmcenery> Hi motu's. I filed this one this morning in the hope that it is seen as important enough to be included. bug #558946
[11:56] <pmcenery> After a long slog... I have finally managed to get the package sponsored.
[11:57] <hyperair> doesn't look sponsored to me.
[11:57] <pmcenery> Do we have any MOTU's with iPhones to be able to test it?
[11:57] <pmcenery> Sorry... Debian sponsored.
[11:58] <hyperair> aah i see.
[11:59] <pmcenery> You dont need a sponsor for a sync from what I can tell. Or do you?
[11:59] <hyperair> you do.
[11:59] <hyperair> but first you need the FFe acked.
[11:59] <hyperair> go poke some #ubuntu-release people =)
[11:59] <pmcenery> I guess it would need someone with an iPhone to test. Do we have MOTU's with such evil devices?
[12:00]  * hyperair shrugs
[12:00] <pmcenery> hyperair: thanks. Will give it a try
[12:00] <hyperair> i've got friends with them, and i wouldn't be opposed to getting one myself, if i didn't already have a good, working phone already.
[12:04] <pmcenery> hyperair: understood. I'm not religious about them as some people are. I have one, it works, and ipheth works quite well, so I thought I'd package it up properly.
[12:05] <pmcenery> A google of popcon and ipheth shows that my PPA package has been quite popular
[12:07] <hyperair> pmcenery: i'd imagine so.
[12:07] <hyperair> pmcenery: and i saw your RFS on debian-mentors sometime back. congrats on getting it into debian =)
[12:07] <hyperair> i know how hard it is, first hand.
[12:08] <pmcenery> hyperair: lol. Yes. It seems that once you have worked with a couple of DD's, it gets easier. They come to trust your work...
[12:09] <hyperair> pmcenery: yes, of course. it's the same everywhere
[12:09] <hyperair> pmcenery: also, it's easier to get things that have a team with DDs watching over the set of packages
[12:09] <hyperair> e.g. CLI packages are easy to get in as we've got two DDs in the team
[12:09] <hyperair> python packages are also fairly easy to get in
[12:13] <pmcenery> hyperair: Yes. I ended up joining the debian-perl team during the process of getting slimrat sponsored. Although in the end I had a non perl DD sponsor me. The perl team were not too interested in sponsoring apps, only modules.
[12:16] <hyperair> heh i see.
[12:16] <pmcenery> I'll hang around here a while... hopefully someone will be brave!
[12:16] <hyperair> i would if i had an iphone =\
[12:16] <hyperair> feel like donating one to me? ;-)
[12:18] <pmcenery> lol. I've only got one. And I think the wife will be getting it when I get the next one...
[12:19] <pmcenery> Well, next phone! Not guarantee it will be an iPhone
[12:19] <hyperair> heheh
[12:31] <Aquina> can someone lend me an ear? It's because I started to use Bazaar with Launchpad.
[13:15] <joaopinto> anyone experienced with reprepro ?
[13:21] <Rhonda> joaopinto: Just ask your question - that will get you a better propability of helpful answers. :)
[13:21] <joaopinto> except that I maybe talking to the wind ;)
[13:21] <joaopinto> the reprepro man page is not very clear
[13:21] <Rhonda> You may that even if someone claims to be experienced with $foo.
[13:21] <joaopinto> is copysrc expected to copy also the source package ?
[13:22] <Rhonda> Actually it doesn't "copy" anything, the package stays in the pool at the same place. It just "copies" the medatdata in its database and the Sources file.
[13:23] <joaopinto> right, I am refering to the meta data
[13:24] <joaopinto> is it expected to copy the source metatada to the target release Sources file ?
[13:24] <Rhonda> I would very much think so that that's its job, yes.
[13:24] <Rhonda> Though an reprepro export run afterwards never can hurt.
[13:25] <joaopinto> no, according to the man page its job is to copy packages whose source (Source:?) match the specified name
[13:25] <joaopinto> it does so for binary packages produce from a given source, but is not clear if it does or should do the same for the source package
[13:25] <joaopinto> produced
[13:26] <Rhonda> It doesn't "every package be it dsc, deb or udeb"
[13:27] <Rhonda> The dsc part is pretty clear source package. :)
[13:27] <Rhonda> s/It doesn't //
[13:28] <joaopinto> ok :P
[14:01] <mhall119> jdstrand: are you around?
[14:02] <jdstrand> mhall119: yes
[14:02] <mhall119> jdstrand: is there anything you need to get a FFe for the other 2 qimo packages?
[14:02] <mhall119> qimo-games isn't terribly useful on it's own
[14:03] <jdstrand> mhall119: they all need an FFe. I think it would be fine to have them all in one bug
[14:03] <mhall119> okay, there are currently 3 needs-packaging bugs for the 3 packages
[14:03] <jdstrand> mhall119: since they are small and dependent on each other, aiui
[14:03] <mhall119> do I need to make an additional FFe bug?
[14:04] <jdstrand> mhall119: oh, if there are already 3 bugs open, then you probably should do the one more for qimo-games
[14:04] <jdstrand> mhall119: since they are already separated. do mention how they relate to each other though
[14:04] <mhall119> qimo-games has already been accepted, the other two have not
[14:05] <jdstrand> I think I am confused
[14:05] <mhall119> ok, I'll add comments to the other 2
[14:05] <jdstrand> there are 3 total
[14:05] <mhall119> yes
[14:05] <jdstrand> 1 accepted, two not?
[14:05] <mhall119> qimo-games was accepted
[14:05] <mhall119> yes
[14:05] <mhall119> qimo-wallpaper and qimo-session have not
[14:05] <jdstrand> I see, then wither wait for review of the other two, are ask someone in ubuntu-release to look at them (I am not a member of ubuntu-release)
[14:06] <mhall119> qimo-games was accepted a couple months ago, you rejected the other two because I needed to expand on the copyrights
[14:06] <jdstrand> s/are/or/
[14:06] <mhall119> so I don't think qimo-games needed an FFe
[14:06] <mhall119> is there a channel for ubuntu-release?
[14:07] <jdstrand> I think qimo-games maybe didn't get uploaded? I don't remember looking at it specifically, but I might not remember correctly
[14:07] <jdstrand> mhall119: #ubuntu-release
[14:07] <mhall119> they were all uploaded
[14:08] <mhall119> qimo-games is in the repo already
[14:08] <mhall119> the other two have been uploaded, but not accepted
[14:18] <Ciemon> afternoon all, having just put my first debdiff on a bug using https://wiki.ubuntu.com/Bugs/HowToFix I wonder if there's a similar guide that explains using bzr and launchpad? I can't seem to find one.
[14:28] <nigelb> Ciemon, https://wiki.ubuntu.com/DistributedDevelopment/Documentation
[14:31] <evilshadeslayer_> dholbach: ping
[14:32] <evilshadeslayer_> whom should i talk to in order to adopt rekonq ?
[14:33] <evilshadeslayer_> ill be in and out.. so can someone please point me to the right people? ( ive already read the wiki links )
[14:33] <dholbach> evilshadeslayer_: pong
[14:33] <dholbach> I'm not sure I'm the best person to talk about rekonq
[14:33] <Laney> there is too much cdbs magic in pandoc
[14:33]  * Laney goes cross-eyed figuring it out
[14:33] <evilshadeslayer_> dholbach: ok so who then? :)
[14:34] <evilshadeslayer_> dholbach: i already do the docs for them... so i can easily adopt this package...
[14:34] <evilshadeslayer_> ( thats my opinion )
[14:34] <Ciemon> nigelb: thanks
[14:35] <nigelb> np :)
[14:35] <evilshadeslayer_> Tonio__: i see that your the last person to update the package :)
[14:35] <dholbach> evilshadeslayer_: can you try to explain what you want to do? :)
[14:35] <evilshadeslayer_> dholbach: i want to adopt a upstream ( rekonq )
[14:36] <dholbach> ahhhhh nice
[14:36] <evilshadeslayer_> dholbach: ive been meaning to do this since some time
[14:36] <dholbach> evilshadeslayer_: a good first step might be to have a look at the changelog of the package and get in touch with the people who worked on the package before, so you get to know ubuntu and debian maintainers which is a good start
[14:36] <dholbach> evilshadeslayer_: also check out the web page I mentioned - it should give you a few good practical tips
[14:37] <evilshadeslayer_> dholbach: lol... i work with the rekonq devs on a daily basis... i practically know all the dev work they do.. also i build rekonq everyday :P
[14:37] <dholbach> awesome
[14:37] <dholbach> :-D
[14:38] <evilshadeslayer_> dholbach: ok but how do i officially adopt it? like do i subscribe a ML or something?
[14:38] <dholbach> it's a good idea to track the bug reports - you can subscribe to the package
[14:38] <dholbach> also have a chat with the people in #ubuntu-bugs
[14:38] <evilshadeslayer_> dholbach: ive subscribed to the meta kubuntu bugs list
[14:39] <dholbach> wow
[14:39] <evilshadeslayer_> hehe.. yeah i just deleted about 13MB's worth of bug mail :P
[14:40] <evilshadeslayer_> from my mail box that is :)
[14:40] <evilshadeslayer_> i guess i should just wait for Tonio__ ...
[15:23] <ScottK> maco: You ought to have a look at Debian Bug #577087.
[16:22] <jdstrand> mhall119: hey. sorry about this, but I need to reject the packages that were uploaded to the archive. I don't know what happened, but the source are like a source within a source. you can see what I mean by viewing the packages at https://launchpad.net/ubuntu/lucid/+queue?queue_state=0&queue_text=qimo
[16:23] <jdstrand> mhall119: eg, a dpkg-source -x ...dsc results in:
[16:23] <jdstrand> qimo-wallpaper/qimo-wallpaper_2.0.0-ubuntu1.dsc
[16:23] <jdstrand> qimo-wallpaper/qimo-wallpaper_2.0.0-ubuntu1.diff.gz
[16:23] <jdstrand> among other things
[16:23] <zgreg> https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/559005
[16:23] <zgreg> this is annoying...
[16:24] <jdstrand> mhall119: perhaps this is due to highvoltage's upload? I don't know
[16:26] <jdstrand> mhall119: you want an orig.tar.gz, a .dsc, a .diff.gz. a dpkg-source -x on the dsc will untar the orig.tar.gz and apply diff.gz to it (which ideally will only touch the debian/ dir). if you are aware of all that, just take it up with highvoltage and/or revu
[16:26] <jdstrand> mhall119: this does not affect the FFe. upload new packages and we'll get the processed
[16:27] <Tonio__> evilnhandler: hey
[16:27] <Tonio__> we won't go with rekonq right now
[16:27] <Tonio__> evilnhandler: we probably will switch to rekonq one day
[16:28] <Tonio__> evilnhandler: there are still too many bugs of features lacking with it right now
[16:42] <zooko`> Folks: we had a critical performance bug in Tahoe-LAFS (actually in foolscap) and we think we fixed it, but we have one report that it still exists after the upgrade, but we can't reproduce it.
[16:42] <zooko`> Anybody else want to try?
[16:43] <zooko`> maco uploaded the update of foolscap which I think fixed the bug.
[16:43] <zooko`> https://bugs.launchpad.net/ubuntu/+source/foolscap/+bug/548993
[16:44] <zooko`> The details about the attempts to reproduce the problem are in http://tahoe-lafs.org/trac/tahoe-lafs/ticket/983
[16:44] <zooko`> Basically, if you can upload, say, a 500 GB mutable file to your localhost with the current version in Lucid, then we're good. :-)
[16:45] <zooko`> In a different topic, how do I tell launchpad that this is a bug in pycentral, not in foolscap: https://bugs.launchpad.net/ubuntu/+source/foolscap/+bug/388855
[16:45] <ScottK> zooko`: Just change the affected package.
[16:50] <zooko`> ScottK: there doesn't appear to be a package for pycentral.
[16:50] <zooko`> I could at least *unset* it from foolscap.
[16:51] <zooko`> There I set it to "invalid".
[16:51] <ScottK> zooko`: How about python-central
[16:51] <zooko`> I looked for that! I'll look again.
[16:52] <zooko`> " There is no project in Launchpad named "python-central". Please search for it as it may be registered with a different name."
[16:54] <maco> zooko: python-central package, not project
[16:55] <ScottK> zooko: Actually I suspect that's not a bug at all.  I suspect the user played with the symlink for /usr/bin/python.
[16:55] <maco> zooko: i just added a python-central task to it
[16:56] <maco> zooko: for future reference, click "also affects distribution" to set the package within a distro that is affected
[16:56] <zooko> Okay. Anything else I should do about it?
[16:56] <zooko> maco: I don't get it. Isn't a "distribution" a version of Ubuntu such as Karmic, Lucid?
[16:56] <maco> zooko: ubuntu is a distribution
[16:56] <maco> zooko: baltix linux also uses launchpad
[16:57] <maco> so if you want to mark a package within ubuntu or baltix, you click "also affects distribution", select which distro from the drop down, and put the package name in the textbox
[16:57] <zooko> Ah, so if I click on "also affects distribution" I'll then be able to find python-central-as-part-of-ubuntu ?
[16:57] <zooko> Or are you just saying I should have marked it as also affecting Ubuntu?
[16:58] <maco> zooko: the first one
[16:58] <maco> but i just did it for you
[16:58] <zooko> Thanks.
[16:58] <zooko> The parts about different people trying to reproduce that performance bug are here: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/983#comment:7
[18:14] <delimiter> hi folks. I'm trying to backport puppet and facter from lucid to hardy. facter builds fine but puppet gives me this error from pbuilder build: pbuilder-satisfydepends failed - presumably because it needs the newer version of facter and that's not in the base.tgz. How can I fix this?
[18:24] <kirkland> is it possible to have a symlink installed in /etc be treated like a conffile?
[18:33] <kirkland> nevermind, cjwatson answered that in #ubuntu-devel
[18:33] <kirkland> short answer: DFDT
[19:06]  * hyperair kicks dpkg-source's @ubuntu.com check
[19:06] <xteejx> Hey guys
[19:06] <hyperair> hello.
[19:07] <xteejx> Noticed another dependency problem in today's updates, hasn't been reported. bug 559447
[19:09] <ScottK> xteejx: Are you on amd64?
[19:09] <xteejx> yeah ScottK
[19:09] <ScottK> xteejx: The package isn't fully built.  Just wait.  No need to report bugs on stuff like that.
[19:10] <xteejx> ScottK: Ahh I'll close it, sorry didn't realise. For future reference...in cases like these is it safe to just close and do normal updates?
[19:10] <ScottK> xteejx: Generally I'd wait and try again later.
[19:11] <ScottK> These things are a normal part of running the development release.
[19:11] <xteejx> I haven't actually came across it yet to be honest, been lucky updating at the right time I guess :)
[19:45] <cnd> if you're creating a package based on the state of the sources in a git tree on a certain date, what version string is suggested?
[19:45] <cnd> say for today's date?
[19:52] <kklimonda> cnd: hmm.. for example last_version+git20100409.<first eight characters from the commit hash>-XubuntuY
[19:53] <cnd> kklimonda: that seems very long and obtuse, is that really suggested?
[19:53] <cnd> also, there's no "last_version"
[19:54] <cnd> I rememberd mtd-utils doesn't put out releases either, so I see that it's version is 20090606-1
[19:55] <kklimonda> cnd: well, the problem with using only the current date is that if they ever release stable package you'll have to use epoch. of course epoch is exactly for situations like that
[19:56] <kklimonda> cnd: I don't think there is a single, official way of naming releases from various repositories - the one I've given you is the one I like the most
[19:56] <cnd> ok
[19:56] <cnd> there's not a huge amount of commits on a given day
[19:56] <soren> POX: Hey, man. Do you have a copy of the .dsc and .debian.tar.gz from the python-cloudfiles upload?
[19:56] <cnd> really, it goes quite some time without commits
[19:57] <soren> POX: Thanks for that, by the way!
[19:57] <cnd> so I think I'll leave off the git hash
[19:57] <kklimonda> cnd: you can grep though /var/lib/apt/lists/ to see what are others conventions
[19:57] <kklimonda> cnd: I think hash may be useful to regenerate the orig tarball
[19:58] <cnd> kklimonda: it's slightly more useful, but if there weren't any commits on that day it's unnecessary
[19:59] <cnd> and not many people are going to download the orig tarball based strictly on the version string
[19:59] <kklimonda> cnd: sure - as I said, the final decision is up to the maintainer
[19:59] <cnd> ok
[20:03] <POX> soren: http://people.debian.org/~piotr/python-cloudservers_1.0~a5-1.d{ebian.tar.gz,sc}
[20:05] <POX> (I didn't check/upload python-cloudfiles, IIRC)
[20:12] <persia> soren: If you upload that, consider -0ubuntu1 or similar just in case there is an issue.
[20:17] <arand> An SRU for universe (Bug #510571), would it be prudent to poke someone from the SRU team? If so who/how?
[20:21] <soren> soren: Sorry, that was a typo.
[20:21] <soren> Hehe..
[20:21] <soren> Good one.
[20:21] <soren> POX: Sorry, cloudfiles was a typo. I meant cloudservers. Thanks!
[20:22] <soren> persia: Hmm... Yeah, I guess that's a good point.
[20:26] <soren> persia: Done so. Very good point. Hadn't thought of that.
[20:28] <persia> soren: 99% of the time the ftp-masters don't reject it, but that 1% hurts :)
[20:32] <ScottK> It goes either way.  I've rejected stuff that was accepted by Debian.
[20:42] <persia> Sure, but that doesn't cause issues with version numbers.
[20:44] <POX> ScottK: (just curious) which package was it?
[20:44] <ScottK> No.  In the cases I was involved in the Debian maintainer uploaded a fixed version and we sync'ed that.
[20:44] <ScottK> POX: I don't recall exactly, it was something R related.
[20:44] <ScottK> Two of them.
[20:45] <POX> ok then (/me rejected every single Ubuntu accepted package so far :P)
[20:45] <Laney> I thought that AAs didn't review packages already in Debian
[20:50] <sebner> baaad POX
[20:50]  * sebner throws rotten tomatoes at POX :P
[20:50] <POX> but I also rejected (almost) every single NEW mentors.d.n package (DktrKranz was one of two guys who managed to get it in)
[20:51] <POX> I mean, NEW without serious comments
[20:52] <Laney> I've not had a NEW package rejected (yet)
[20:52] <POX> sebner: still waiting for you to join DktrKranz :P
[20:52] <Laney> :cool:
[20:52] <sebner> POX: with that attitude you can wait long :P
[20:52] <sebner> Laney is teehh geek!
[20:53]  * Laney releases sebner under the WTFPL
[20:54]  * sebner is FREEEEEEEEEEEEEEEEEe
[20:54]  * soren admires POX' keen eye
[20:55] <sebner> soren: pfff, he's just EVIL :P
[20:56] <soren> "delightfully picky"
[20:57]  * sebner uploads *any* package that's lintian clean even if it does rm -rf / in postinstall. lintian is god \o/  *muahahahahhaha*
[20:57] <POX> soren: there's another competition, BTW - uploads without a comment in a row - DktrKranz and Jonathan Wiltshire have 4 (but DktrKranz decided to quit the game)
[20:57]  * Laney coughs
[20:58] <sebner> DktrKranz: pussy!
[20:59] <Laney> He got @debian.org and ftp team powers
[20:59] <Laney> I'd call that pretty hardcore
[20:59]  * Laney bows down
[20:59] <sebner> DktrKranz: haha, I told ya ;)
[21:00] <sebner> Laney: I expect from him to become president of the world, nothing less
[21:09] <lfaraone> cnd: do still intend to submit rinputd to Debian? I noticed you filed debbugs 569042 two months ago, and was wondering if you wanted someone to maintain it.
[21:10] <cnd> lfaraone: I'm very new to all this, but it's already been sponsored and uploaded to ftp-master
[21:10] <cnd> it's in the NEW queue, so I assume now I wait for an ftp-master to review it?
[21:10] <cnd> been waiting for 5 days
[21:11] <lfaraone> cnd: ah, didn't check there :)
[21:11] <cnd> lfaraone: how long do packages usually sit in the NEW queue
[21:11] <lfaraone> cnd:  NEW can take anywhere from a few days to a month. For my packages, it's been an average of 10/12 days
[21:12] <cnd> ok
[21:12] <ScottK> hyperair: What version of sugar is Lucid supposed to have.  It appears to have pieces of several at the moment.
[21:12] <lfaraone> ScottK: Debian packages a bunch of versions.
[21:12] <hyperair> ScottK: sugar has versions?
[21:12]  * hyperair only cares about sugar levels in his blood
[21:13] <lfaraone> hyperair: http://sugarlabs.org/ :)
[21:13] <hyperair> aha!
[21:13] <hyperair> *that* sugar.
[21:13] <hyperair> i'm assuming a wrong ping then
[21:13] <ScottK> Ah.  I think I meant that for highvoltage.  Sorry.
[21:14] <hyperair> np
[21:14] <lfaraone> right now in karmic we have python-sugar-toolkit-0.88, sugar-0.86, sugar-activities at 0.83, sugar-artwork-0.88, sugar-browse-activity-0.86, sugar-chat-activity-0.86, sugar-emulator-0.88, sugar-read-activity-0.86, sugar-presence-service-0.88,  sugar-session-0.88, and sugar-tools-0.88
[21:14] <lfaraone> s/karmic/lucid/
[21:15] <ScottK> yep.
[21:16] <lfaraone> ScottK: it's complicated. 0.88 is the latest stable, 0.84 is in most deployments, but 0.86 will be on the next OLPC XO laptop.
[21:16] <ScottK> lfaraone: Someone needs to sort out what we have.
[21:17] <lfaraone> ScottK: upstream ideally would like to have 0.88 shipped, as we'd rather not support .84 for all eternity.
[21:17] <ScottK> There are bits of 0.84 and 0.86 that aren't buildable.
[21:17] <ScottK> lfaraone: Are you involved upstream with sugar?
[21:17] <lfaraone> ScottK: yes, I'm a systems administrator.
[21:18] <lfaraone> (I maintain some of their servers, that is)
[21:18] <highvoltage> ScottK: would it be possible to bring it up to .88 via SRU?
[21:18] <ScottK> lfaraone: OK.  Someone who understands all the sugar packages ought to sort through what we have/need/don't need.
[21:18] <ScottK> highvoltage: Generally not, but as different sugar versions are packaged to be co-installable, we could have more than one.
[21:19] <lfaraone> ScottK: well, I'm in pretty good contact with the development team.
[21:19] <ScottK> The thing is it doesn't appear to me that we have ANY version that is complete and buildable right now.
[21:19] <lfaraone> yes, it is rather a mess.
[21:20] <ScottK> So it would be great if you and highvoltage could put your heads together and figure out the best path forward.
[21:20] <ScottK> I don't care some much WHICH version as that we have at least one.
[21:21] <lfaraone> ScottK: in theory, we would be fine if we only shipped the shell, artwork, presence service, browse, and the toolkit. Users can download activities (Sugar Applications) through the prefered means of distribution, http://activities.sugarlabs.org/, a la Mozilla Addons.
[21:21] <highvoltage> ScottK: one of the sugar developers (or at least he was until a few months ago) lives quite close to me and he was quite enthusiastic about the ubuntu packages until he got a new job and adopted a baby, I'll also check if he has more free time now and try to reel him in
[21:21] <lfaraone> highvoltage: dfarning, right?
[21:21] <highvoltage> at the very least he could help bring me up to speed and fill some gaps
[21:21] <highvoltage> lfaraone: morgs (Morgan Collett)
[21:22] <ScottK> lfaraone and highvoltage: I've got a few hundred other packages to sort before release, so please figure it out.  Ping me if you need an FFe for something.
[21:22] <lfaraone> highvoltage: ah. I haven't heard from him since Intrepid.
[21:22] <lfaraone> ScottK: understood, we'll ask if we need something :)
[21:22] <ScottK> Excellent.
[21:23] <highvoltage> lfaraone: I think that's about when he officially stopped working as an employee for the sugar project, he was still involved for a bit afterwards though
[21:23] <lfaraone> highvoltage: would you agree my assessment of the bare-minimum is accurate, and a good base to start towards?
[21:24] <highvoltage> lfaraone: to be perfectly honest, my knowledge of sugar is very minimal, but that does sounds like a very rational and pragmatic approach, so yes
[21:24] <lfaraone> highvoltage: take a look at https://launchpad.net/~sugarteam/+archive/ppa , by the way. I haven't tested the packags, but they're supposed to work :)
[21:24] <highvoltage> lfaraone: nice, we should probably link to it somewhere on the edubuntu site if anyone adventurous wants to try it out and file some bugs
[21:25] <lfaraone> highvoltage: mk. I was never clear on this: where should PPA bugs be filed? :)
[21:25] <ScottK> Somewhere other than Ubuntu.
[21:26]  * lfaraone thinks he's asked this before, and I often get different answers.
[21:26] <ScottK> You can make an LP project with it's own bug tracker if you want
[21:26] <lfaraone> highvoltage: I guess we could use https://edge.launchpad.net/usr
[21:26] <lfaraone> highvoltage: and I can add you to ~sugarteam if you want.
[21:26] <highvoltage> yes I think creating a project and filing bugs against that is the right way to do it
[21:27] <highvoltage> lfaraone: that would be great
[21:27] <lfaraone> highvoltage: done, ~jonathan added
[21:28] <highvoltage> lfaraone: great, I think it would be a good addition to the edubuntu dvd's as an optional install when the packages are nice and ready
[21:34] <xteejx> How do I grab the source code for a specific arch?
[21:34] <lfaraone> xteejx: all arches have the same source code tarball...
[21:34] <soren> xteejx: Source code is the same across architectures.
[21:34] <jpds> xteejx: Erm... they're the same for all arches?
[21:35] <xteejx> oops :)
[21:36] <xteejx> thanks guys
[21:47] <xteejx> Guys, bug 557556, is that right about ppc64/PS3? Gives me the impression that it won't be worked on, although I think I might have found the problem
[21:48] <xteejx> something to do with the gst.GhostPad part of mixer.py
[21:51] <lfaraone> xteejx: well, it has a priority assigned. if someone knows about it, they'll propose a fix.
[21:51] <ScottK> Even better if you figure it out, you can attach a patch.
[21:52] <ScottK> The odds of it getting fixed go WAY up then.
[21:52] <xteejx> Well to be honest all I know is that the gst.GhostPad is part of gstreamer, but other than that I'm no use I'm sure plenty of others know that
[21:53] <lfaraone> xteejx: well, try to replicate the problem with a smaler testcase to isolate the bug.
[21:53] <ScottK> Put what you know in the bug and that'll help the next person to take a shot at it..
[21:54] <xteejx> Will do, and hope so!