[00:37] <LaserJock> ScottK: you doin' FTBFS again tonight?
[00:37] <ScottK> Just looking at it a bit.
[00:37] <ScottK> We also have the archive rebuild test going on now https://launchpad.net/ubuntu/+archive/test-rebuild-20090909
[00:38] <ScottK> Not much in the way of results yet, but what there is can be found here http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20090909.html
[00:40] <LaserJock> ScottK: I'm looking at a FTBFS one right now where a python package failed because of a doctest failure
[00:40] <ScottK> Ah.
[00:41] <LaserJock> but the doc test fails because it's looking at a list of modules
[00:41] <LaserJock> and it expects a certain set, but the set that's returned is longer
[00:54] <LaserJock> ScottK: that link you gave for the latest rebuild test looks like something's messed up with amd64
[00:55] <ScottK> LaserJock: Why do you say that?
[00:56] <ScottK> It's been running ahead of i386 from almost the start
[00:56] <ScottK> Most of the builds that are done are amd64, so it's no suprise that's where the failures are.
[00:56] <LaserJock> well, it looks like an awful lot are failing
[00:57] <LaserJock> in particular 9base is the first Universe package I believe alphabetically
[00:58] <LaserJock> well, close to the first
[00:58] <LaserJock> just seems like a pretty high FTBFS rate
[01:10] <ScottK> Dunno
[01:21] <LordMetroid> http://concise-software.blogspot.com/2009/08/concise-howtos-install-erlangotp-r13b01.html is reporting that JInterface is missing from the Erlang packages, is this still the case with Karmic?
[01:22] <LordMetroid> How do I figure that out?
[01:41] <wgrant> LaserJock: Those are all legit failures. i386 is just backlogged because it's i386.
[01:41] <wgrant> And the failure rate isn't much higher than expected.
[01:41] <wgrant> It was often around 10% in rebuildd, IIRC.
[01:42] <LaserJock> I was thinking it was looking like 20-30%
[01:42] <LaserJock> but upon relooking at the list of packages it's probably more like 10%
[01:42] <wgrant> LaserJock: We have gcc4.4.
[01:44] <wgrant> It's actually sitting slightly under 4% right now, but there are langpacks involved.
[01:44] <wgrant> I noticed they built first.
[01:44] <wgrant> Which makes no sense.
[01:44] <wgrant> Ah. Of course.
[01:44] <wgrant> THey're forced to a score of 0 before the rebuild archive score is forced to -10
[01:45] <wgrant> So they will have monopolised the i386 builders, and they are unlikely to fail.
[01:45] <wgrant> Hence the large number of amd64 failures.
[02:41] <qiy> !casper
[02:42] <micahg> !info casper > qiy
[02:42] <qiy> micahg: is casper dead or not?
[02:42] <micahg> !info casper
[02:43] <qiy> micahg: casper and live-initamfs, which is the future?
[02:43] <micahg> idk
[02:43] <qiy> !info live-initramfs
[02:43] <micahg> !info casper karmic
[02:43] <qiy> which is default/offical? micahg
[02:43] <micahg> idk
[02:44]  * micahg is looking for a blueprint
[02:44] <qiy> live-initramfs universe optional
[02:44] <qiy> casper main extra
[02:45] <qiy> so casper is offical
[02:49] <superm1> qiy, for the forseeable future ubuntu will be using casper
[02:49] <qiy> superm1: why they fork?
[02:50] <superm1> qiy, i'm not too sure on the history, you'll probably want to look in debian/changelog for hints and talk to those who were the initial committers
[02:50] <cody-somerville> It got forked because Ubuntu was unresponsive at the time cause Colin, the maintainer of Casper, was busy.
[02:51] <cody-somerville> live-initramfs in universe probably won't even work with Ubuntu but I saw a few weeks ago patches discussed in Debian to add support for Ubuntu to live-initramfs
[02:52] <qiy> cody-somerville: so casper is not dead
[02:53] <cody-somerville> Correct
[02:58] <qiy> cody-somerville: are they still look and work similar ?
[02:58] <cody-somerville> not at all
[02:58] <qiy> what about that live-helper? cody-somerville
[02:59] <cody-somerville> what about it?
[03:00] <qiy> !info live-helper
[03:01] <cody-somerville> qiy, live-helper 1.0.5-1 supports building live images for Ubuntu
[03:06] <qiy> cody-somerville: imo, live-helper is used with live-initramfs
[03:07] <qiy> cody-somerville: how is casper? does casper need a live-helper?
[03:07] <cody-somerville> Its nice that you have that opinion
[03:07] <cody-somerville> but live-helper supports both live-initramfs and casper
[03:08] <qiy> cody-somerville: so casper users should use live-helper too?
[03:08] <cody-somerville> qiy, To do what? Create a customized live image? They can if they want to
[03:12] <qiy> cody-somerville: yeah, to create a customized live image or ubuntu/debian create their images
[03:36] <qiy> cody-somerville: casper conflicts live-initramfs
[03:36] <cody-somerville> qiy, right - you can't use both at the same time naturally
[03:36] <qiy> it is trying to overwrite /usr/share/initramfs-tools/conf.d/compcache from live-initramfs
[03:37] <qiy> cody-somerville: ^
[03:43] <StevenK> qiy: As cody-somerville says, you can't have both installed at the same time.
[06:40] <dholbach> good morning
[07:06] <mruiz> hi all
[07:06] <mruiz> what "debuild -sa" does ?
[07:10] <randomaction> man dpkg-buildpackage
[07:12] <mruiz> randomaction, thanks
[07:13] <fabrice_sp> Hi dholbach !
[07:14] <fabrice_sp> about bug #427025, could you post the full log? I've been building this package several time, in karmic, and never got this error
[07:14] <dholbach> fabrice_sp: sure, just a sec
[07:14] <fabrice_sp> thanks :-)
[07:15] <mruiz> What is the default command to build a package: debuild -S -k<my_key> or debuild -S -sa -K<my_key> ?
[07:16] <dholbach> mruiz: -k<keyid> shouldn't be necessary if you set up DEBEMAIL and DEBFULLNAME in ~/.bashrc properly (and your gpg key)
[07:16] <dholbach> the "-sa" is only relevant if you intend to upload the package somewhere
[07:19] <mruiz> dholbach, thanks
[07:19]  * mruiz writing it down
[07:19] <mruiz> dholbach, news about the mentoring program ?
[07:20] <dholbach> mruiz: no and I'm not running it anymore
[07:20] <fabrice_sp> have to go now. CU later
[07:20] <mruiz> dholbach, who is on charge?
[07:21] <dholbach> mruiz: https://wiki.ubuntu.com/MOTU/Mentoring/Reception
[08:26] <sivang> hi all
[08:27] <sivang> is there anybody interested in packaging a very useful utility written in twisted ?
[08:29] <slytherin> sivang: Are you paying for it? :-P
[08:30] <sivang> slytherin: hmm, I would have - but now that I'm unemployed it might be a bit a problem
[08:30] <sivang> aren't there new MOTUs wanting to package their first python software ?
[08:31] <slytherin> I am not one of them. I stay away from python.
[08:31] <slytherin> And those who want to package python software have probably already done so. :-)
[08:54] <sivang> slytherin: then I guess I should do it myself
[08:54] <sivang> what's the protocol these days for upload something to unierse if my ubuntu-devel membership expired ?
[09:06] <dholbach_> sivang: 1) https://wiki.ubuntu.com/SponsorshipProcess 2) send a quick email to motu-council@lists.u.c saying that you want to rejoin the team and what your plans are
[09:06] <dholbach_> sivang: how are you doing? :)
[09:06] <dholbach_> tseliot: can you take a look at bug 411915 when you have a bit of time?
[09:07] <sivang> dholbach_: my health poor, but I'm trying to hang there
[09:07]  * sivang hugs dholbach 
[09:07] <sivang> and misses him
[09:07] <dholbach> long time no see :)
[09:07] <sivang> indeed
[09:08] <sivang> I worked for stupid company for the last year
[09:08] <sivang> was very busy
[09:08] <sivang> at least I became a plone expert
[09:08] <sivang> :)
[09:08] <sivang> so something good came out of it
[09:08] <tseliot> dholbach: I approved the merge proposed by james_w and he volunteered to upload the fix: https://code.edge.launchpad.net/~arky/ubuntu/karmic/envyng-core/fix-411915/+merge/11231
[09:08] <dholbach> ah ok
[09:08] <dholbach> super
[09:10] <tseliot> :-)
[09:11] <nicolasvw> :P
[09:21] <slytherin> How can I separate  the build process so that the targets for required by arch:all packages are not run when doing only arch:any build?
[09:23] <geser> does the upstream build process support it? e.g. a seperate target to build only the documention
[09:24] <qiy> !info gfxboot
[09:24] <qiy> !info grub-gfxboot
[09:25] <slytherin> geser: yes it does.
[09:27]  * slangasek hates curl for making the libkrb53 transition 3x harder than it should have been
[09:28]  * slangasek hates cups for ensuring the next transition will be hard too
[09:37] <geser> slytherin: then you use the binary-arch and binary-indep target and the binary target depending on both
[09:40] <slangasek> well, ultimately the right solution is to use build-arch and build-indep targets; that doesn't work today because there's a messy transition involved
[09:41] <slangasek> so you have to specifically do your building of the arch-indep stuff in the binary-indep target, and *not* in the build target where it would normally be
[09:42] <slytherin> slangasek: Thanks. And I thought I was doing something wrong. I tried putting the 'make doc' command in build-indep but it was getting built even when doing arch:any only build.
[09:42] <slytherin> slangasek: I will follow your suggestion now.
[09:43] <slangasek> yeah, because dpkg-buildpackage (which everything is based on) always calls ./debian/rules build :(
[09:43] <slytherin> slangasek: even when you say dpkg-buildpackage -B?
[09:43] <slangasek> yep
[09:43] <slytherin> that is a bug then isn't it?
[09:43] <slangasek> it's a... historical wart
[09:44] <slytherin> And that probably adds overhead on buildd. Because the even if we split the builds, build-indep gets executed on all archs.
[09:44] <slangasek> it's how things were done in the distant past; then Build-Depends-Indep were introduced but the build target wasn't split; now the only way to have dpkg-buildpackage start calling build-arch is by breaking things
[09:45] <slangasek> i.e., all packages that don't support a build-arch target today will FTBFS, there's no reliable way to detect whether the target exists and fall back to build
[09:45] <slytherin> But isn't it better to break sooner than later?

[09:46] <slangasek> the default conclusion has been that no one finds the problem important enough to break anything at all :)
[09:50] <slytherin> slangasek: The problem is usually seen with packages that have both arch:all and arch:any packages and failure in build-indep causes the whole build to fail.
[09:52] <slangasek> slytherin: if it's a build failure because of dependencies not installed, that's really a package bug at present
[09:53] <slytherin> Not because of build-deps. Consider this, javadoc generation is really 'god-knows-if-it-will-work' in some archs. So failure in generating javadoc causes problem for whole build.
[09:54] <directhex> ikvm is suitably abusive
[09:54] <directhex> i.e. the "build" target only calls build-arch
[09:54] <directhex> because the build-indep rule only works on buildds with over a gig of ram
[09:55] <directhex> since the ubuntu buildd calls build-indep separately, it works well
[09:55] <directhex> don;t know whether it works on debian as expected, but with binary uploading, doesn't really matter
[10:15] <slytherin> directhex: that is why it is hard to find a solution that works for both Debian/Ubuntu.
[10:17] <quadrispro> nhandler: ping
[10:21] <dholbach> quadrispro: I guess nhandler is sleeping now
[10:21] <dholbach> quadrispro: did you see bug 306399?
[10:22] <quadrispro> dholbach: i'm reading right now
[10:23] <quadrispro> I think we should wait for a siretart's opinion
[10:23] <andv> quadrispro, siretart left for his honey moon ;)
[10:24] <andv> quadrispro, so he won't be back in few days
[10:29] <quadrispro> after the upgrade, there's a good number of packages that would need a rebuild, and, as Loic said, siretart is looking over that
[10:32] <quadrispro> if I had some spare time, I would make more testing
[11:05] <kaushal> hi
[11:06] <kaushal> when i try to install apt-get install ssmtp
[11:06] <kaushal> i get http://paste.ubuntu.com/268493/
[11:21] <hyperair> looks like a prerm remove script problem
[11:21] <hyperair> s/remove//
[11:22] <hyperair> kaushal: file a bug
[14:35] <slytherin> slangasek: the trick you mentioned does not seem to work for some reason. My document generation target is getting called after the -doc package is created. So all the generated content is missing from -doc package.
[14:45] <bddebian> Heya gang
[14:46] <ScottK> Heya bddebian.
[14:46] <bddebian> Hi ScottK
[15:01] <dholbach> porthose: #ubuntu-meeting?
[15:01] <hjmf> dholbach: me I ask you a shameful and offtopic question?
[15:01] <dholbach> hjmf: try it and I'll see if I answer :)
[15:02] <hjmf> yesterday I noticed that my ubuntu membership expired :-(
[15:02] <hjmf> dholbach: the fact is that I didn't noticed the automatic renew emails that I received days before
[15:02] <hjmf> dholbach: can I do something about it?
[15:03] <dholbach> just a sec
[15:03] <hjmf> dholbach: k
[15:04] <dholbach> send a quick mail to ubuntu-membership-board-emea@lists.u.c
[15:04] <dholbach> they'll fix you up
[15:05] <dholbach> tell them your launchpad id and stuff and they'll take care of it
[15:05] <hjmf> dholbach, asac OK I'll do; thank you both
[15:05] <asac> great
[15:05]  * asac happy that this moves forward
[15:05] <dholbach> no worries
[15:05] <dholbach> should be quick
[15:05] <asac> dholbach: the email looks cryptic
[15:05] <asac> board-emea
[15:06] <hjmf> yes, a bit cryptic
[15:06] <dholbach> https://wiki.ubuntu.com/Membership has more info on the split
[15:06] <dholbach> and why
[15:06] <asac> ok ... so probably ok ;)
[15:07] <hjmf> dholbach: looking and sending
[15:13] <the-dude> will becomming a ubuntu maintainer be much easyer then becomming a debian maintainer?
[15:14] <slytherin> the-dude: There is no such thing as Ubuntu Maintainer. There is Ubuntu Developer. And I believe becoming Debian Maintainer (DM) is easier.
[15:15] <dholbach> basically you work on things in Ubuntu, you work with reviewers who upload changes for you, once they tell you how much great work you do, you can apply for Ubuntu developer membership
[15:16] <dholbach> https://wiki.ubuntu.com/MOTU/GettingStarted will link to all the important stuff
[15:16] <hjmf> dholbach: delivery failed to ubuntu-membership-board-emea@lists.u.c DNS error
[15:16] <dholbach> hjmf: lists.ubuntu.com, right?
[15:16] <the-dude> becomming a debian maintainer seems so formal and official
[15:16] <hjmf> my bad :-)
[15:18] <the-dude> so its building a new package and finding someone to review it ? thats all it takes?
[15:18] <dholbach> the-dude: not necessarily a new package - if you work on existing packages and improve them, that's even better :)
[15:19] <dholbach> we don't have the concept of "package maintainer" - it's not like you own a package in Ubuntu
[15:19] <dholbach> but we work on them as a team
[15:19] <dholbach> I encourage you to check out the link above
[15:19] <the-dude> but I want to add new new packages instead of fixing bugs
[15:19] <dholbach> and have a look at https://wiki.ubuntu.com/UbuntuDevelopment - it explains a lot about how things work
[15:19] <dholbach> you can do that too
[15:20] <the-dude> finding a new package which I like seems a lot easyer then waiting for a bug in a existing package I like
[15:21] <dholbach> well, I'll leave that decision to you, but I found it much easier to work on existing packages and fix a small bug here, and another small bug there instead of starting to package an application and really take care of it
[15:22] <the-dude> I already have experiance with packaging
[15:23] <the-dude> im just searching for a way to get it in to debian or ubuntu
[15:23] <the-dude> ubuntu seems a bit easyer but I have a sponsor for debian
[15:23] <the-dude> so im not sure yet
[15:25] <hjmf> dholbach: issue fixed, thank you
[15:25] <dholbach> hjmf: rock and roll!
[15:25] <hjmf> :-D
[15:50] <Laney> who's our LP liaison?
[15:56] <soren> Laney: You. Didn't you get the memo?
[15:56] <soren> :p
[15:56] <Laney> Awesome!
[15:57]  * Laney kicks some ass
[15:57] <quadrispro> nhandler: ping
[15:57] <quadrispro> iulian: ping
[16:02] <Laney> the-dude: if you have a sponsor then Debian is easier
[16:02] <Laney> finding MOTU reviewers can be really hard
[16:02] <Laney> (plus we are in a freeze now)
[16:03] <Laney> ...also I think having a human responsible for each package is a massive win - we have a bit of a problem with fire-and-forget packagers sometimes
[16:07] <bdrung> dholbach: jippi
[16:09] <dholbach> bdrung: congratulations!
[16:09] <bdrung> thanks
[16:10] <bdrung> finally i can screw ubuntu up. ;)
[16:10] <highvoltage> bdrung: jus saw daniels mail. congrats!
[16:11] <bdrung> highvoltage: thanks
[16:24] <the-dude> Laney: so what would you suggest? wait for a while?
[16:25] <Laney> use your debian sponsor
[16:26] <the-dude> aight
[16:26] <the-dude> but then I won't get a @ubuntu alias ;)
[16:26] <sebner> bdrung: congrats :)
[16:27] <bdrung> sebner: thanks
[16:27] <Laney> the-dude: you can fix things in Ubuntu, but I really wholeheartedly recommend packaging *new* things in Debian
[16:27] <Laney> the majority of what we do applies equally over there anyway
[16:30] <the-dude> Laney: ok thanks, will get the package in sid then
[16:30] <Laney> good good
[16:36] <slytherin> Laney: Why do you think 'fire-and-forget' is not problem in Debian?
[16:39] <Laney> slytherin: I didn't say that. I think that having a named maintainer responsible for each package helps when problems come up though.
[16:40]  * directhex names Laney 
[16:40]  * Laney leaves the chamber :(
[16:41] <slytherin> Laney: Both methods have their own disadvantages. You can find many packages in debian not updated for long time with many bugs open because there is only one maintainer.
[16:42] <slytherin> I prefer Ubuntu method. It's disadvantages are lesser of the two evils IMHO
[16:42] <Laney> I don't think we're particularly good at handling our bugs in general
[16:43] <slytherin> well, I am not talking about all bugs, just bugs that arise out of packaging problems.
[16:43] <directhex> i want a median
[16:43] <directhex> every package should be "owned" by a team
[16:43] <ScottK> No way
[16:44] <directhex> individuals are blockers in debian, and motu si too large to give lovin' to everything in ubuntu
[16:44] <the-dude> so ubuntu packages don't have official owners?
[16:45] <directhex> no. in ubuntu everything is owned by everyone. comrade.
[16:45] <geser> directhex: "motu is too large"?
[16:45] <directhex> geser, i mean their remit. the number of things the motu people need to look after is too large
[16:45] <directhex> geser, too thinly spread
[16:46] <slytherin> directhex: MOTU is not too large. Number of packages owned bu MOTU are too large. MOTU team is too small to handle all that.
[16:46] <directhex> slytherin, that's what i meant. i phrased it badly
[16:47] <the-dude> so how does it work? anyone with access can just upload en new package if they feel like it?
[16:47] <directhex> right
[16:47] <directhex> ehm, i mean an *updated package* there
[16:48] <directhex> for brand new packages, yes they can go in directly for those with appropriate rights, but sometimes it's better to do the peer review thing via revu
[16:48]  * ScottK has always done so even though it's not required.
[16:49] <the-dude> hmm it sounds a bit weird
[16:49] <the-dude> sounds like something that could get messy
[16:50] <directhex> it tends to work. ish.
[16:50] <ScottK> It could, but we generally work as a team and communicate a lot when needed, so it rarely has problems.
[16:50] <slytherin> the-dude: Not when everyone is co-operative and no one goes into uploading packages at random without asking previous uploaders.
[16:50] <directhex> we're all one big huggy family!
[16:51]  * geser hugs directhex :)
[16:51]  * slytherin got to go
[16:51] <the-dude> it sounds to good to be true ;)
[16:52] <directhex> to an extent, what happens is a package doesn't *formally* have an owner, but there's an unofficial "who touched it last" thing where it ends up being considered as someone's "area of expertise". such that even though you can update it directly for something, you may just want to double-check with whomever touched it last over things they might be more knowledgable about
[16:52] <directhex> which works for me
[16:53] <Laney> I just think we need better processes for taking care of our local packages
[16:53] <the-dude> but do developers get access to all branches?
[16:53] <directhex> this is my package. there are many like it but this one is mine
[16:58] <geser> the-dude: what you mean with branches in the packages context?
[17:15] <the-dude> geser: development testing stable
[17:16] <the-dude> like jaunty en hardy en inteprid?
[17:18] <geser> for the development version any developer can upload
[17:19] <ScottK> Also true for stable release, just nothing gets accepted without archive admin approval.
[17:36] <ScottK> Someone who cares about Gnome might want to go through gnome-core-devel and remove obsolete (no longer in the archive) packages as it's currently uninstallable in Karmic
[17:48] <ScottK> I'd be willing to help a newcomer with this if they are interested in doing it.
[18:18] <jbernard_> ScottK: im happy to take a look
[18:18] <ScottK> jbernard_: Great.
[18:18] <jbernard_> ScottK: libeel2-dev needs to be removed
[18:18] <ScottK> jbernard_: At least.  Not sure what else.
[18:19] <jbernard_> ScottK: what is the workflow for making sure i've found them all?
[18:19] <ScottK> jbernard_: Are you on karmic?
[18:19] <jbernard_> ScottK: yep
[18:19] <jbernard_> ScottK: i suppose i could keep rebuilding the package without the missing depends
[18:20] <jbernard_> ScottK: until all can be resolved
[18:20] <jbernard_> ScottK: is there a better way?
[18:20] <ScottK> That or look up to see that the all still exist in LP or using rmadison would be the other choice.
[18:20] <ScottK> Neither one is particulalry appealing, but up to you
[18:21] <jbernard_> ok, ill take a look and see what i can come up with
[18:21] <ScottK> Great.  I have to run some errands in a bit, so if I don't respond to a ping, it's not because I'm ignoring you.  I do read the scrollback if I'm pinged.
[18:25] <ahe> i uploaded a package of a pure ruby application to my ppa and it was built fine and the packages platform is all but still on my ppa page it is shown under i386 build
[18:25] <ahe> is this normal or is there something wrong?
[18:26] <jacob> ahe: if the arch is "all" then they always seem to build on the i386 machines
[18:26] <jacob> just make sure that the output packages end in _all.deb and you should be fine
[18:27] <ahe> ah ok
[18:27] <ahe> thx, so everything is ok
[18:27] <jacob> yep
[18:38] <jbernard_> ScottK: just libeel2-dev
[18:38] <ScottK> jbernard_: Excellent.  Make a debdiff in a bug and ping me with the bug number.  I'll send it right up.
[18:39] <jbernard_> ScottK: im on it
[18:39]  * ScottK out for a bit jbernard_.
[18:46] <jbernard_> ScottK: bug #393834
[19:05] <RoAkSoAx> bdrung, congrats!!
[19:06] <bdrung> RoAkSoAx: dito
[19:06] <fabrice_sp> RoAkSoAx, congrats also to you!
[19:06] <fabrice_sp> bdrung, congrats :-)
[19:06] <RoAkSoAx> thanks fabrice_sp :)
[19:06] <bdrung> thanks
[19:07] <mfoster> hi folks, I have a question. If I have want to overlay a patchset (from a tarball) onto a package prior to building what's the right way to do that?
[19:07] <bdrung> mfoster: using a patch system
[19:08]  * RainCT ended up compeletely messing up his system (or maybe not, but anyway) and decided it's time to try out Debian for another week :P
[19:08] <mfoster> would I put the tarball into the patch folder and extract it in the rules file?
[19:08] <bdrung> cdbs'es simple-patchsys, quilt or dpatch
[19:08] <fabrice_sp> somebody willing to testbuild the fix in bug #427025 ? I've been able to build it in 2 different computers, but it's FTBFS to Daneil
[19:09] <RainCT> But Lenny feels outdated, how does one live in testing (eg. compared to a late Ubuntu alpha)?
[19:09] <fabrice_sp> or even upload it ;-) (after building it)
[19:11] <mfoster> let me rephrase my question a little. I have a tarball containing source code (not patches), how do I incorporate it into my package. The URL is http://www.grid.net.ru/nginx/upload.en.html (it's a 3rd party module for nginx)
[19:14] <bdrung> fabrice_sp: i test it now
[19:14] <fabrice_sp> cool thanks!
[19:15] <bdrung> mfoster: you can create a patch out of it
[19:16] <DktrKranz> hey RoAkSoAx, congrats!
[19:17] <sluimers> Hello, I've got a question, how do I get a screenshot in my package? You know, the one you see in the desciption of a package.
[19:17] <DktrKranz> sluimers: screenshots.debian.net
[19:17] <RainCT> sluimers: upload it to http://screenshots.debian.net/
[19:17] <RainCT> DktrKranz: *grrr* :)
[19:17] <DktrKranz> RainCT: slooooooooow :P
[19:17] <sluimers> thanks guys :)
[19:18] <RoAkSoAx> DktrKranz, thanks man :)
[19:18] <DktrKranz> so you don't need me to stress your packages anymore :P
[19:19] <bdrung> fabrice_sp: i get the same error like dholbach. i used pbuilder on amd64
[19:20] <RoAkSoAx> DktrKranz, haha :)
[19:21] <POX> fabrice_sp: fix for 427025 will be uploaded to Debian in ~15 minutes
[19:22] <DktrKranz> RoAkSoAx: you probably will on Debian side, but you're safe at least on Ubuntu :)
[19:23] <RoAkSoAx> DktrKranz, haha yeah. I actually have to get lekhonee into Debian xD
[19:23] <DktrKranz> whooops
[19:32] <fabrice_sp> bdrung, I've used sbuild on amd64 and pbuilder on i386. Strange. Anyway, I'll wait for the fix in Debian and request the sync then
[19:32] <fabrice_sp> thanks bdrung and POX
[19:32] <randomaction> fabrice_sp: it FTBFS, I get the same error as dholbach but on i386
[19:38] <Laney> RainCT: did you roll back those ubuntu-boot packages?
[19:39] <RainCT> Laney: Yeah, reverted them using a server CD in rescue mode, but then I got an error about /proc being a symlink. I've removed that now so maybe it'd work now, but I'll give Debian another try anyway :P
[19:39] <Laney> haha
[19:39] <Laney> I was hoping for a handy command to copy
[19:40] <RainCT> Laney: Heh. Same problem??
[19:40] <Laney> it's unbootable
[19:40] <Laney> sreadahead problems or something
[19:40] <RainCT> I understand how you feel... *g*
[19:41] <RainCT> Laney: well what I've done is just   sudo dpkg -i /var/cache/apt/archives/<previous package>.deb   inside a chroot
[19:41] <fabrice_sp> POX, do you mean the problem in pycryptopp or the problem in the build (KeyError:...)?
[19:42] <fabrice_sp> because the package was building fine yesterday, and it fails now
[19:43] <fabrice_sp> by the way, it's failing also now in my sbuild
[19:46] <POX> fabrice_sp: works fine with python2.6 from experimental
[19:47] <randomaction> could that be caused by new python packages in karmic?
[19:48] <fabrice_sp> surely: it was buillding yesterday, and it's failing today
[19:49] <blackxored> hi, I could probably spent some more time maintaining my packages as a MOTU in ubuntu, are you interested????
[19:51] <RainCT> blackxored: I'm not sure if I follow.. But, help is always welcome :)
[19:51] <blackxored> RainCT, probably focused the statement wrongly, so here it goes again
[19:52] <blackxored> I could probably use some of my time to contribute to ubuntu as well, initially syncing or merging my debian packages there, got it?
[19:52] <blackxored> on a regular basis
[19:53] <blackxored> and I was wondered if that could be useful, so, if you guys are interested
[19:53] <blackxored> s/wondered/wondering
[19:55] <fabrice_sp> blackxored, as stated RainCT, any help is welcome :-)
[19:55] <blackxored> fabrice_sp, fine then\
[19:55] <blackxored> although slytherin has taken this round
[19:55] <blackxored> I'll be up for the next one ;)
[19:56] <fabrice_sp> blackxored, did you subscribed to bug mail of your package?
[19:56] <blackxored> fabrice_sp, (s) yes
[19:57] <fabrice_sp> good starting point :-)
[19:57] <blackxored> fabrice_sp, I've been marking fixing bugs there
[19:57] <fabrice_sp> ok
[19:59] <blackxored> fabrice_sp, great then
[19:59] <fabrice_sp> also, do you know about the FTBFS page?
[20:00] <blackxored> fabrice_sp, sure
[20:00] <fabrice_sp> so you already know everything :-)
[20:00] <blackxored> fabrice_sp, far from that :D
[20:02] <fabrice_sp> :-)
[20:04] <blackxored> fabrice_sp, ok, back to work, glad to know i can contribute here too :D
[20:05] <fabrice_sp> thanks for your contributions :-)
[20:05] <fabrice_sp> (in advance ;-) )
[20:05] <bdrung> blackxored: have fun with digging through eclipse bug reports
[20:06] <blackxored> bdrung, hi, no that's nthykier's job :D hehehe
[20:06] <fabrice_sp> python2.6 has been updated yesterday, and I supect to be that upgrade the root cause of the new FTBFS
[20:06]  * fabrice_sp reports a bug againt pyton2.6
[20:06] <bdrung> blackxored: then you can digg through the vlc bugs :p
[20:07] <bdrung> fabrice_sp: sounds plausible
[20:07] <blackxored> bdrung, I love vlc :D
[20:07] <blackxored> bdrung, did you manage to fix the bug that prevents eclipse-platform from building???
[20:08] <fabrice_sp> bdrung, I've both logs, and it's the only difference (in term of versions)
[20:10] <blackxored> bdrung, ???
[20:11] <bdrung> yes
[20:11] <bdrung> it builds
[20:11] <blackxored> bdrung, ^^^^
[20:11] <blackxored> great, so that lets only eclipse left
[20:11] <bdrung> blackxored: do you like this bug list, too? https://launchpad.net/ubuntu/+source/vlc/+bugs
[20:12]  * blackxored has no comments about that list ;)
[20:13]  * blackxored thanks an entire bugsquad team should be created for that :D
[20:13] <bdrung> then have a look at the linux package: 5780 bugs
[20:14] <blackxored> bdrung, yes but that is sort of general
[20:14] <blackxored> bdrung, and thanks for the bug survey :D you almost made me cry
[20:15] <bdrung> blackxored: ubuntu has more users than debian and therefore more bug reports
[20:16] <blackxored> bdrung, yes I know, I'm one of them :D
[20:17]  * bdrung will now install karmic
[20:46] <ScottK> jbernard_: Looking.
[20:47] <ScottK> jbernard_: Generally I'd prefer to include why in debian/changelog and also close the bug in changelog too.  Care to fix it up or would you rather i  did?
[20:47] <jbernard_> ScottK: im on it
[20:47] <ScottK> jbernard_: Great.  Ping me again when ready.
[20:59] <jbernard_> ScottK: ok, that should be much better
[20:59]  * ScottK looks again
[21:00] <ScottK> Looks much better.
[21:00] <jbernard_> thanks!
[21:01] <fabrice_sp> Can some MOTU have a look at sync request in bug #416262 ? It would allow us to close most of the bugs in aptoncd.
[21:10] <ScottK> jbernard_: Uploaded.  Thank you for your contribution to Ubuntu.
[21:11] <ScottK> jbernard_: A couple of comments for you ....
[21:11] <ScottK> 1.  No need to edit both control.in and control.  If control.in is changed, control will get regenerated automatically.
[21:11] <ScottK> 2.  There's a new poilcy on maintainer, and all Ubuntu packages (Universe and Main) should now be Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
[21:12] <ScottK> I fixed the second one before I uploaded.
[21:12] <ScottK> jbernard_: Want another one?
[21:14] <jbernard_> ScottK: Re: #1, that is true but both control and control.in were present in the source so I figured I'd be thourough
[21:14] <ScottK> jbernard_: It doesn't hurt, but it's extra work.
[21:14] <jbernard_> ScottK: sure, whaddya got?
[21:14] <ScottK> jbernard_: Make gwp buildable.
[21:16] <jbernard_> ScottK: ill take a look
[21:16] <jbernard_> ScottK: how long before the new gnome-core-devel hits the archive?
[21:16] <ScottK> Likely an hour and a half for fast archs.
[21:17] <jbernard_> ok, lemme see what i can come up with
[21:18] <ScottK> jbernard_: It's about built on i386: https://launchpad.net/ubuntu/+source/meta-gnome2/1:2.22.2~4ubuntu7/+build/1238038
[21:18] <ScottK> So publisher run starts at :03 and finishes ~:45, so ~2145 UTC.
[21:51] <jbernard_> ScottK: with gnome-core-devel in incoming, gwp builds successful
[21:52] <jbernard_> ScottK: ive got version 0.4.0-1.2
[22:36] <segler> hello, i programmed a rhythmbox plugin, and i want it to get into universe. i uploaded it to revu. but it says to me, that i should use another maintainer e-mail address. something with  @ubuntu.com. what should i do? which adress is the right one?
[22:45] <jbernard_> segler: i believe the maintainer field should be: "Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>"
[23:13] <soren> How many release team members need to ACK an FFe?
[23:14] <arand> Does Hardy handle the ~ in package vsersion differently? Since I have a Hardy box where it prefers *-0ubuntu1.1 over *-0ubuntu1.1~arand-* ¤ Whereas on intrepid, it prefers *-0ubuntu2.1~arand-* over *-0ubuntu2.1
[23:14] <Laney> arand: do some dpkg --compare-versions experimentation
[23:19] <arand> Laney: oh, nvm, it was the right way around on hardy, /me is blind.
[23:20] <Laney> soren: always was 2 previously
[23:20] <Laney> related, do release teams need to ack removals? I guess yes
[23:21] <soren> Laney: I see. I couldn't find that mentioned anywhere on the wiki.
[23:21] <soren> It's a big wiki, though. I may have missed it.
[23:22] <Laney> soren: https://wiki.ubuntu.com/FreezeExceptionProcess#Exceptions%20for%20Universe/Multiverse
[23:22] <soren> Laney: Oh, there it is.
[23:23] <soren> Laney: Ah, no, that's for new upstream versions.
[23:23] <soren> Laney: This is a new package.
[23:23] <Laney> I don't know why it always talks about new upstream releases
[23:23] <soren> Anyhow, if a friendly motu-release team member would be so kind to give bug #427581 a quick glance, it would be much appreciated.
[23:23] <Laney> I think it's the policy for all FFes
[23:23] <Laney> but what do I know!
[23:23] <soren> Laney: Possiblu.
[23:23] <soren> Bah.
[23:23] <soren> Possibly, even.
[23:24] <soren> Blimey, that's a long list! https://bugs.edge.launchpad.net/~motu-release/+subscribedbugs
[23:26] <Laney> motu-release: please make the page clearer :)
[23:31] <chrisccoulson> i take it that motu-release need to ACK package removals too?
[23:33] <Laney> trying to find out
[23:33] <chrisccoulson> Laney - thanks. Did I ask you a similar question earlier? sorry if I already did - it's been a busy day ;)
[23:43] <segler> please motu team, comment on my small rhythmbox plugin i uploaded http://revu.ubuntuwire.com/p/rhythmbox-radio-browser
[23:47] <Laney> chrisccoulson: You mentioned it, and I'm interested in finding out the answer too