[00:01]  * maxb re-raises the question about remove-patch, and questions the clean target's completeness
[00:02] <AdamDH> remove-patch was going to be used in clean target
[00:02] <maxb> well: (1) it isn't, and (2) it doesn't need a stamp file
[00:03] <AdamDH> whats wrong with the clean section?
[00:04] <maxb> Well, it doesn't remove src/, for a start
[00:05]  * coppro bugs MOTUs to REVU
[00:07] <AdamDH> so I need a rm -rf src anything else?
[00:09] <maxb> You should make a copy of your source package, do a build, and a clean, and then see if there are any differences (stuff left over). If there are, your clean isn't complete
[00:10] <directhex> so who wants to write a clean rule for my ikvm package/ think of it as, uh, a technical challenge!
[06:10] <dholbach> good morning
[06:13] <iulian> Morning dholbach.
[06:14] <dholbach> hiya iulian
[06:14] <iulian> How is it going?
[06:15] <dholbach> good good, just triaging the sponsoring queue :)
[06:15] <dholbach> how are you?
[06:16] <tmurder> is there some automagic way to check compliance with a Debian Policy Standards-Version (3.8.0) ?
[06:16] <fabrice_sp> Morning dholbach
[06:16] <dholbach> hiya fabrice_sp
[06:16] <iulian> dholbach: I have just woken up. I'm going my homework now.
[06:16] <iulian> s/going/doing
[06:16] <dholbach> iulian: hehe :))
[06:18] <tmurder> lintian.
[06:18] <iulian> Well, I must print something for school and my bloody ink is low.
[06:19] <fabrice_sp> sound familiar to me this kind of situation :-)
[06:20] <iulian> Heh
[06:22] <slytherin> persia: ping
[06:22] <slytherin> tmurder: lintian
[06:24] <dholbach> I don't think that running lintian on your package will give you 100% policy compliance safety
[06:24] <dholbach> but it's a very good indicator for things that are wrong in your package
[06:33]  * persia studiously ignores contentless pings
[06:35] <slytherin> persia: ok, here is the one with content. Most of the packages needed for maven 2 support seem to be uploaded in Debian. But since we are post DIF I have to file sync bugs after verifying that Debian sources built in jaunty pbuilder. I was wondering if I should bug one particular archive admin for all the syncs.
[06:36] <persia> I generally don't bug the archive-admins about syncs, except where there is some priority that something needs to be done soonest.
[06:37] <persia> If there's a specific order in which they should be synced to build cleanly, then it's worth putting that on the wiki, and adding a note to each of the sync bugs pointing to that doc, so that they don't get pulled out-of-order, although Soyuz *should* autodetect this, and build them in the right order.
[06:37] <persia> If there is a priority, bug the archive-admin of the day (days posted in the archive administration section of the wiki)
[06:38] <slytherin> persia: I usually don't file sync bugs without verifying that it builds. As of now I am waiting for sync on one package after which I can evaluate it's reverse-build-depends.
[06:40] <persia> Then that package counts as priority, as your work is blocked.  Try something like "could an archive admin please prioritise the sync of foo (bug #nnnnnn) from {unstable, experimental}: it's blocking processing of a host of other syncs for maven support" in #ubuntu-devel.  I'd recommend asking either early in your morning, or in your evening, as that's when you'd most likely find an archive admin (I don't think there are any between UTC+1 and U
[06:40] <persia> TC+11)
[06:41] <slytherin> persia: I will ask in evening then.
[06:53] <tmurder> should i be building static libraries too, if i have the option? default is no.
[06:55] <didrocks> morning everyone o/
[07:03] <persia> tmurder, I'd recommend not doing it unless there is an overwhelming reason to do so: static libraries don't tend to automatically get security updates, which can mean a *lot* of recompiling, depending on the library.
[07:06] <tmurder> ok, thanks
[07:18] <stefanlsd> why doesnt mom or dad let u know when u have merges...  do you think some people don't even know they have merges to do?
[07:20] <stefanlsd> james_w: can i grab some of your merges?
[07:29] <persia> stefanlsd, Because merges weren't owned when MoM was invented, and DaD mirrored MoM's behaviour.  There's still a school of thought that says merges shouldn't be owned, but there's another school of thought that those who work on a package know it best.  I think we're still reaching for the right balance.
[07:32] <stefanlsd> persia: yeah. im never sure if someone minds if you just take their merge and do it, or if they know something that would save a ton a trouble and its best for them to do it.  from the schedule tho, merges should of been completed 25th dec. (and debian in import freeze, so not too much will change) and there's still about 100 outstanding...
[07:33] <persia> stefanlsd, I'd personally recommend evaluating the Debian changes, and the history.
[07:34] <stefanlsd> would be nice if someone could just indicate, as a preference, like... feel free to grab, or i would prefer to do it myself kinda thing
[07:34] <persia> If the package is primarily uploaded by a single person, and the changes are complex or interesting, then it makes much more sense to ask them.
[07:34] <persia> If the package has small or standard changes, and a variety of uploaders, then it's probably safe to do.
[07:35] <persia> In either case, the specific changes in Debian should be the overriding concern when deciding which is correct: it's not worth doing a merge unless there's some specific benefit to Ubuntu from the merge, at this point.
[07:35] <pwnguin> yay, new desmume!
[07:36] <persia> So, if the maintainer changed, or there was a minor update, don't bother.  If it's a critical bugfix, it's worth merging, if we don't already have the fix in Ubuntu.
[07:38] <stefanlsd> persia: ok. new version we always want to merge thou.. i agree, small changes with a debian revision that dont fix anything, are prob not required.
[07:38] <pwnguin> anyone remember what the name of that ubuntu game oriented project was?
[07:40] <pwnguin> xeiso
[07:44] <persia> stefanlsd, Actually, no.  We specifically *don't* always want to merge a new version after DIF.
[07:44] <persia> We want to review the impact of the new version on the release we are building, and merge it iff it will improve the coming release.
[07:45] <persia> Often when there is just a Debian revision bump, it's far more important to do the merge, as these are frequently bugfixes.
[07:46] <stefanlsd> persia: mmm. ok.  makes sense also.  i guess also app minor revisions.  yeah, we dont want major revisions and api/abi changes to break stuff
[07:46] <persia> Except when we do :)
[07:47] <persia> For instance, if a new version of a library comes out, with an ABI change, and some API additions (but no removals or context changes), and upstream declared this was the version to support, and that they planned to offer several years of bugfix support, we'd want that over whatever we had.
[07:47] <persia> (Assuming we trust upstream, which we usually do)
[07:48] <persia> Or something where there's a central set of servers (e.g. network games), where we want to support the current server version protocol, we'd upgrade to the newer version.
[07:49] <stefanlsd> persia: kk. thanks. makes total sense.   so actually saying 100 merges remaining doesnt really matter.  dad is nice when u can make a comment. like some say, not neccessary.
[07:49] <persia> Well, are the "outstanding" merges or "new" merges?
[07:50] <persia> If we've never merged yet in the jaunty cycle, they deserve a good hard look.  If we've merged before, it's just a quicker look to try to determine the state.
[07:50] <persia> Sometimes I would like comments, just so someone could say "I reviewed 1.2.3-4: no benefit" or "I'll do this on the weekend: I'm in touch with upstream on a couple outstanding issues".
[07:52] <stefanlsd> yeah. i've looked at a couple of them to find existing merge or sync bugs (although its my fault by not checking, would still be nice if we had one place with the info...)
[07:55] <persia> The launchpad crew is looking at having syncs from registered sync sources be fully supported, which persumably would be expressed in a way that MoM could then parse at some point in the future.
[07:55] <persia> There was also some talk at UDS about attempting to parse patches submitted to launchpad for application against bzr trees for packages, and present that in a UI somehow, which might catch the merge bugs.
[07:56] <persia> Given that, it's probably not worth trying to create a system now, when there's the possibility of doing it in an integrated fashion later.  MInd you, "later" is poorly defined.
[08:00] <stefanlsd> yeah. its pretty good, but i guess it takes time to improve process and systems
[08:01] <persia> RIght.  Until then, we relay on clear thought and a common goal, which mostly works :)
[08:02] <stefanlsd> with communication. which helps :)
[08:10] <stefanlsd> where can i see history of a package and why its not in jaunty.  looking for libmagick9-dev  which is in intrepid and in sid... i see what its been replaced by in debian experimental, just wanted to know who makes the call in jaunty and where i would see it?
[08:12] <persia> stefanlsd, You'd need to translate the binary package name into a source package name (in this case imagemagick).  Then look at the binary packages produced by the current imagemagick.
[08:12] <persia> The set of included binary package names is determined by those who adjust each source package (developers generally, but typically the relevant Debian maintainer)
[08:13] <persia> The set of included source packages is determined by the archive-admins, based on input (as bugs) by developers.
[08:19] <pmjdebruijn> .win 13
[08:19] <pmjdebruijn> sorry
[10:20] <slytherin> dholbach: my bad that I didn't get time to reply to your mails earlier. :-( I will reply to both mails tonight.
[10:20] <dholbach> slytherin: take your time :)
[10:29] <stefanlsd> NCommander: you around?
[10:30] <james_w> stefanlsd: you are welcome to them
[10:30] <james_w> stefanlsd: feel free to subscribe me directly for sponsorship
[10:30] <stefanlsd> james_w: kk. thanks :)
[10:30] <stefanlsd> james_w: trying to look at the FTBS for imview...
[10:31] <james_w> take a look at the bugs on the imagemagick package, and follow the link on the top one to Debian
[10:33] <Laney> morning folks
[10:34] <stefanlsd> does anyone know if i can put something running into a screen session?
[10:36] <jpds> morning Laney.
[10:40] <stefanlsd> james_w: do u have a link to what you are referring to - i only got http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=470777
[10:41] <james_w> bug 301618
[10:41] <james_w> the Debian counterpart to that
[10:45] <AdamDH> hi, I have built a couple of packages that require one common package, if I try and build the package that is dependant on the common package I get  pbuilder-satisfydepends-dummy depends on msp430-binutils; however:
[10:45] <AdamDH>   Package msp430-binutils is not installed.
[10:45] <AdamDH>  even tho its installed
[10:45] <AdamDH> any ideas?
[10:50] <directhex> it's available inside the pbuilder?
[11:36] <persia> AdamDH, Can your pbuilder see a repo that provides msp430-binutils?
[11:41] <DktrKranz> is anybody able to display https://roundup.mplayerhq.hu/roundup/ffmpeg/issue711 ?
[11:42] <slytherin> just out of curiosity ... has anyone successfully played a blue ray drive in Ubuntu?
[11:42] <StevenK> % telnet roundup.mplayerhq.hu 80
[11:42] <StevenK> Trying 130.192.86.145...
[11:42] <StevenK> DktrKranz: ^
[11:42] <StevenK> (It doesn't answer)
[11:43] <DktrKranz> so, it's not just me
[11:43] <StevenK> Nope
[11:43] <StevenK> Wait, just noticed the https, but it doesn't answer on 443 either
[11:44] <DktrKranz> I'll try later, thanks ;)
[11:51] <AdamDH> no non of my packages are in a repo
[11:52] <persia> AdamDH, You could force-install it into the pbuilder with --save-after-login, but you might do better to use a PPA for that one package, or apt-ftparchive for a local package directory.
[11:59] <maxb> I like to turn /var/cache/pbuilder/result into a repository, such that pbuilder can see packages that it build in previous runs
[11:59] <DktrKranz> http://hattory.no-ip.info/jaunty/result/mlt_0.3.4-0ubuntu2/mlt_0.3.4-0ubuntu2.buildlog       is pbuilder going crazy?
[12:00] <persia> DktrKranz, Do you get debian/control from dpkg-source -x ?
[12:01] <DktrKranz> yes, the interesting part is everything goes fine on i386
[12:01] <DktrKranz> this happens on my amd64 buildserver
[12:02] <AdamDH> i am on an amd64 system any way I can force it to make an x86 binary?
[12:02] <directhex> use an i386 pbuilder
[12:06] <persia> DktrKranz, Very odd.  Especially odd that it appears to build a dependencies line, and then claim it can't find debian/control.
[12:07] <persia> This can be repeated?  Are you low on temporary space for the pbuilder run?
[12:07] <DktrKranz> Filesystem            Size  Used Avail Use% Mounted on
[12:07] <DktrKranz> /dev/sda5              44G  2,7G   39G   7% /
[12:08] <DktrKranz> it's an intrepid box
[12:08] <stefanlsd> what are the consequences of having a build-dep which isnt really required?
[12:08] <persia> Curiouser and Curiouser.  Does sbuild also break there?
[12:09] <DktrKranz> no sbuild installed
[12:09] <persia> (and no, sbuild/schroot *doesn't* need LVM, it's just better that way)
[12:09] <persia> Is the source package somewhere easy to grab?
[12:09] <persia> (unsigned, please)
[12:10] <persia> Or rather, I like the source signed, but not .changes :)
[12:10] <hyperair> persia: why not
[12:10] <DktrKranz> persia, https://launchpad.net/ubuntu/+source/mlt/0.3.4-0ubuntu2 :)
[12:10] <persia> hyperair, Because a signed .changes file for something that shouldn't be uploaded is a dangerous thing to exist.
[12:10] <persia> DktrKranz, Ah, repo.  Grabbing.
[12:11] <DktrKranz> just uploaded, so you need pull-lp-source
[12:11] <persia> Not published yet?  I thought it didn't work.
[12:11] <hyperair> persia: what dyou mean something that shouldn't be uploaded?
[12:11] <maxb> Gah. I wrote my own script not realizing pull-lp-source existed :-/
[12:12] <DktrKranz> maxb, heh :)
[12:12] <persia> hyperair, Say I'm working on a package, and there's a bug, and I haven't fixed it yet.  I don7t want that uploaded until it's fixed, but I might want to share it with others so they can help debug.
[12:12] <maxb> though mine pulls from debian too
[12:12] <persia> DktrKranz, The amd64 buildd is already building under sbuild: no point me restarting.
[12:12] <hyperair> aah i see
[12:13] <hyperair> i'd just share the diff.gz file
[12:13] <nhandler> maxb: There is a pull-debian-source script too ;)
[12:13] <persia> hyperair, Well, I like signed .dsc just because I'm lazy and like dget :)
[12:13] <hyperair> heh
[12:13] <hyperair> i se
[12:13] <persia> But yes, the diff.gz is the only useful part.  One of these days, someone ought write the script that converts from diff.gz to full package.
[12:14]  * DktrKranz tries to launch pdebuild to see if things change
[12:14] <persia> Grumble.  crested log shows it purging everything, but build record says the log isn't available yet.
[12:14] <hyperair> nhandler: http://revu.ubuntuwire.com/details.py?package=codelite
[12:14] <hyperair> persia: you can't generate a full package without the orig.tar.gz
[12:15] <hyperair> and it's not scriptable either
[12:15] <persia> hyperair, Actually, you often can.  The diff.gz just either needs an accurate watch file, or a working get-orig-source rule.
[12:15] <nhandler> hyperair: I know, I'll get to codelite soon. I've just been busy
[12:15] <hyperair> nhandler: okay then.
[12:15] <persia> and, yes, it is scriptable.  I've a (mostly broken) script that does it, that needs some work, and productionising.
[12:15] <hyperair> hmm
[12:15] <hyperair> i see
[12:16] <hyperair> with the debian/watch file eh
[12:16] <persia> Or debian/rules get-orig-source
[12:16] <hyperair> i see
[12:16] <persia> My script tried get-orig-source first, and uscan if that failed.
[12:16] <hyperair> but it won't get the exact version
[12:16] <hyperair> and for repackaged sources, it won't work
[12:16] <persia> It will for a correctly written get-orig-source that does reproducible repackaging checksums.
[12:17] <hyperair> eh?
[12:17] <persia> And yes, it won't get the original source, it gets the current best source.  Personally, I wanted get-orig-source to get the correct source for the package, rather than the latest upstream, but policy optimised for developers rather than users (as only makes sense).
[12:17] <hyperair> i can't remember what get-orig-source does again
[12:17] <persia> It gets the latest upstream source, repackages as necessary, and provides orig.tar.gz.
[12:18] <hyperair> i see
[12:20] <persia> So, theoretically, if one added X-orig-md5sum: to the Source stanza in debian/control, one ought to be able to fully trustfully automate collection of original sources, which ought reduce all this fuss about mismatched origs, but that's a ways off, at least.
[12:21] <persia> DktrKranz, It's your pbuilder.  Works fine on the buildds.
[12:21] <DktrKranz> I see
[12:21] <persia> https://launchpad.net/ubuntu/+source/mlt/0.3.4-0ubuntu2/+build/828141
[12:23] <didrocks> is it possible to run some daily cron job by a non root user like www-data (appart from writing this in the script)? run-parts runs as root from /etc/crontab and run every scripts in /etc/cron.daily/. I want to make that in a package, so not edit one user's crontab
[12:25] <persia> didrocks, Why not create a system users (like www-data), and then install it in that user's crontab?
[12:26] <didrocks> persia: system user has to be declared with fixed uid from debian policy, right? (I thought I read something on that...)
[12:27] <persia> Well, there's a couple classes of system user.
[12:28] <didrocks> do you have a link on that? But I think you go the point :)
[12:30] <maxb> didrocks: What you want is to put a file into /etc/cron.d/
[12:30] <persia> didrocks, Policy 9.2.2: UID 0-99 is statically assigned, 100-999 is dynamically allocated at package installation time (adduser --system)
[12:31] <didrocks> maxb: and that file executed by another user than root
[12:31] <didrocks> persia: thanks a lot :)
[12:31] <DktrKranz> persia, interestingly, it seems only jaunty pbuilder is affected, intrepid builds are fine...
[12:31] <didrocks> persia: so, I think, I will go in this way. Thanks :)
[12:31] <persia> DktrKranz, methinks you've found a bug :)
[12:32] <DktrKranz> really
[12:33] <maxb> didrocks: If you look at one of the existing files in /etc/cron.d/, you will see that you specify a username in it
[12:35] <didrocks> maxb: I use the default run-parts and drop files in */cron.{daily,weekly...}
[12:35] <didrocks> maxb: that was part of my issue but I will use a system user for that
[12:35] <maxb> Are you sure you need a user?
[12:36] <maxb> Even if you do create a special user, I think it is wrong to install crontabs for non-human users
[12:36] <maxb> that's what /etc/ is for
[12:37] <didrocks> maxb: I try to catch up some additional services for transmission-daemon and want to run it as a transmission user
[12:38] <maxb> Then you do want to create a user, but any cron stuff should go in /etc/, not a crontab(1)-installed one
[12:39] <persia> maxb, so `su ${transmission-user} -c ${command}` would be your advice ?
[12:40] <maxb> No
[12:40] <didrocks> persia: it was my first idea
[12:40] <maxb> Go look in /etc/cron.d/ on your system
[12:40] <persia> Oh, those file names are usernames?  Nifty.
[12:40] <maxb> No, the file names are not usernames
[12:41] <persia> No, package names. but one can still fix them.
[12:41] <persia> Yeah, that's lots better.
[12:41] <maxb> the username goes in the cron-line - the files are fragments that get processed like /etc/crontab does
[12:41] <didrocks> ok, I thought they were no username in thoses files, like the one in cron.{daily...}, but there are :)
[12:41] <didrocks> yes I see, there are regular crontab files :)
[12:41] <didrocks> thanks both of you!
[12:42] <persia> maxb deserves all the thanks: I just recommended the wrong solution :)
[12:43] <didrocks> persia: yes but you give so many good advice that I can't blame you :)
[12:45] <didrocks> maxb: next time, I will read more carefully man cron :)
[13:53] <mok0> pwd
[13:53] <mok0> oops
[13:55] <pochu> /home/morten/.irclogs/Freenode/
[13:55] <mok0> pochu: cute :-)
[14:01] <soc> hi
[14:01] <soc> can somone help me?
[14:01] <soc> i built a source package, but i get the error make[1]: *** No rule to make target `clean'.
[14:01] <soc> i use cdbs and thought the standard tartgets would be handled ...
[14:03] <mok0> soc: cdbs assumes there's a top level Makefile that implements the target "clean"
[14:04] <mok0> soc: That target should return the directory to the same state as it is when the tar file is unpacked
[14:04] <mok0> soc: i.e. remove all *.o files etc
[14:08] <soc> there are no .o files
[14:08] <soc> there are just some fonts!
[14:08] <soc> nothing to compile, nothing to configure, nothing to clean up
[14:09] <mok0> soc: then make an empty clean target
[14:18] <soc> where?
[14:18] <mok0> soc: in Makefile
[14:19] <soc> just "clean"?
[14:19] <soc> or "clean/<packagename>"
[14:19] <mok0> soc: don't you know about make?
[14:19] <soc> no
[14:20] <mok0> soc: ah
[14:20] <mok0> just try putting "clean:" on a line by itself in debian/rules
[14:21] <mok0> soc: an empty line after that
[14:21] <soc> ok thanks
[14:21] <soc> debian/rules:9: *** target file `clean' has both : and :: entries.  Stop.
[14:21] <soc> dpkg-buildpackage: failure: fakeroot debian/rules clean gave error exit status 2
[14:22] <mok0> soc:  change it to clean:: then
[14:22] <soc> already tried
[14:22] <mok0> soc: meh
[14:22] <soc> make[1]: *** No rule to make target `clean'.
[14:23] <soc> http://pastebin.com/m1374e29e
[14:23] <soc> thios is my rules file currently
[14:24] <soc> btw, i want to do a native package, i heard that i have to look at the file name of my src archive, is that true?
[14:24] <mok0> soc: you shouldn't make a native package
[14:25] <soc> mok0: i can't figure out how to do a non-native one ...
[14:25] <mok0> soc: you have to
[14:25] <soc> the watch file doesn't really work with that http://android.git.kernel.org/?p=platform/frameworks/base.git;a=tree;f=data/fonts
[14:25] <mok0> soc: it will be made automatically if you have the orig.tar.gz file
[14:25] <soc> even if i had figured out that, i'm still missing the right version
[14:26] <soc> i just made an archive myself with that .orig.tar.gz
[14:26] <soc> because the version of the fonts is only in the fonts intself
[14:26] <mok0> soc: it needs to have the form xxxxx_1.0.orig.tar.gz
[14:27] <mok0> using 1.0 as version
[14:27] <mok0> change that to whatever
[14:27] <soc> i made one following that scheme
[14:27] <soc> but my "original" tarball isn't really original, because i made it myself
[14:27] <mok0> soc: you need to specify version-release in debian/changlog
[14:27] <soc> it isn't available for download somewhere
[14:28] <soc> how can i do that?
[14:28] <mok0> soc: you are packaging your own stuff?
[14:28] <soc> i'm trying to learn it
[14:28] <soc> i'm uploading it first to my ppa, but would be happy if i cloud get it into ubuntu
[14:28] <mok0> soc: you mean how to make a tarball?
[14:29] <soc> mok0: no, i just wonder what "original" tarball means
[14:29] <soc> because there is no usable file i can download from upstream
[14:29] <mok0> soc: it's usually a copy of the upstream tarball
[14:30] <mok0> soc: renamed according to the scheme above
[14:30] <soc> that won't work
[14:30] <soc> the version info is only inside the fonts itself
[14:30] <mok0> soc: then something else is wrong
[14:30] <mok0> soc: please explain
[14:31] <soc> the fonts are version 1.00 build  112
[14:31] <soc> and that's only written inside the font file
[14:31] <mok0> soc: can you make a tarball of that directory (without the debian/ one)?
[14:31] <soc> which directory?
[14:32] <mok0> soc: where you have the font files
[14:32] <soc> http://android.git.kernel.org/?p=platform/frameworks/base.git;a=tree;f=data/fonts ==> Click on "snapshot"
[14:32] <soc> that gets me a archive with some random git revision at the end
[14:33] <soc> even if i could figure it out how to clean up that archive, i still can't get the version of the fonts ...
[14:33] <mok0> soc: (my system disk is about to die, so I can't really do much right now)
[14:34] <mok0> soc: so rename the tarball you get from that android.git. place
[14:34] <mok0> for example android-fonts_1.0build112.orig.tar.gz
[14:35] <soc> i can't do that!
[14:35] <soc> i don't know the version
[14:35] <mok0> soc: you just said it was 1.0 build 112
[14:35] <soc> that is the one currently, but i thought the watch file should help people to update an existing package
[14:36] <mok0> soc: it should, but never mind the watch file right now
[14:36] <soc> of course i could hardcode 1.0 build 112, but that wouldn't make sense, would it?
[14:36] <soc> ok, so no wtach file
[14:36] <directhex> GAH
[14:36] <directhex> quilt hates my guts
[14:36] <mok0> soc: yes it would because thats the version inside it
[14:36] <soc> just that get-orig-source atm?
[14:36] <mok0> soc: you can add that later
[14:36] <soc> mok0: but the version can change very day
[14:37] <mok0> soc: are you going to update the package every day?
[14:37] <soc> no
[14:37] <mok0> soc: First, you have to learn how to build a package
[14:38] <soc> but i can't promise that people will get the same file i used for the package and i can't even read out the version
[14:38] <soc> mok0: i'm just fixing the last things ...
[14:38] <mok0> soc: right. But as I said, the watch file is not important right now
[14:39] <soc> all the other files are ok
[14:39] <mok0> soc: huh? You can't build the source package
[14:39] <soc> changelog, control, copyright, install, rules
[14:39] <mok0> soc: remove the clean:: target from rules, and also remove the include .... makefile.mk line
[14:39] <soc> ok
[14:40] <mok0> that's line 3
[14:40] <soc> mhh cool
[14:40] <soc> now it works
[14:40] <soc> i guess i'll upload it  now ...
[14:41] <mok0> soc: does the .deb files contain what you expect?
[14:41] <soc> i didn't build an deb file yet
[14:41] <soc> just did  debuild -S -sa
[14:41] <mok0> soc: do you have a pbuilder environment?
[14:43] <soc> i tried not to compile anything on my machine, because most of the time these tools won't work cleanly and i don't have the time to clean up the whole mess
[14:43] <mok0> soc: that's why we all use pbuilder
[14:43] <soc> and my internet connection is slow
[14:44] <mok0> soc: pbuilder stashes the deb files it downloads away, so you only need to download once
[14:44] <soc> and afaiu pbuilder builds a new chroot and therefore downloads all the packages again with things i already have installed ...
[14:44] <soc> does it use the files from /var/cache/apt?
[14:44] <mok0> soc: a minimum set
[14:44] <mok0> soc: yes
[14:44] <soc> ok, then let's try
[14:44] <mok0> soc: if you have the CD you could copy all the deb files there
[14:45] <mok0> soc: but the compiler etc is not on the CD though
[14:45] <persia> Does it do that by default now?  One used to have to specifically bind that directory manually.
[14:45] <persia> Also, compiler is on the CD, in the pool directory.
[14:45] <mok0> persia: Hmm, not sure
[14:45] <mok0> persia: ah I stand corrected
[14:45] <soc> "Default mirror site:"??
[14:46] <soc> this is a question i get when installing pbuilder
[14:46] <soc> http://archive.ubuntu.com/ubuntu?
[14:46] <mok0> soc: you could use ubuntu.com but it's slow
[14:46] <soc> ah k
[14:46] <mok0> soc: preferrably a mirror near you
[14:47] <soc> http://de.archive.ubuntu.com/ubuntu/
[14:47] <soc> then?
[14:47] <soc> (germany)
[14:47] <mok0> ! mirror
[14:47] <soc> ok, pbuildinstalled now
[14:48] <mok0>   pbuilder --build [options] .dsc-file
[14:48] <persia> I'd recommend using two mirrors in your sources.list: the local mirror first, and archive second.  apt will pull from the local mirror if it's there, and from archive if it's been updated, but not mirrored yet.
[14:49] <persia> Given the mirror refresh cycles, this may get you newly uploaded stuff as much as an hour earlier.
[14:50] <soc> mok0: i ran  "sudo pbuilder create --debootstrapopts --variant=buildd" before that
[14:50] <mok0> soc: good
[14:50] <soc> but somewhere it said "Distribution is jaunty."
[14:51] <maxb> debootstrap unfortunately doesn't use /var/cache/apt, it just redownloads. I wrote myself a wrapper which bindmounts /var/cache/apt/archives into the chroot being built to save myself download time.
[14:51] <soc> and i don't want this
[14:51] <mok0> soc: I assume you are reading the wiki
[14:51] <soc> i don't want to download all the packages again
[14:51] <soc> yes
[14:51] <bddebian> Heya gang
[14:51] <mok0> bddebian: yo, Dude!
[14:51] <bddebian> Hi mok0
[14:52] <mok0> maxb: huh? I though pbuilder did that by default
[14:53] <soc> mok0: mhhh in /usr/share/pbuilder/pbuilderrc:
[14:53] <maxb> Apparently not, for me.
[14:53] <soc> APTCACHE="/var/cache/pbuilder/aptcache/"
[14:54] <soc> could i just point to my normal cache directory?
[14:54] <soc> /var/cache/apt?
[14:54] <mok0> soc: sure
[14:54] <soc> ah ok
[14:54] <maxb> I don't think that's enough to make debootstrap use it too, though
[14:55] <persia> If you run one release (e.g. hardy) and develop another (e.g. jaunty), keeping them separate can be useful.
[14:55] <mok0> maxb: oh that's probably true
[14:55] <mok0> persia: ... but does it matter? I don't think it does
[14:56] <mok0> persia: (I agree it's messy)
[14:56]  * mok0 uses sbuild on an lvm snapshot
[14:57] <persia> mok0, Well, depends.  I'd probably want autoclean run regularly on the pbuilder apt-cache, but not on my normal system (as there are times one wants to downgrade, despite the pain)
[14:57]  * persia uses sbuild, and has ethernet to a mirror, so this is all theoretical
[14:57] <mok0> persia: right, of course
[14:58] <soc> mhhh ok, no it says validating or retrieving
[14:58] <soc> but it's quite fast
[14:58] <mok0> soc: good
[14:58] <soc> but my /var/cache/apt directory doesn't change
[14:59] <soc> even if the package isn't available there ...
[14:59] <soc> i thought it would download the required packages ..
[14:59] <mok0> soc: Like maxb said, it's only pbuilder using the cache, not debootstrap
[14:59] <soc> ah k
[15:00] <mok0> soc: when you use pbuilder, it figures out what extra packages it needs and installs them
[15:00] <mok0> soc: downloading if it hast o
[15:00] <soc> but pbuilder and apt-get have compatible directory structures?
[15:00] <soc> or will it mess up things if i use the same dir for both?
[15:00] <mok0> soc: not if you build for the same distro that's on your rig
[15:01] <soc> ah k
[15:01] <mok0> soc: usually people have different dirs for different distros
[15:02] <mok0> soc: if you install ubuntu-dev-tools, theres a wrapper called pbuilder-dist that takes care of a lot of the nitty-gritty
[15:02] <mok0> of working with different distros
[15:17] <soc> mok0: do i need a debian/install file?
[15:18] <mok0> soc: most likely
[15:18] <soc> what has to be in there?
[15:18] <mok0> soc: file names that you want to include in the package relative to topdir
[15:19] <soc> addtional files?
[15:19] <mok0> soc: and in column 2 the directory you want them to go into
[15:19] <mok0> soc: eg. "font /usr/lib/fonts"
[15:19] <soc> *.ttf		/usr/share/fonts/truetype/ttf-droid/
[15:20] <mok0> soc: right
[15:21] <persia> Well, except that one omits the initial '/' from the list.
[15:21] <mok0> soc: I recommend you call the install file <packagename>.install
[15:21] <directhex> how would i perform an action in a debian/rules on the basis of whether a file exists or not?
[15:22] <soc> persia: which initial "/"?
[15:22] <mok0> directhex: there's probably some gnu make macro that can test for the existance of a file
[15:22] <persia> soc: you want a line like "`.ttf    usr/share/fonts/truetype/ttf-droid"
[15:22] <soc> ah ok
[15:27] <soc> ok, it worked ...
[15:27] <soc> but where is my *.deb now?
[15:31]  * directhex abuses 'rename' instead
[15:31] <mok0> soc, in ..
[15:47] <soc> where?
[15:49] <persia> Isn't it something like /var/cache/pbuilder/result/ _
[15:49] <soc> ahh thx!
[15:49] <soc> cooöl
[15:49] <soc> package looks good
[15:51] <soc> could someone review that package?
[15:53] <mok0> !REVU |soc
[15:53] <hanska> \o
[15:53] <jpds> soc: Only source packages are REVUed, but have a sucessfully built binary package is a great start to knowing that it works.
[15:53] <jpds> hanska: hello.
[15:56] <soc> mok0, jpds: do i have to upload that thing again to revu, or can i move it from my ppa to revu?
[15:56] <hanska> hello jpds
[15:56] <hanska> soc: still working on ttf-droid? ;)
[15:57] <jpds> soc: Upload it to REVU.
[15:58] <soc> hanska: i'm finished now
[15:58] <soc> except for the small things ...
[15:58] <soc> https://bugs.launchpad.net/ubuntu/+source/kubuntu-meta/+bug/311415
[15:58] <RainCT> soc: you can copy it
[15:58] <soc> should i use that bug, or should i create another one?
[15:58] <Riddell> DktrKranz: bug 303245 is probably a legit target for poking archive admins on irc, most of the admins forget about processing backports New queues
[15:58] <RainCT> soc: http://revu.ubuntuwire.com/import.py
[15:59] <Riddell> DktrKranz: (I'm processing them now)
[16:00] <jpds> RainCT: Hmm, didn't know that.
[16:01] <RainCT> jpds: yeh, that's new (well, actually it's old, but it hasn't been publicized yet :P)
[16:01] <soc> RainCT: thanks
[16:01] <soc> mhh
[16:02] <soc> RainCT: the package doesn't appear on that import.py ...
[16:02] <soc> mhh now it appeared on launchpad, but not in revu
[16:03] <Riddell> soc: did you upload to ubuntu instead of revu?
[16:03] <RainCT> soc: is it already built on the PPA?
[16:03] <DktrKranz> Riddell, thanks ;)
[16:03] <RainCT> soc: and did you upload for jaunty?
[16:05] <soc> Riddell: i uploaded it to my ppa
[16:05] <soc> RainCT: it is built for intrepid on my ppa
[16:05] <soc> can i just use the interface to build it for jaunty?
[16:05] <soc> or do i have to reupload the modified changelog?
[16:06] <RainCT> I'm not sure, never tried that. If you do, please tell me if it works
[16:06] <maxb> reupload the modified changelog
[16:06] <soc> The following source cannot be copied: ttf-droid 1.00~b112-2 in intrepid (same version already has published binaries in the destination archive)
[16:06] <soc> no it doesn't work ...
[16:07] <soc> it's probabyl a bug
[16:07] <RainCT> soc: ok, then change to jaunty and upload to REVU
[16:07] <soc> mhh ok, i copied that thing
[16:07] <soc> should probably work
[16:08] <soc> status pending ...
[16:11] <khashayar> If there's a new upstream release of an application, but the package is neither in debian nor in ubuntu, what's the next step? If I build a package, should it go to revu?
[16:12] <persia> No.
[16:12] <jpds> khashayar: New upstream release for a package not in Debian/Ubuntu?
[16:12] <khashayar> persia: Somehow, I suspected that :-)
[16:12] <persia> First, file a "Please upgrade" bug in the BTS.  See if there's any response.  Next update the package, and attach a diff.gz to the bug, and subscribe the sponsors.
[16:12] <khashayar> Yes,
[16:13] <khashayar> Thanks. I'll go about that.
[16:13] <directhex> i'm confused how "New upstream release for a package not in Debian/Ubuntu?" is possible
[16:13] <persia> Oh, sorry.  Package *not* in Debian or Ubutu does go to REVU.
[16:13]  * persia missed the "not"
[16:13] <hanska> persia: or, filing a RFP in DBTS :)
[16:13] <DktrKranz> directhex, there are several packages to be transitioned against new gnome-sharp2, is a rebuild sufficient or are there adjustments to make?
[16:13] <directhex> if it's not in any dist, then it's irrelevant if there's a new upstream - it's a new package, full stop
[16:13] <khashayar> The package I'm thinking of is audacity 1.3.6. 1.3.5 is in debian + ubuntu.
[16:14] <persia> hanska, For people just starting in Ubuntu, I generally recommend REVU pre-ITP.  Many RFPs just sit there for a while.
[16:14] <directhex> khashayar, then that's not "not in Debian/Ubuntu"
[16:14] <hanska> persia: ACK :)
[16:14] <khashayar> directhex: yeah, sorry, I'm confusing the terms here.
[16:14] <directhex> DktrKranz, erm, oh god..... wasn't this some bodged ABI bump or something? slomo knows more about it than me
[16:15] <persia> khashayar, In that case, ask in #debian-multimedia on OFTC about the upgrade plans.  If they don't mind, just do the upgrade.
[16:15] <persia> Publish your packaging so they can put it into VCS, and push the diff.gz to a bug report.
[16:15] <DktrKranz> directhex, yes. There has been a SONAME bump.
[16:16] <hanska> DktrKranz: to', un altro italiano :)
[16:16] <directhex> DktrKranz, i don't imagine anything other than a rebuild is needed, unless there's a serious problem with the gnome# package. give it a punt in a pbuilder
[16:16] <DktrKranz> hanska, indeed! ;)
[16:16] <khashayar> persia: thanks for the info. I'm a bit confused about all the shorts (VCS, ITP, OFTC). I'll get back here with questions if I get stuck.
[16:17] <directhex> hanska, you remember anything about gnome#? i think slomo had something to do with updating it, but there was some kinda issue
[16:17]  * khashayar is off to google
[16:17] <persia> khashayar, OFTC is an IRC network.  VCS is a version control system.  ITP is a special class of bug in Debian.
[16:17] <soc> mhhh
[16:17] <soc> something is not working in my ppa i believe
[16:17] <hanska> directhex: yes, I had nothing to do with that beast either :/
[16:17] <DktrKranz> directhex, I'll have a look with sebner, he likes this kind of stuff ;)
[16:17] <khashayar> persia: thanks :-)
[16:17] <hanska> DktrKranz: lol :)
[16:17] <directhex> hanska, you remember the specifics? my memory is terrible
[16:17] <soc> the status of my ttf-droid package is still pending, although it was only copied, not built ...
[16:17] <jpds> khashayar: OFTC is the IRC network where the debian people hang out: http://www.oftc.net/
[16:17] <hanska> directhex: we're two, then.
[16:17] <directhex> DktrKranz, yeah, sebner's a clever chap. poke him
[16:18] <directhex> DktrKranz, my main issue is the oracle of debian mononess is MIA
[16:18] <hanska> yeah, anyone seen meebey? :P
[16:18] <hanska> directhex: taken by aliens, I told you.
[16:18] <DktrKranz> he uploaded a NEW package for sebner some days ago
[16:18] <DktrKranz> he's not totally MIA ;)
[16:19] <directhex> DktrKranz, how many days, though? :o
[16:19] <soc> RainCT: is it normal, that it takes more time to cpoy a apckage from intrepid to jaunty in the same ppa, then to build it on the server?
[16:19] <DktrKranz> directhex, less than one week ago
[16:19] <RainCT> soc: I don't know, sorry
[16:20] <DktrKranz> directhex, http://ftp-master.debian.org/new/themonospot_0.7.1.1-1.html    <- 4 days ago
[16:21] <directhex> haven't seen him since then!
[16:21] <directhex> need to pin him down for about 10 things
[16:21] <directhex> meybe he's hiding frmo me ¬_¬
[16:21] <hanska> directhex: nah, hiding from me too
[16:21] <hanska> directhex: probably he got 5mins and did the upload
[16:23] <directhex> hanska, but not moon! :O
[16:24] <hanska> directhex: probably he wants to beat you on something :/
[16:24] <directhex> MOON!
[16:25] <soc> https://help.launchpad.net/Packaging/PPA "If you only copy the source, the corresponding build records are created in the destination PPA immediately. "
[16:25] <soc> i don't understand it ..
[16:28]  * rexbron is still lacking the revu luv: http://revu.ubuntuwire.com/details.py?package=libffado
[16:32] <soc> lol ...
[16:34] <soc> i don't get it: the package for jaunty in my ppa doesn't get finished but hangs with "pending" and the ppa of the fonts team, where i rebuild my packages for jaunty doesn't even exist in revu
[16:36] <oojah> soc: From the PPA page: "However, it can take up to twenty minutes for the files to actually appear in your archive."
[16:37] <soc> does status "pending" mean that?
[16:38] <ScottK> Pending means not published yet.
[16:39] <soc> oojah: "If you only copy the source, the corresponding build records are created in the destination PPA immediately." this is the next sentence
[16:40] <oojah> soc: My experience is that it can take a while to go from pending->published, even when just copying binaries.
[16:40] <soc> if i upload the source, it gets build and published within minutes, but if i just want to copy one thing from intrepid to jaunty, it takes ages ... wrong world :-/
[16:42] <soc> should i mabe just do a new revsion with jaunty in the chnagelog and upload it?
[16:43] <persia> Better to ask in #launchpad to see if someone can track it down first.
[16:44] <oojah> soc: You can do that but you'll need to change the version number as well.
[16:44] <soc> can i do something like 1.00~b112-2~jaunty and 1.00~b112-2~intrepid?
[16:46] <oojah> Yes
[16:46] <soc> "Connection failed, aborting. Check your network (111, 'Connection refused')"
[16:46] <soc> lol ... somehow everything is failing now
[16:46] <soc> i give up
[16:47] <oojah> soc: ftp is down - the guys in #launchpad know about it.
[16:47] <soc> so what should i do now?
[16:47] <oojah> Just chill out a bit :)
[16:48] <soc> *sigh*
[16:48] <soc> i spent days on that package and now when i'm finished, everything i depend on fails ... *sigh*
[17:10] <soc> File ttf-droid_1.00~b112.orig.tar.gz already exists in PPA for soc, but uploaded version has different contents. See more information about this error in https://help.launchpad.net/Packaging/UploadErrors.
[17:10] <soc> Files specified in DSC are broken or missing, skipping package unpack verification.
[17:12] <soc> is there a way to remove _all_ packages from my ppa including the source packages and starting again?
[17:12] <DktrKranz> soc, packages are not removed immediately, you should wait a bit or use a higher version numver
[17:14] <soc> but incrementing the number of the .orig.tar.gz??
[17:14] <soc> that doesn't make sense really ...
[17:15] <DktrKranz> soc, I misread sorry. .orig.tar.gz differ in md5sum, so you should use the one provided by Ubuntu or by your PPA itself for future revisions
[17:19] <maxb> soc: Once uploaded, it is never permitted to change the contents of a file. You MUST use a new version number.
[17:20] <maxb> For example: 1.00~b112+repack1
[17:22] <fabrice_sp_> Hi. I'm doing an upgrade of a package and a previous patch is not accurate anymore (one line has been move). Do I update the previous patch or do I create a new patch?
[17:23] <Laney> fabrice_sp_: update it, no point keeping an old patch around
[18:18] <LaserJock> is anybody maintaining kompozer?
[18:19] <soc> mhh, how long will it tkae until my package actually appears in revu, after i imported it?
[18:27] <vorian> LaserJock: i've touched it recently
[18:28] <LaserJock> vorian: do you know if there is a usual maintainer?
[18:28] <LaserJock> I'm considering putting it in Main
[18:28] <LaserJock> but I'd hate to rip it out of a MOTU's hands
[18:29] <vorian> hmm
[18:29] <sebner> LaserJock: I thought upstream is dead since years?
[18:29] <LaserJock> sebner: on kompozer?
[18:29] <vorian> LaserJock: yeah, that's tonyyarusso's package
[18:29] <LaserJock> we found some signs of life
[18:30] <vorian> it hasn't been changed since hardy :o
[18:30] <sebner> LaserJock: ah, well lastest release is 5. sep 2007. Besides, the mozilla team told me that it's dead (but another replacement already in work)
[18:30] <LaserJock> that's not all that long ago
[18:31] <LaserJock> sebner: you happen to remember what it was called?
[18:31] <sebner> LaserJock: unfortunately not but it wasn't stable yet anyways. I'll ask the mozilla guys :D
[18:32] <LaserJock> it seems like most software is either dead/dying or new/unstable
[18:34]  * sebner likes new stuff :P
[18:36] <LaserJock> I don't
[18:36] <LaserJock> because it teases you with possibility ;-)
[18:36] <sebner> heh
[18:37] <sebner> LaserJock: btw, I think it's http://www.bluegriffon.org/
[18:50] <CarlFK> I need rules/quilt help:  rules/results: http://dpaste.com/106056/
[18:52] <LaserJock> CarlFK: I think that's supposed to be patched-stamp not stamp-patched
[18:52] <hanska> CarlFK: line 35
[18:52] <hanska> $(QUILT_STAMPFN) is a dependency of configure-stamp, not a command
[18:52] <hanska> thus, that should be
[18:53] <hanska> configure-stamp: $(QUILT_STAMPFN)
[18:53] <hanska> (i.e. it's a target, not a command inside the configure-stamp target)
[18:53] <hanska> CarlFK: also, you forgot the unpatch target as dependency of the clean one
[18:53] <CarlFK> right.  been years since I did make.  thanks
[18:54] <hanska> (be careful if you use patched makefiles for the clean -- and, however, I suppose something like "$(MAKE) clean" should go there)
[19:10] <soc> how long will it take until my package actually appears in revu after i imported it?
[19:11] <pmjdebruijn> I can take a few minutes
[19:11] <pmjdebruijn> max 20 if I'm not mistaken
[19:18] <james_w> would "ppamadison" have a place in ubuntu-dev-tools?
[19:19] <james_w> "ppamadison james-w bzr-builddeb"
[19:19] <james_w> it was bigon's idea
[19:19] <fabrice_sp_> I'm working on bug 313995. What do I attach to the bug? a debdiff between the 2 debian directories? Or the dsc, orig tarball and diff file?
[19:19] <Laney> fabrice_sp_: just the diff
[19:19] <Laney> if it's an ubuntu upgrade and not a merge
[19:19] <Laney> diff.gz that is
[19:20] <fabrice_sp_> this package is only in ubuntu
[19:20] <fabrice_sp_> ok
[19:20] <james_w> the url of the upstream tarball is also useful to have
[19:20] <Laney> damn you sponsors
[19:20] <james_w> :-)
[19:21] <fabrice_sp_> just building in a sbuild. If it works, I will upload the diff file and put the url. :-)
[19:30] <slytherin> calc: there? need to discuss something about OOo dependencies that needs to be moved to main.
[20:01] <huats> persia: are you around ?
[20:23] <tonyyarusso> For when LaserJock returns, there is a new version of KompoZer in the works currently, with an alpha that seems to run pretty well for most people (and better than the current version in Intrepid does).  Hopefully that will be finalized in time for 9.04, and either backported or PPAd for 8.10.  The long-term replacement, BlueGriffon, is likely to be ready in time for 9.10 (hopefully).
[20:23] <tonyyarusso> I'm tracking various developments and do plan to package whatever I can get my hands on.
[20:32] <calc> slytherin: ok
[20:32] <calc> slytherin: whats up?
[20:33] <slytherin> calc: with all the java libraries that are build dependencies of OOo 3, are we expecting them to be included on CD? Also does that mean a JRE will be included?
[20:34] <calc> slytherin: not included on the cd, no
[20:34] <calc> slytherin: they are needed for build-depends and will be in main so if you install 'openoffice.org' they will be pulled in
[20:35] <calc> there isn't nearly enough space on the cd to actually include all of openoffice.org much less all of its dependencies
[20:35] <slytherin> calc: Ok.
[20:35] <huats> nxvl: ping
[20:35] <huats> are you around ?
[20:37] <jpds> huats: is idle : 1 days 4 hours.
[20:37] <huats> jpds: I have realized right after :)à
[20:37] <huats> thanks jpds
[20:38] <huats> :)
[20:38] <jpds> huats: bonsoir anyhow. :)
[20:38] <huats> :)
[20:39] <Chris`> huats: Have you finally managed to get around to the mentoring list with my email? :)
[20:40] <huats> Chris`: I am doing that right now :)
[20:40] <Chris`> Wow really? :)
[20:40] <huats> I will contact you by the end of the week
[20:40] <huats> Chris`: really !
[20:40] <Chris`> Great, ok thanks :D
[20:40] <Chris`> A bit of a time lag but who cares?
[20:41] <huats> Chris`: thanks...
[20:41] <huats> I am clearing the mentoring request queue
[20:42] <huats> but before I have to check the status of the current mentee
[20:42] <huats> that is what I am doing right no
[20:42] <huats> w
[20:42] <nxvl> huats: pong
[20:42] <huats> so you can expect a mentor by the end of the week (or early next one)
[20:42] <Chris`> huats: That sounds fantastic
[21:01] <jpds> Anyone remember where harvest is?
[21:01] <Laney> http://daniel.holba.ch/harvest (iirc)
[21:01] <jcastro> ^^
[21:01] <Laney> i do rc!
[21:02] <jpds> Ah, I was looking under his people.ubuntu.com place. Thanks.
[21:02] <kees> siretart: do you want to do the cryptsetup merge?  I don't have the bzr trees set up at the moment :)
[21:04] <directhex> who's good with man pages?
[21:05] <directhex> i have one last lintian error in the most tricksy of evil packages, and it's from man
[21:10] <Laney> pastebin it?
[21:23] <directhex> Laney, i cracked it
[21:23] <Laney> mad skillz
[21:23] <directhex> Laney, i MIGHT just have a lintian-clean IKVM package here
[21:23] <Laney> sanity-clean?
[21:23] <Laney> working?!
[21:23] <broonie> How big's the ignore file? :P
[21:23] <directhex> Laney, other than the john goerzen problem
[21:24] <directhex> broonie, non-existeny
[21:24] <slytherin> calc: One more question. Is it ok to disable the unit test that causes the build failure for lucene2?
[21:25] <siretart> kees: I'm sorry but I've  been so incredibly busy since weeks that I didn't get to do any merge so far :-(
[21:25] <kees> siretart: okay, no problem, I'll take a stab at it.
[21:25] <siretart> kees: AFAIR I've pushed all branches to launchpad
[21:25] <siretart> kees: thanks!
[21:25] <siretart> kees: cryptsetup needs some love anyway. there are some bugs that need to be looked at.
[21:26] <siretart> one of them looked rather important, the UUID= not supported one...
[21:26] <kees> siretart: yeah, I can't commit to that bit of work, but I can at least get us merged with Debian, which added a ton of fixes.
[21:26] <Laney> directhex: he is on oftc
[21:26] <Laney> you could harass in PM
[21:27] <directhex> Laney, what's his /nick ?
[21:27] <Laney> directhex: cosmicray
[21:27] <directhex> * cosmicray :No such nick/channel
[21:27] <directhex> i'd guessed it was that, but it's never been there for my whoising
[21:27] <siretart> kees: yes. it was a real please being able to compare to the debian branch and revert and validate diffs on a per file basis (instead of a per tree basis) with the bzr branch
[21:27] <broonie> CosmicRay normally
[21:28] <broonie> but he's not online ATM AFACIT
[21:28] <siretart> kees: I hope that we get the debian bzr imports soon.
[21:28] <Laney> oh, irssi automatically does a whowas too
[21:28] <Laney> mea culpa
[21:29] <directhex> i hope meebey reappears & starts on the sponsoring backlog soon!
[21:30] <directhex> and i hope ikvm stops needing 1.5 gig of ram to compile
[21:31] <directhex> and for pigs to fly
[21:37] <calc> oops i missed him
[21:39] <fabrice_sp> by the way, someone interested in reviewing dvdstyler (http://revu.ubuntuwire.com/details.py?package=dvdstyler)?
[21:45] <soc> mhhh weird ....
[21:46] <soc> i imported an package into revu approx. 3.5 hours ago, but it didn't appear on my profile
[21:53] <soc> can maybe someone check if that package hangs somewhere?
[21:56] <jpds> soc: Which package?
[22:01] <soc> ttf-droid
[22:03] <jpds> soc: Afraid I can't find that in the queue or the archive.
[22:04] <jpds> Then again I'm not sure how the importer works..
[22:04] <jpds> NCommander: Can you please look into soc's problem?
[22:04] <NCommander> The PPA importer?
[22:05] <jpds> Yep.
[22:05] <NCommander> To my knowledge its non-functional
[22:05] <NCommander> The crontab is disabled
[22:05] <NCommander> RainCT was working on it, he's your main
[22:05] <jpds> soc: OK, in that case, sorry to keep you waiting, you're better off dput'ing the source package to revu.
[22:06]  * RainCT runs the importerç
[22:07] <RainCT> soc: there you have it
[22:07] <soc> thanks!
[22:07] <jpds> RainCT: Where is the importer script?
[22:07] <RainCT> jpds: /srv/revu-production/scripts/ppa-import.py
[22:08] <RainCT> jpds, NCommander: I'll add a cronjob for it
[22:08] <soc> jpds, RainCT: could you review that package?
[22:09] <jpds> soc: About to go to bed here, I'll look at it in the morning tomorrow.
[22:09] <NCommander> RainCT, the crontab is something else, thats just the frontend one.
[22:10] <RainCT> NCommander: no, the frontend is /srv/revu-production/import.py
[22:10] <NCommander> oh
[22:10] <soc> jpds: ah ok, np thanks
[22:12] <soc> "The Maintainer     field is invalid. It has to contain an @ubuntu.com address (usually the     Ubuntu MOTU Team's)."
[22:12] <soc> so what _is_ the mail address then? :-)
[22:12] <jpds> soc: make sure you have the ubuntu-dev-tools package installed and run: update-maintainer in the source root.
[22:12] <soc> motu@ubuntu.com?
[22:12] <Adri2000> Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>
[22:12] <Adri2000> but better use update-maintainer indeed
[22:13] <jpds> the script will do it for you, but that's the address^
[22:13] <RainCT> jpds: Cron job added. If you ever want to run the importer manually, do "sudo /srv/ppa_import.sh" (this new file implements a lock)
[22:14] <jpds> RainCT: OK. Thanks.
[22:21] <soc> jpds: which section do i need?
[22:21] <soc> universe?
[22:21] <Adri2000> soc: for update-manager?
[22:21] <Adri2000> euh
[22:21] <Adri2000> update-maitainer*
[22:21] <Adri2000> +n
[22:21] <soc> yes
[22:22] <soc> ok, chose universe
[22:22] <soc> seems to be right
[22:22] <jpds> Yeah, it's in universe.
[22:24] <soc> Note: This package has no debian/watch file or get-orig-source rule.
[22:24] <soc> is that too bad?
[22:24] <soc> because i'm sure that i can't fullfill that wish
[22:25] <soc> or maybe just get-orig-source
[22:25] <soc> but that won't help people to update the package
[22:25] <soc> basically you have to mess with fontforge to get the version info of the fonts
[22:25] <soc> i don't believe this can be done by some script ...
[22:34] <blizzkid> lo all. is Dustin here by any chance?
[22:36] <Laney> blizzkid: #ubuntu-devel
[22:36] <blizzkid> ty Laney
[22:39] <soc> hi
[22:40] <soc> can someone review http://revu.ubuntuwire.com/details.py?package=ttf-droid
[22:40] <soc> this is a package with some fonts, so it isn't much work, i guess
[22:49] <jpds> james_w: You have my + for ppamadison in u-d-t.
[22:49] <james_w> cool, thanks jpds
[22:50] <james_w> though that means I'll have to make it work more than just writing some output on my blog :-)
[22:50] <soc> is it a good idea to downgrade the Build-Depends from debhelper (>= 7) to debhelper (>= 6) so it builds on hardy correctly?
[22:50] <soc> or should i leave it alone?
[22:51] <jpds> soc: If you want to backport it later on, yees.
[22:51] <soc> down-grade?
[22:51] <soc> do  have to change the debian/compat file too?
[22:52] <jpds> Yep. But you only would need to do it if you want to backport it to hardy.
[22:52] <Adri2000> james_w: is ppamadison useful for ubuntu development? if it's only related to ppa I'm not sure everyone will agree
[22:52] <soc> or can i request behavior version 7 and if the versio of debhelper is too old it will fail gracefully?
[22:52] <soc> jpds: i'm thinking of debian at the moment
[22:52] <james_w> Adri2000: some people use PPAs for development, so it might be useful to them
[22:52] <soc> they have all the outdated things there ...
[22:53] <james_w> I don't really want to start a new project
[22:53] <jpds> soc: Then check which version if debhelper is in stable (I think it's 5).
[22:53] <soc> jpds: yes, just checked it
[22:53] <soc> it's 5.0.42
[22:53] <soc> so it won't make a difference
[22:54] <soc> then i guess i'll leave it
[22:54] <Adri2000> james_w: I'm saying that because of what happened with ppaput
[22:54] <soc> jpds: could you look on my package for a few seconds?
[22:56] <jpds> soc: what's debian/bug/script for?
[22:58] <soc> jpds: i took that from the ttf-liberation package
[22:58] <jpds> soc: Package not in Ubuntu/Debian. changelog should only have one entry with "Initial release." and version ending in -0ubuntu1.
[22:58] <soc> i guess it has something to do with debian/bug/presubj
[22:59] <jpds> soc: is there actually a release of the font on the web somewhere?
[22:59] <james_w> debian/bug/script is a reportbug script isn't it?
[23:00] <jpds> soc: if not: I think the version ought to be: 0.0~gitYYYYMMDD-0ubuntu1.
[23:00] <jpds> james_w: It has a dpkg command in it, no idea what it does.
[23:00] <soc> jpds: version from what?
[23:01] <jpds> soc: debian/changelog.
[23:01] <jpds> james_w: Actually looks like it grabs from some packages.
[23:01] <soc> i took the version from the fonts
[23:01] <jpds> OK. Didn't see that anywhere.
[23:02] <soc> james_w: that could be, i don't understand what that at the end should be, i get /home/soc/Entwicklung/Pakete/ttf-droid-1.00~b112/debian/bug/script: 3: 3: Bad file descriptor
[23:02] <jpds> soc: Might be a good idea to put the copyright text in README.txt in debian/copyright.
[23:03] <soc> jpds: that's my problem with debian/watch ... to see the version of the font, i have to open fontforge .. i gues that can't be automated
[23:04] <soc> i don't have a README.txt ....
[23:04] <jpds> soc: it's in the git repo linked from the package.
[23:05] <jpds> soc: It is possible to parse web pages for tarballs for watch files, take a look at http://dehs.alioth.debian.org/wwiz_detail.php?id=15766059&type=watch - for example.
[23:06] <soc> yes, i already tried that
[23:06] <soc> but the tarballs always have some git revision at the end
[23:06] <soc> and i can't get the version of the fonts
[23:06] <soc> to get the version i have to open them with fontforge
[23:07] <soc> regarding the README.txt: i didn't take that one, because the font files stated something different
[23:07] <jpds> Hmm, well, I'm going to bed for real time this time.
[23:07] <jpds> soc: OK; I'll take another look when I'm more awake in the morning.
[23:08] <soc> and because i'm not distributing the whole tarball with lots of android opensource project files, but just the google files, i wrote google in the copyright
[23:14] <soc> because in the font files, google is stated as the copyright holder
[23:14] <soc> ok, new version for revu and ppa
[23:25] <soc> is someone willing to look at the package?
[23:26] <soc> i'm just uploading a new one, after reading https://wiki.ubuntu.com/MOTU/Packages/REVU/CheckList and setting the version back to 0ubuntu1