[00:03] <savvas> clean works now?
[00:05] <savvas> that's a huge log :P
[00:06] <AdamDH> so where do I remove the clean tag?
[00:06] <savvas> maxb: is the right one dh_clean -k there.. or?
[00:06] <savvas> AdamDH: in install
[00:07] <savvas> I think it should be dh_prep or dh_clean -k
[00:07] <savvas> (still a newbie, don't mind me :P)
[00:07] <maxb> yes, that's right
[00:10] <maxb> delete the dh_clean in the build rule too
[00:12] <AdamDH> thanks will give it a clean
[00:12] <AdamDH> *go
[00:16] <AdamDH> even after removing all that I still get that error
[00:23] <AdamDH> thanks for all the help maxb I got a working package http://paste.ubuntu.com/119875/ there is my rules is that sane?
[00:23] <AdamDH> and savvas
[00:26] <savvas> AdamDH: add dh_clean in "clean:"
[00:26] <savvas> And I think everything else looks good
[00:28] <AdamDH> would that rule once corrected be considered on the next cycle for inclusion into ubuntu?
[00:31] <AdamDH> why do some packages use dh_ tags and some do not use any just a standard make and some shell?
[00:32] <savvas> what do you mean by dh_ tags? dh_* commands?
[00:32] <AdamDH> dh_* commands sorry
[00:33] <AdamDH> looking at say binutils source there rules does not have any dh_* tags
[00:33] <AdamDH> i mean commands
[00:42] <savvas> AdamDH: I think binutils is GNU utilities, probably it is treated as a special package that doesn't use any debhelper commands
[00:44] <AdamDH> its a nice rules file tho easy to read
[00:45] <AdamDH> right one package down time to clean up my gcc rules
[00:46] <savvas> AdamDH: I like to build mine using cdbs: http://bazaar.launchpad.net/~medigeek/%2Bjunk/dcsharp/files/head%3A/debian/
[00:47] <AdamDH> never really liked cdbs
[00:48] <savvas> ah, ok :)
[01:41] <maxb> savvas: every package uses dh_* commands
[01:41] <maxb> oops
[01:42] <maxb> AdamDH: ^
[01:42] <maxb> (or at least 99.9% of them, anyway)
[01:42] <ScottK> maxb: Note every one.
[01:42] <ScottK> Note/Not.
[01:43] <ScottK> It's completely and totally optional just way more trouble to avoid than to use for almost everyone.
[01:43] <maxb> ok, but the ones that don't are super-rare exceptions
[01:44] <ScottK> Unfortunately one of the Debian SE Linux maintainers is one of those exceptions.
[01:44] <savvas> heh
[01:44] <StevenK> The *vast* majority of source packages use debhelper
[01:45] <ScottK> Yes.
[01:46] <maxb> AdamDH: your indentation is a bit odd, better to be standard. you still have that wrong remove-patch logic in there. You've switched to $(PWD) - don't, I'm fairly sure $(CURDIR) is preferred.
[01:46] <StevenK> Then there's the oddballs that use debstd (isn't that dead yet?), yada (wish it was dead) or by hand
[01:47] <AdamDH> thanks maxb I will take that into account
[01:47] <ScottK> StevenK: Manoj has a very nice build system.  It's just, unique, so you have to figure it out.
[01:47] <StevenK> ScottK: Much like trying to debug kernel-package.
[01:47] <ScottK> Yes, exactly.
[01:48] <AdamDH> maxb the binutils does not use dh_* commands
[01:48] <ScottK> Although for Hardy I had to switch the dault python version in one of his packages and it was suprisingly easy to do.
[01:50] <maxb> AdamDH: Oh. Indeed it does not. How peculiar
[01:53] <AdamDH> maxb: the idea behind producing these packages was to get better support for the msp430 in linux, I started using this controller for some uni projects after been indtroduced to it at work, so I wanted debs so I could hand them to the sys admins to run them on the linux clusters they did not want to do a source install etc
[01:54] <AdamDH> i actually use a php script to build the packages as well as creating patches
[01:55] <AdamDH> hopefully after I get debs I can look at windows support using minggw
[01:57] <savvas> hm...
[01:57] <savvas> "* Rewriting copyright file in machine-interpretable format."
[01:58] <savvas> Is eebian preparing for a lintian copyright checker in the future? :)
[01:58] <savvas> *debian
[02:00] <savvas> Found this at http://ftp.de.debian.org/debian/pool/main/v/vsftpd/vsftpd_2.0.7-2.diff.gz
[02:01] <savvas> http://paste.ubuntu.com/119890/ - looks nice, almost like a debian/control file hehe
[02:04] <AdamDH> savvas thats how I do my copyright files
[02:04] <AdamDH> IMHO its a much nicer formatt
[02:06] <AdamDH> savvas: http://paste.ubuntu.com/119891/ the {} are replaced using sed
[02:09] <ScottK> savvas: You noticed the topic change, right?
[02:10] <savvas> ScottK: yes 10 minutes ago
[02:10] <savvas> nice job AdamDH, now I'm jealous for not knowing about it earlier :P
[02:11] <AdamDH> savvas: more info here
[02:11] <AdamDH> http://wiki.debian.org/Proposals/CopyrightFormat
[02:13] <savvas> thanks!
[02:28] <AdamDH> whats it called when I have one package but I want to create a package say msp430 that pulls in all the required packages?
[02:29] <maxb> a metapackage, but such a metapackage would be unusual and probably unnecessary
[02:29] <maxb> (typo fix)
[02:31] <AdamDH> true as msp430-gcc depends on msp430-binutils and msp430-libc and msp430-gdb and msp430-proxy are optional packages
[02:31] <AdamDH> thanks any way maxb was trying to find some information on them
[04:36] <superm1> ScottK, what does bug 320915 got to do with cdbs?
[04:37] <ScottK> superm1: I need to set --without-arts in kde.mk or a bunch of KDE 3 apps will fail configure now.
[04:38] <superm1> ScottK, ah that would do it.
[04:38] <superm1> but that begs another question.  why are there a bunch of kde3 apps still in the archive?
[04:38] <superm1> i thought things transitioned to kde4?
[04:40] <ScottK> We have a KDE4 desktop, but there's lots of stuff that hasn't transitioned/there is no KDE equivalent for.
[04:40] <ScottK> Our goal for this release (which we may or may not make) is no KDE3 on the CD.
[04:41] <superm1> ah
[04:46] <ScottK> For reference, last I checked gtk1.2 was still in the archive ....
[05:33] <tonyyarusso> If I made an extremely tiny (~20 lines of code) feature addition to Pidgin, is taht something I could get included in Ubuntu directly, or would I have to get it acceptied upstream first?
[05:34] <ScottK> You'd have to ask the Desktop Team.
[05:35] <tonyyarusso> Aha, all righty.
[05:35]  * tonyyarusso hopes I can clean it up enough by tomorrow to try
[05:40] <dholbach> good morning
[05:56] <slytherin> we are still few hours away from FF, right?
[06:06] <ScottK> slytherin: See /topic
[06:07] <slytherin> my mistake
[06:07] <ScottK> No problem.
[06:07] <ScottK> I was suprised slangasek pulled the trigger as early as he did too.
[06:11] <slytherin> I files a sync bug in about an hour ago thinking that FF was still away. And I was planning to do another merge.
[06:12] <ScottK> FFe are generally pretty liberal to start.
[06:12] <ScottK> If you have a good reason for them, perhaps you should ask.
[06:14] <slytherin> I will first check if the merge could really be a sync. And then file the bug accordingly.
[06:36] <persia> So I fell asleep 90 minutes before FF, while the test-builds were still running for three sync requests I was trying to sponsor.  What's the best way to request exceptions for these?
[06:47]  * persia realises everyone who might have an opinion is probably asleep, having been awake at FF.
[06:50] <didrocks> morning o/
[06:50] <Milyardo> Good morning
[06:54] <geser> good morning
[06:54] <dholbach> hi geser
[06:55] <geser> Hi dholbach
[07:19] <Laibsch> FF in effect?  I guess, I'll switch my main system to Jaunty one of these days.
[07:28] <slytherin> Laibsch: you haven't already? :-D
[07:28] <Laibsch> no, of course not
[07:28] <Laibsch> I need a working computer
[07:29] <Laibsch> without too much hassle
[07:30] <Laibsch> Is there a debvscript similar to dget but for locally available files that will copy the dsc, tar and diff to $PWD and optionally unpack the source?
[07:30] <Laibsch> slytherin: actually, I'm still on hardy.  I usually skip one release.
[07:50] <stefanlsd> Adri2000: Do you know if mom or dad stuff is available in xml or csv or some format?
[07:55] <persia> Laibsch, dget file:/// ...
[07:56] <Laibsch> persia: great, thank you!
[08:07]  * Laibsch is looking for feedback on the packaging quality of http://mentors.debian.net/debian/pool/main/p/pybugz/pybugz_0.6.11-1.dsc
[08:07] <Laibsch> I particularly am not too sure that two binaries in /usr/bin is the right thing to do
[08:09] <Laibsch> pybugz is just one single python script.  it can be used to interface bugzilla from the command line
[08:46] <\sh> moins
[08:51] <ziroday> Is there a way to see recently uploaded packages/updates?
[08:52] <soren> ziroday: There's a mailing list where every upload is announced.
[08:52] <soren> Search for jaunty-changes.
[08:52] <ziroday> soren: awesome, thanks!
[08:52] <soren> ziroday: Sure. :)
[08:53] <\sh> ziroday: dennis kaarsemaker is also providing some rss feeds...
[08:53] <\sh> ziroday: e.g. http://feeds.ubuntu-nl.org/UbuntuChanges <- consolidated rss feed for all distro release uploads/changes
[08:54] <ziroday> \sh: ooh that loos neat too, thanks!
[08:54] <soren> \sh: Ah, thanks for the link. I was searching for that a couple of days ago, but my Google-Fu wasn't strong enough.
[08:55] <\sh> soren: hehe..I just remembered that dennis is da man for rss feeds of *-changes
[08:59] <ziroday> hmm any idea why the change to xserver-xorg-video-ati says its version 1:6.11.0-1ubuntu1 but https://lists.ubuntu.com/archives/jaunty-changes/2009-February/004829.html says its 1:6.10.99.0-1ubuntu1?
[09:00] <ziroday> err in http://feeds.ubuntu-nl.org/UbuntuChanges its says its at 1:6.11.0-1ubuntu1
[09:06] <slytherin> ziroday: trust the mailing list
[09:06] <ziroday> slytherin: yeah, thought as much :)
[09:41] <AndrewGee> Hey. Still looking for a MOTU to review gpxviewer :) It's an application to look at GPS tracks. Would appreciate a review :) Thanks. http://revu.ubuntuwire.com/details.py?package=gpxviewer
[10:01] <persia> AndrewGee, Be aware that FeatureFreeze for Jaunty has passed, so reviewers may be light on the ground until close to ArchiveOpen for jaunty+1
[11:20] <savvas> The following packages have unmet dependencies: libboost-filesystem-dev: Depends: libboost-dev (= 1.34.1-15ubuntu1)
[11:20] <savvas> (jaunty)
[11:21] <Adri2000> stefanlsd: there is dad.dunnewind.net/tomerge-$component, and same for MoM
[11:23] <ScottK> savvas: In main we transitioned to boost1.35 and boost (1.34) and boost1.35 are not coinstallable.  Whatever is still build-dep/depends on boost needs to move to boost1.35.
[11:25] <savvas> oh ok
[11:27] <savvas> ScottK: I shouldn't file a bug about it, right?
[11:29] <directhex> DktrKranz, are you about?
[11:31] <ikonia> directhex: sorry my whole client crashed a minute ago
[11:31] <directhex> ikonia, sounds like you're enjoying pidgin
[11:32] <ikonia> it's normally fine, today it's just gone on a bender
[11:32] <ScottK> savvas: You should figure out which package needs changed.
[11:32] <ScottK> savvas: Then let a developer know about (a bug is a good way).
[11:34] <savvas> ok
[11:39] <ScottK> savvas: Even better, would be to change the build-dep/depends on the package, make a debdiff, and subscribe ubuntu-universe-sponsors.  Then the odds of it getting fixed go up by a couple of orders of magnitude.
[11:41] <directhex> ScottK! you're motu-release aren't you?
[11:41] <ScottK> I am.
[11:41] <savvas> on my way!
[11:42] <directhex> ScottK, if you were me, would you post merge debdiffs for packages related to 330519 (updates for the monodevelop-java and monodevelop-database packages already in the archive) via the same bug number, or open fresh bugs?
[11:42] <stefanlsd> Adri2000: thanks. thats great!
[11:43] <directhex> bah
[11:43] <directhex> BUG 330519
[11:43] <ScottK> directhex: Every time I think I understand how to use Launchpad in this case I get told I'm wrong.  I'm not the best guy to ask.  Myself, I'd use the same bug.
[11:44] <directhex> ScottK, then i think i will too. at least you made me giggle :)
[11:44] <ScottK> directhex: If you've got a limited set of packages that need FFe though, you'll want to ask for that sooner rather than later.
[11:45] <directhex> ScottK, yes, i know. hence why i was talking to DktrKranz and sistpoty about it a couple of days before FF
[11:45] <directhex> ScottK, and i decided against making bad merges last night when exhausted, in favour of missing FF & getting it right
[11:45] <directhex> so i should get that covered later today
[11:45] <ScottK> Sounds good.
[11:46] <directhex> until bug 330440 is closed, it'll suck, though. but from what i hear bug 330440 plays hell with tomboy & f-spot too
[11:48] <stefanlsd> Adri2000: is mom the authoritive source of this file? I mean does dad get it from mom?
[11:52] <Adri2000> stefanlsd: no, both MoM and DaD generate these files on their own. but I'd note that the idea comes from DaD, and that it was later implemented in MoM :)
[11:54] <stefanlsd> Adri2000: nice :)  is anyone considered more current or authoritive?
[11:56] <Adri2000> you mean, any of DaD and MoM?
[11:56] <savvas> ScottK: about boost - all metapackages in boost 1.34 should be moved to 1.35?
[11:57] <stefanlsd> Adri2000: yeah, between DaD and MoM
[11:59] <savvas> ScottK: Nevermind, I'll take a closer look between the two versions
[11:59] <Laney> directhex: sync is acked now \o/
[12:00]  * Laney chief string puller
[12:00] <directhex> Laney, sweet
[12:00] <Adri2000> stefanlsd: MoM is the official tool initially developed and still hosted by Canonical, DaD is community developed. now that MoM is free (it was not at the beginning), DaD features are being merged into MoM and DaD will disappear eventually
[12:00] <directhex> Laney, see, i don't need to become MOTU, not when i have access to several ;)
[12:00] <Laney> heh
[12:00] <Laney> I just asked super seb
[12:00] <directhex> Laney, http://packages.ubuntu.com/jaunty/moonlight-plugin-mozilla
[12:01] <stefanlsd> Adri2000: ok. great. thanks for the info.
[12:01] <Laney> :>
[12:02] <Adri2000> stefanlsd: see https://code.launchpad.net/~adri2000/merge-o-matic/dev/+merge/572 about merging the comments feature into MoM. when MoM has comments I think we will stop DaD (as it's the main thing missing currently)
[12:37] <nhandler> dholbach: Are you going to be serving on the MC until we hold an election? Or will we just have 4 people on the council temporarily?
[12:40] <geser> nhandler: only 4 MC members
[12:57] <huats> AndrewGee: Are youa round ?
[13:06] <loic-m> I've got a FFe for xvidcore, sadly my ppa was too slow yesterday to allow me to test yesterday evening, and I didn't want to upload the diff.gz before I was sure it was ok
[13:06] <loic-m> it's at https://bugs.launchpad.net/ubuntu/+source/xvidcore/+bug/306399
[13:06] <loic-m> Can motu-release or MOTU tell me if the FFe is filled ok?
[13:15] <laszlok_work> dholbach: ping
[13:16] <geser> loic-m: is the FFe documented somewhere? didn't see it mentioned in the bug nor in the new changelog
[13:22] <c_korn> need all packages that await a REVU a FFE bug report to be processed?
[13:23] <loic-m> geser: it wasn't supposed to be an FFe, it just took too long yesterday and I had trouble uploading to Launchpad ppa (which also took longer than expected to build, and just kept telling me they were going to be build in 1 min. for like one hour or more..)
[13:24] <geser> c_korn: you need a FFe when you want it finally uploaded (when it has two advocates), practically nearly nobody won't do reviews for packages without a FFe so you need to do it in parallel (find advocates and get a FFe)
[13:26] <geser> loic-m: if you have now a FFe for xvidcore please mention it in the changelog, so it can be easily checked by those who accept the uploads
[13:26] <c_korn> geser: can I just change the needs-packaging bug reports into FFe or do I have to setup special bug reports?
[13:26] <c_korn> (following this wiki https://wiki.ubuntu.com/FreezeExceptionProcess)
[13:27] <loic-m> geser: I'll reupload then
[13:28] <geser> c_korn: please turn the needs-packaging bug into a FFe or add the missing info for a FFe and subscribe motu-release. That way all the infomation is in one bug and not scattered across several bugs
[13:29] <ScottK> c_korn: The answer for an FFe on a new package is virtually always no.  There needs to be a really good reason.
[13:29] <geser> loic-m: updating the diff.gz in the bug should be enough
[13:29] <geser> loic-m: no need to do a rebuild on PPA just for an additional line in the changelog
[13:29] <loic-m> Is aline like that in the changelog ok? : * FFe request : New upstream release (LP: #306399);
[13:30] <loic-m> s/aline/a line/
[13:30] <geser> yes
[13:30] <loic-m> geser: thanks a lot
[13:31] <c_korn> ScottK: so it is not worth asking for? (updated package would be scilab)
[13:32] <ScottK> c_korn: Generally not.  Part of the reason is that as we get later in the release cycle the people who are archive admins have other stuff they need to be focused on.
[13:32] <c_korn> ok, then I will wait for 9.10. thanks
[13:33] <ScottK> c_korn: Last cycle I think we said yes to reuploading packages that were rejected out of New after FF and one case where it was part of a development spec for Intrepid.
[13:33] <ScottK> c_korn: Personally, if it's a package that makes Ubuntu work on more hardware (we have some of those I think), I'd be willing to consider that also.
[13:34] <c_korn> well scilab is a numerical math application :P has nothing to do with hardware
[13:35] <loic-m> geser: done
[13:36] <geser> looks good, now you need to wait
[13:39] <ScottK> c_korn: Have you considered trying to get it into Debian?
[13:40] <RainCT> Heya
[13:40] <c_korn> there are already open bug reports for it. jeuclid is in debians new queue which has been frozen due to the new release
[13:40] <RainCT> How was the pre-FF sprint? :)
[13:41] <ScottK> c_korn: OK, well I think it might be worth considering getting it into Debian and then it would auto sync into Ubuntu for the next release.
[13:42] <ScottK> There's a Debian Science team that you could probably work with on it (you may know this already, I realize).
[13:43] <c_korn> I am member of the debian-science team
[13:43] <ScottK> Excellent.
[13:44] <c_korn> I also already ported the patches back to debian that were required for ubuntu
[13:46] <dholbach> laszlok_work: pong
[13:46] <ScottK> Personally I think it's better to maintain packages that you have an interest in in Debian as many more people will benifit.  The now generally if i do a new package it enters through Debian.
[13:47] <laszlok_work> dholbach: do you have time to upload a new jokosher? :) https://launchpad.net/jokosher/0.11/0.11
[13:48] <dholbach> laszlok_work: we're in Feature Freeze now, but I'll take a look and care of it - just not this week - I'll add it to my list, OK?
[13:48] <ScottK> laszlok_work: We're past feature freeze.
[13:48] <laszlok_work> dholbach: k thanks
[13:50] <c_korn> ScottK: ok, then I will keep the package in a PPA and wait for debian to release it. then I will push the sync bug report again. the jaunty milestone can also be removed from the bug report https://bugs.launchpad.net/debian/+source/scilab/+bug/272264
[13:51] <ScottK> c_korn: I'll take care of it.  Sorry it didn't work out better.
[13:51] <c_korn> k, thanks
[13:52] <ScottK> c_korn: Looking at the bug, this isn't a new package is it?
[13:52] <ScottK> When you were discussing REVU, I thought this was a new package.
[13:53] <c_korn> it is a new release
[13:53] <c_korn> scilab-4 is in the repositories
[13:53] <c_korn> but it is also not a sync because the package is also not in debian. it is just build in a PPA
[13:53] <ScottK> So the intent is to keep that and add scilab-5?
[13:55] <c_korn> it is an update for scilab. was it wrong to upload it to REVU? I thought all packages that do not come from debian or packages are completely new must go there first. sorry if I did it wrong
[13:56] <ScottK> It's not completely new.
[13:56] <ScottK> It's an upgrade of an existing package.
[13:56] <ScottK> Generally we don't use REVU for that.
[13:57] <ScottK> I would suggest talk to mok0 about it and see if he's interested in pursuing a feature freeze exception.
[13:57] <ScottK> For an upgrade to an existing package if it's been well tested and there's a MOTU to look after the package, that's not so hard to get.
[13:59] <c_korn> ok, but scilab-5 still depends on jeuclid also is not in ubuntu,yet. (I requested a REVU)
[13:59] <c_korn> +which
[14:00] <ScottK> Which makes it harder.
[14:01] <ScottK> Personally, if mok0 tells me this is important from a science perspective, I'd be inclined to at least consider it.
[14:03] <savvas> ScottK: boost1.35 and boost1.37 and their binary packages can co-exist installed?
[14:04] <ScottK> savvas: I haven't actually checked 1.35 and 1.37.  boost (1.34) and boost1.35 cannot.
[14:05] <savvas> ok I think I found the culprit, boost1.35 was missing a few "Provides:", testing a ppa build now
[14:09] <AndrewGee> huats_: Hi. You asked if I was around.
[14:09] <huats_> AndrewGee: I did indeed !
[14:09] <huats_> :)
[14:09] <AndrewGee> :)
[14:25] <savvas> arts is for sound right?
[14:26] <broonie> Yes, though I thought that was KDE3 only.
[14:26] <ScottK> savvas: Yes.  We are trying to remove it from the archive right now.
[14:26] <ScottK> As broonie says, it's KDE4 only.
[14:26] <ScottK> 4/3
[14:28] <savvas> hm..
[14:29] <savvas> I'm looking at bug 328932 - logically it shouldn't affect x11 and opengl of libsdl1.2
[14:30] <ScottK> IIRC whoever tried to extract the need for arts from libsdl had some unfortunate side effects.
[14:32] <ScottK> https://wiki.kubuntu.org/RemoveArts
[14:48] <savvas> ScottK: is it normal for boost1.35 to fail in PPA?
[14:48] <savvas> ...failed updating 224 targets... // ...skipped 12 targets... // ...updated 11 targets... // make: *** [build-stamp] Error 1 // dpkg-buildpackage: failure: debian/rules build gave error exit status 2
[14:49] <ScottK> savvas: No.
[14:49] <ScottK> savvas: What PPA?
[14:49] <savvas> the only thing I've changed is debian/control, to add the 'Provides:'
[14:49] <savvas> http://launchpadlibrarian.net/22876525/boost1.35_1.35.0-8ubuntu3_1.35.0-8ubuntu4.diff.gz
[14:49] <savvas> warning! it's a huge log file
[14:49] <savvas> ScottK: https://edge.launchpad.net/~medigeek/+archive/ppa
[14:50] <savvas> ScottK: oops sorry, wrong link: https://edge.launchpad.net/%7Emedigeek/+archive/ppa/+build/875553/+files/buildlog_ubuntu-jaunty-i386.boost1.35_1.35.0-8ubuntu4_FAILEDTOBUILD.txt.gz
[14:51] <bddebian> Heya gang
[14:55] <ScottK> savvas: I'm not sure what to tell you.  I uploaded a boost1.35 fix yesterday and it built fine.
[14:55] <sistpoty|work> hi folks
[14:55] <sistpoty|work> damn, looks like FF was announced just too early, so that I'll need a FFe now myself? *G*
[14:55] <savvas> ScottK: ok, I'll try it locally
[15:03] <sistpoty|work> ScottK, DktrKranz: bug #331583
[15:05] <kirkland> geser: Koon: are both of you guys around?
[15:05] <kirkland> geser: Koon: i'm looking at https://bugs.edge.launchpad.net/ubuntu/+source/oscache/+bug/252318
[15:05] <Koon> yep
[15:06] <slytherin> Does anyone know any particular reason why ubuntu-restricted-extras has direct dependency on libdvdread3 libmp3lame0?
[15:06] <Koon> kirkland: afaict it's a big mess of stuff half in universe half in multiverse
[15:06] <Koon> like with source in multiverse and binaries in universe
[15:07] <Koon> kirkland: since they tend to build-dep on each other, they need to move at the same time.
[15:07] <Koon> kirkland: geser had a look at it too, maybe he can confirm
[15:08] <kirkland> Koon: thanks.
[15:08] <geser> kirkland: yes, I'm around
[15:09] <kirkland> geser: can you confirm that all of (ehcache, libhibernate3-java, libswarmcache-java, oscache) are all ready to move to universe?
[15:09] <kirkland> geser: https://bugs.edge.launchpad.net/ubuntu/+source/oscache/+bug/252318 fyi
[15:10] <geser> kirkland: I've checked the build-dependencies and the runtime dependencies from the affected package and they're either already in main or universe (or one of the affected packages)
[15:10] <kirkland> geser: :-)
[15:10] <Koon> as for "freeness", they are all in debian main, so they should be alright
[15:10] <kirkland> Koon: right-o
[15:12] <geser> kirkland: should I add the debian version where the packages moved from contrib to main to the bug?
[15:12] <kirkland> geser: hey, that would be nice, sure
[15:18] <slytherin> Does anyone know any particular reason why ubuntu-restricted-extras has direct dependency on libdvdread3 and libmp3lame0?
[15:19] <geser> kirkland: added to the bug, anything else missing?
[15:20] <kirkland> geser: nope, i think we're good.
[15:20] <kirkland> geser: i'm processing shortly
[15:21] <geser> kirkland: could you also "fix" bug 323863?
[15:21] <kirkland> geser: sure
[15:26] <loic-m> Which files do I need to look at when provding a diff of the symbols for a new version of a library?
[15:28] <geser> I didn't use it myself yet, but probably the output of check-symbols
[15:29] <geser> it's in ubuntu-dev-tools
[15:32] <loic-m> geser: thanks
[15:34] <slytherin> what is the way to unsubscribe someone else from a bug?
[15:35] <geser> slytherin: you can't (unless it's a team you're part of)
[15:35] <slytherin> there is no way? not even possible by asking a lp admin?
[15:37] <DktrKranz> sistpoty|work: IIRC, a similar request was made for Intrepid. Which benefit does it provide for Jaunty?
[15:38] <sistpoty|work> DktrKranz: hm? there wasn't a request for intrepid in regards to faumachine, as it did have some copyright problems back then
[15:38] <geser> slytherin: opening a question against LP might work but I guess you will be faster by asking the person or team to unsubscribe themselves
[15:38] <slytherin> that is what I just did. :-)
[15:39] <DktrKranz> sistpoty|work: oh, I probably confused with another piece of software then
[15:39] <sistpoty|work> DktrKranz: well, I had the idea to use faumachine for cd testing purposes... (which I still think would be a good use of it)
[15:40] <DktrKranz> I don't know upstream project at all, could you summarize very briefly about it?
[15:41] <sistpoty|work> DktrKranz: sure... I'll try to be brief. FAUmachine is a virtual machine like qemu, however it comes with fault injection capabilities and a rich testing framework
[15:41] <sistpoty|work> DktrKranz: and lots of examples, like installing ubuntu 7.10 (provided that you've got the iso at hand)
[15:42] <DktrKranz> I see, so it could be useful for QA purposes such as stres-testing for SRUs, or similar?
[15:43] <sistpoty|work> DktrKranz: rather for iso testing... e.g. checking if lvm+raid still works with the newest daily
[15:43] <kirkland> geser: Bug #323863 : done ;-)
[15:43] <DktrKranz> sistpoty|work: sounds cool :)
[15:44] <sistpoty|work> DktrKranz: basically anything a user could type/click can be automated with faumachine (w.o. need to mess with the iso at all)
[15:45] <DktrKranz> sistpoty|work: so it is almost ready for upload, isn't it?
[15:45] <sistpoty|work> DktrKranz: yes, the problem that stresses me more atm is that I'm trying to dist-upgrade my office laptop to jaunty straight from hardy, which seems to be a very bad idea *g*
[15:46] <sistpoty|work> DktrKranz: others than that (I do want to do a final test with jaunty), it's ready for upload
[15:47] <DktrKranz> sistpoty|work: sounds good, I'll comment it on the bug ;)
[15:47] <DktrKranz> and good luck with hardy -> jaunty
[15:47] <sistpoty|work> DktrKranz: thanks! :)
[15:57] <geser> kirkland: did you also moved the libjdic-java source from multiverse to universe? (or is just LP laggy?)
[15:58] <slytherin> geser: any idea how good is openjdk-6-jre on amd64?
[16:14] <kirkland> geser: hmm
[16:15] <geser> slytherin: I don't use any java apps, so I can't tell
[16:15] <kirkland> geser: seems it's already there
[16:15] <kirkland> geser: https://bugs.edge.launchpad.net/ubuntu/+source/libjdic-java/+bug/323863/comments/4
[16:15] <geser> kirkland: just saw it too
[16:16] <geser> so it was just LP a little bit behind
[16:19] <slytherin> I hope all these move to universe activities is not giving any chance to soyuz for eating packages.
[16:20] <loic-m> does anyone has Jaunty installed or in a vm?
[16:20] <loic-m> I'm trying to run : check-symbols xvidcore
[16:20] <loic-m> it works on Intrepid, but fails on Jaunty
[16:20] <loic-m> "package doesn't exit : libxvidcore"
[16:22] <slytherin> loic-m: I have jaunty installed.
[16:22] <loic-m> I think pb is on my side actually
[16:22] <loic-m> works if I don't have my ppa in source.list, doesn't work with it
[16:23] <loic-m> that's realy strange
[16:24] <slytherin> loic-m: I am getting this - No matching binary files found in «/var/cache/pbuilder/result».
[16:25] <lfaraone> Hi, would changing a new feature upstream added to be on by default when a package is installed require a FFE if implemented after FF?
[16:25] <loic-m> Which means I'd need to build it in Jaunty, not just on my ppa?
[16:27] <sistpoty|work> loic-m: maybe you'd just want readelf -s <sharedobjectinpackage> | sort?
[16:28] <sistpoty|work> loic-m: (for all shared objects contained in the package)
[16:29] <loic-m> sistpoty|work: i'm not sure I'd be able to tell which file is a sharedobject
[16:29] <sistpoty|work> loic-m: shared objects live in /usr/lib (or /lib) and end with .so ;)
[16:30] <loic-m> I've been on xvidcore since monday, my brain is going to short off soon
[16:30] <slytherin> lfaraone: imo, yes
[16:31] <loic-m> sistpoty|work: i don't really understand. Do you mean I install the new version, check what files it puts in /usr/lib and run readelf -s on them?
[16:31] <sistpoty|work> loic-m: yes, and the same for the old version... (you don't even need to install it, dpkg -x <deb> somedirectory will extract the contents to somedirectory)
[16:32] <loic-m> sistpoty|work that sound really interesting. Can I just do that from my current Intrepid?
[16:33] <sistpoty|work> loic-m: yes
[16:35] <loic-m> sistpoty|work thanks a lot
[16:35] <sistpoty|work> loic-m: no problem
[16:36] <sistpoty|work> loic-m: eventually, you'll want to modify the output of readelf -s a little bit afterwards... the interesting bits are the symbol names and symbol versions (the other stuff can be ignored)
[16:37] <lfaraone> slytherin: Ok.
[16:37] <lfaraone> slytherin: (currently the application acts oddly with the feature turned off)
[16:38] <lfaraone> slytherin: (and the feature is already in jaunty)
[16:39] <slytherin> lfaraone: then do you need new upstream version for that? Can't you just change package in jaunty to turn on the feature by default?
[16:40] <lfaraone> slytherin: currently the upstream is in a feature freeze as well, in the RC1 stage.
[16:40] <lfaraone> slytherin: so we theoretically can import all of the new upstream versions, since all changes after what's currently in jaunty should be bugfixes.
[17:02] <loic-m> sistpoty|work: do you think I just need to run readelf -s on -dev libraries only, and is doing it for one arch sufficient?
[17:04] <sistpoty|work> loic-m: the actual shared object should be in the lib* package, the -dev package only contains the link
[17:04] <sistpoty|work> loic-m: and yes, one arch is ok
[17:04] <sistpoty|work> loic-m: oh, and as I've just looked at the output of readelf -s myself, please filter out undefined symbols (those marked as UND)
[17:07] <loic-m> sistpoty|work: thanks a lot. Actually it helped me see I need to update the packaging
[17:14] <loic-m>  sistpoty|work http://paste.ubuntu.com/120195/ is that the desired output for attaching to bug 306399 ?
[17:15] <sistpoty|work> loic-m: almost... can you filter out these columns: "35: 00000000000114b0  4363"?
[17:16] <sistpoty|work> loic-m: the interesting bits are actually: did a symbol vanish which was there before
[17:16] <sistpoty|work> loic-m: if it just changed in size, but is still there, that's not a problem
[17:16] <sistpoty|work> loic-m: granted, in this case it's easy enough to spot in that output as well that no symbol disappeared ;)
[17:21] <loic-m> sistpoty|work: I'll do that
[17:21] <sistpoty|work> loic-m: thanks!
[17:21] <stefanlsd> Does anyone know where the colors for MoM are documented?  http://merges.ubuntu.com/universe.html     - so the red, or dark / light green?
[17:22] <sistpoty|work> stefanlsd: not too sure, but it could be Priority from debian/control
[17:23] <DktrKranz> sistpoty|work: just to improve my knowledge, is there something I should read about library management/symbol handling?
[17:23] <stefanlsd> sistpoty|work: aah. yeah. i think you're right. will check
[17:24]  * Laney hunts for motu-sru
[17:24] <sistpoty|work> DktrKranz: the library packaging guide is always a good read... also iirc there's an annotated log from the library packaging session in the wiki (but I forgot where)
[17:26] <DktrKranz> sistpoty|work: ELF internals are a good candidate too?
[17:26] <sistpoty|work> DktrKranz: haven't read that myself yet, so no idea
[17:26] <sistpoty|work> DktrKranz: but it sounds interesting :)
[17:26] <DktrKranz> heh
[17:29] <stefanlsd> sistpoty|work: yeah, in 0-5.  [ "unknown", "required", "important", "standard", "optional","extra" ]
[17:47] <sistpoty|work> ScottK, iulian: any opinions on bug #331583? (I'm about to leave the office, and would like to upload it once I'm home, so please, please, please *g*)
[17:52] <directhex> hello sistpoty|work. i'm gonna prepare merges for the new versions of the 2 monodevelop plugins currently in the archive, and attach to that MD2 bug. okay?
[17:53] <iulian> sistpoty|work: Accepted.
[17:57] <sistpoty|work> iulian: thanks a lot!
[17:57] <sistpoty|work> directhex: sure thing
[17:58] <iulian> No problem, I'd like to see that in Jaunty.
[17:58] <sistpoty|work> :)
[18:00]  * sistpoty|work heads home now
[18:00] <sistpoty|work> cya
[18:27] <slytherin> can any of the motu release team members take a look at bug 331392?
[18:29] <slytherin> don't bother. someone synced it already. :-)
[18:37] <geser> slytherin: on a quick look, it looks like a bugfix release, so you don't need a FFe
[18:38] <slytherin> geser: better safe than sorry. :-) anyway it was just synced when I added last comment.
[18:39] <slytherin> got to go. sleepy now.
[19:09] <savvas> hm.. mplayer is using svn now, the stable releases are marked outdated
[19:12] <hyperair> asac: bug #248705 -- you asked me to ping you if nothing happened after two weeks
[19:32] <Laibsch> Does "pbuilder-dist sid create" work successfully for anyone? http://rafb.net/p/F1VUwD66.html
[19:43] <ScottK> Yes.
[19:44] <ScottK> Laibsch: IIRC the one on Hardy is broken.  Try hardy-backports for a newer one.
[19:45] <Laibsch> ScottK: Hehe, you're assuming now.
[19:45] <Laibsch> Although not without reason
[19:45] <Laibsch> But I was trying the backports version
[19:45] <ScottK> Making an educated guess.
[19:45] <ScottK> OK, then I don't know.
[19:46] <Laibsch> I'm wondering if maybe there's something cached from a previous run
[19:46] <ScottK> The one I used that worked was the intrepid one.  The hardy-backports one is newer, so it may have been rebroken.
[19:46] <ScottK> Check your .pbuilderrc
[19:46] <Laibsch> Thanks for trying
[19:48]  * Laibsch has no .pbuilderrc
[19:49] <geser> what about /etc/pbuilderrc?
[19:49] <ScottK> directhex: If a package needs to have itself installed to build the source, I'd consider that a bug.
[19:49] <geser> as I wonder why it tries to access PPAs
[19:50] <directhex> ScottK, i'm inclined to agree. i want to better understand WHY it's the way it is
[19:50] <directhex> ScottK, it would be much easier to do it if i could pbuilder it, which means MD 1.9.2 would need to be in universe ;)
[19:51] <ScottK> directhex: I'm certainly not going to ack something that does that without a lot of convincing there is no other way.  Consider how that affects bootstrapping a new arch.
[19:51] <ScottK> directhex: Use pbuilder login and play with it in an open chroot.
[19:51] <geser> directhex: what about adding your PPA to your pbuilder?
[19:51] <directhex> ScottK, it's not a circular dep - it's a plugin needing the main app
[19:52] <ScottK> Ah.
[19:52] <ScottK> I misread your comment then.
[19:52] <directhex> ScottK, and it's arch:all too, so no bootstrap question ;)
[19:52] <ScottK> We don't do binary uploads in Ubuntu.
[19:52] <directhex> ScottK, but i'd like to remove the issue if i can, since it's a PITA to work on
[19:52] <ScottK> OK.
[19:54] <directhex> ScottK, my DSL is misbehaving today, doesn't help
[20:01] <directhex> oh... my... ***
[20:01] <directhex> ScottK, you want to hear it?
[20:01] <ScottK> OK
[20:01] <directhex> http://paste.debian.net/28773/
[20:03] <savvas> isn't that bash scripting? debian/rules accept bash?
[20:04] <directhex> savvas, debian/rules is a makefile. it understands gnu make stuffs
[20:05] <RAOF> Hurray for single-buttocked build-systems.
[20:06] <savvas> directhex: ok, but I mean that, as far as I know, this command is bash, not sh-compatible: [ ! -f Makefile ] || /usr/bin/make clean
[20:06] <savvas> I'm probably wrong though :P
[20:06] <RAOF> savvas: Each tab-indented line of a makefile is run in a shell.
[20:07] <geser> savvas: which part of the line should be not sh?
[20:08] <directhex> ScottK, so, erm... ideas? now i see why meebey swears so much about MD packaging
[20:09] <savvas> geser: nothing, my bad - I think it was "[[ ... ]]" that sh couldn't use
[20:09]  * savvas tries
[20:11] <directhex> my word, a Wulfie
[20:11] <Lucas_Smithen> directhex: Normally a Wulfie. From 3-5 on Thursdays a Lucas_Smithen
[20:13] <directhex> which one works for Transgaming?
[20:13] <Lucas_Smithen> both
[20:13] <Lucas_Smithen> :)
[20:15] <directhex> hm, 4 years since we last spoke. how time flies
[20:16] <Lucas_Smithen> has it really been that long?
[20:16] <Lucas_Smithen> wow
[20:16] <Lucas_Smithen> so how have you been?
[20:16] <Laibsch> http://rafb.net/p/KzufcV72.html is my /etc/pbuilderrc, geser, please excuse the belated response
[20:16] <Laibsch> I guess that answers the PPA question
[20:16] <directhex> busy
[20:16] <Laibsch> Anything incorrectly set?
[20:18] <Lucas_Smithen> i hear that
[20:20] <geser> Laibsch: try setting COMPONENTS="main" as Debian doesn't have the other components and try again
[20:21] <savvas> hm.. boost1.35 fails to build in PPA: https://launchpad.net/~medigeek/+archive/ppa/+build/875552/+files/buildlog_ubuntu-jaunty-amd64.boost1.35_1.35.0-8ubuntu4_FAILEDTOBUILD.txt.gz
[20:21] <savvas> I've built it successfully on my machine, but not in PPA
[20:22] <ScottK> directhex: I have tried very hard and so far succeeded in avoiding knowing how this mono stuff works.
[20:23] <directhex> ScottK, it's makefile-fu, not mono-fu
[20:23] <directhex> ScottK, i have a nasty hack. i want to discuss it with meebey
[20:23] <ScottK> Ok.
[20:26] <geser> savvas: your local build was also with python3 installed?
[20:27] <savvas> hm..
[20:27] <savvas> geser: I don't think so, let me check
[20:28] <geser> savvas: the build looks for python 2.4 headers (see the gcc call before the the python errors) but only python2.{5,6}-dev is installed
[20:29] <ScottK> I wonder if this is caused by all the python uploads yesterday and today.
[20:29] <ScottK> I uploaded a revised boost1.35 yesterday morning to the archive and it worked out fine.
[20:30] <geser> ScottK: you seem to be right, https://edge.launchpad.net/ubuntu/+source/python-defaults (see the 2.5.4-0ubuntu1 upload)
[20:30] <savvas> ScottK, geser: I'll try and rebuild it now that I've upgraded
[20:31] <savvas> I mean locally
[20:31] <geser> savvas: I guess you need to patch it to build against python 2.5 instead of python2.4
[20:32] <savvas> geser: you're a life-saver :)
[20:32] <savvas> I'll try it in a couple of minutes, but it takes a while to build
[20:41] <ScottK> I just tested and libboost1.35-dev is still installable, so this isn't a crisis.
[20:41] <ScottK> It's not going to break any other builds.
[20:46] <geser> but should be fixed for jaunty anyway
[20:50] <fransman> savvas: question ... are you moving well with flumotion ?
[20:52] <davromaniak> I would like to know if anybody here knows python-apt
[20:53] <ajmitch> davromaniak: it depends on what you need to do with it
[20:53]  * ajmitch hasn't used it for awhile, but was able to use it to install some packages
[20:54] <savvas> fransman: unfortunately, no reply from the maintainer yet about it - feel free to take over the one I've created if you wish :)
[20:55] <davromaniak> ajmitch: I would like to do a thing pretty simple
[20:55] <davromaniak> a basic text export of upgradable packages
[20:57] <davromaniak> I know "apt-get upgrade -s | grep "^Inst" | awk {'print $2'}" does the trick, but I searching an other way to do it
[20:57]  * ajmitch would guess that there's something in apt.cache that would give you that info
[20:58] <davromaniak> ok
[21:01] <ajmitch> cache = apt.Cache()
[21:01] <ajmitch> you can iterate over cache as a dictionary of packages
[21:02] <davromaniak> ok
[21:04] <ajmitch> davromaniak: ah, each package in that dict has an isUpgradable property
[21:04] <davromaniak> ok
[21:21] <Laibsch> https://help.launchpad.net/Packaging/PPA#Using%20packages%20from%20other%20distributions is great, but it kind of skips over how to actually get that .changes file.  I opened question 51583 for that.
[21:22] <Laibsch> Maybe you want to include a link to http://oss.leggewie.org/ppa-upload-hardy which does make all this a one-line operation.
[21:22] <Laibsch> cprov: I see you are the one to last edit above page, maybe you want to update it again?
[21:23] <ScottK> Laibsch: We have nothing to do with Launchpad here.  We just use it.  Try #launchpad.
[21:23] <Laibsch> ScottK: Understood and I thought which channel would be best for this
[21:24] <Laibsch> I think a large amount of the users of PPA would hang around here
[21:25] <ScottK> It's really ot
[21:29] <Laibsch> Then let's not make it worse by discussing it.  If cprov had felt motivated to make the change if I had contacted him in #launchpad, but doesn't feel an inclination to do it because I did it here, well foobar.  I'm not gonna run around offering something that makes other ppl's life easier.
[21:30] <Laibsch> OT warning duely noted
[21:38] <directhex> ScottK, i have a new debdiff which removes the need for the package deps installed before debuild works
[21:51] <ScottK> directhex: Good.  I don't have time to look at it for sponsoring just now though.
[22:00] <savvas> A lot of game packages are affected by this: https://bugs.launchpad.net/ubuntu/+bug/328932
[22:04] <directhex> DktrKranz, pang! monodevelop's ready for a proper look from those sexy motu-release people now
[22:05] <ScottK> superm1: Is 328932 a consequence of the upload you sponsored that got rid of arts?   ^^^
[22:19] <Laibsch> geser: It was indeed the COMPONENTS setting.  Thanks.
[22:25] <Laibsch> bug 331806
[22:26] <savvas> woohoo! lpia boost1.35 built successfully: http://launchpadlibrarian.net/22888973/buildlog_ubuntu-jaunty-lpia.boost1.35_1.35.0-8ubuntu4~ppajaunty1_FULLYBUILT.txt.gz
[22:27] <DktrKranz> directhex, am I sexy? brrrr :)
[22:52] <directhex> DktrKranz, had a chance to try it out from my ppa yet? i haven't uploaded the plugins there though
[22:53] <directhex> did i mention it's awesome? :p
[22:53] <DktrKranz> directhex, not yet, I'll probably have some tomorrow night
[22:56] <directhex> DktrKranz, do you want me to file any FFe request paperwork beyond what i have?
[23:00] <RAOF> Time to merge evo# and file some FFe paperwork.
[23:03] <DktrKranz> directhex, a list of changes (even if huge!) is welcome
[23:05] <savvas> what's FFe?
[23:06] <savvas> I've seen it so many times these last 2-3 days
[23:06] <directhex> the upstream changelog you mean?
[23:07] <porthose> savvas: Feature Freeze Exception
[23:07] <Hobbsee> !ff | savvas
[23:07] <Hobbsee> bah
[23:07] <directhex> poor Hobbsee
[23:07] <DktrKranz> directhex, yep
[23:07] <Hobbsee> i'm sure that used to sya feature freeze
[23:09] <directhex> !cake | Hobbsee
[23:09] <directhex> poor ubottu
[23:09] <directhex> a life without cake :(
[23:09] <Hobbsee> indeed!
[23:09] <RAOF> Oh, I'm lying.  Actually, we want to sync evo#, and file FFe paperwork.
[23:10] <directhex> RAOF, no gnome# dep?
[23:10] <directhex> or transitioned in debian?
[23:11] <RAOF> Bah.  That's right.
[23:11] <RAOF> No, has a gonme# dep.
[23:11] <RAOF> Acursed thing.
[23:12] <RAOF> Didn't notice that on the run-through.
[23:14] <directhex> RAOF, yay gnome# :)
[23:19] <directhex> DktrKranz, integrated licensecheck! http://monodevelop.com/Image:CapturaCodeMetrics.png
[23:20] <DktrKranz> :D
[23:30] <directhex> DktrKranz, i've made a changelog (upstream haven't made one from 1.0->2.0 yet, only 1.0->1.9.0,1.9.0->1.9.1,1.9.1->1.9.2). i don't think it's 100% accurate though
[23:41] <savvas> ScottK: Here's the patch for python 2.5 and 2.6 for boost1.35: http://paste.ubuntu.com/120352/ - In the meantime, I need figure out a way to fix "libboost-filesystem-dev: Depends: libboost-dev (= 1.34.1-15ubuntu1)" (Provides didn't do the trick)