[00:49] <dtchen_> anyone around for a quick mplayer upload to fix bug 482408?
[00:49] <dtchen_> afterward should be SRU-able to 9.10, too
[00:50]  * jdong will bite :)
[00:50] <dtchen_> jdong: thanks!
[00:51] <jdong> err...
[00:51] <jdong> siretart: how would you like to handle the pkg-multimedia-ness of mplayer?
[01:01] <mannyv> if i request a sync for a package in main on LP is there anything else I need to do to get someone to look at it?
[01:04] <micahg> mannyv: might be easier to use the requestsync tool
[01:06] <ari-tczew> mannyv: would be nice if you'll do build test
[01:07] <mannyv> micahg, I did use requestsync
[01:07] <mannyv> ari-tczew, I did test build and test install
[01:07] <ari-tczew> yhym ok
[01:08] <mannyv> i was wondering if afterwards i just wait for someone to come along and sync it or if i have to do something else to get someone to notice it
[01:09] <mannyv> i havent been around long but i used to be serialorder then i decided to follow suit and just use my real name =)
[01:10] <ajmitch> dtchen_: let's hope you get your core-dev upload rights back soon :)
[01:10] <dtchen_> I applied; I'm awaiting development membership board's say
[01:10] <ajmitch> I don't think there should be too many objections
[01:11] <dtchen_> well, status quo won't change anything. It's unlikely that bugs will stop flowing in or that I'll stop fixing them regardless whether I can upload. :-)
[01:11] <ajmitch> no, it just makes things smoother for you
[01:11] <ajmitch> you've done an impressive amount of work :)
[01:12] <dtchen_> I wish I didn't have to blog every time someone writes something daft. :/
[01:13] <ajmitch> there seems to be a lot of annoyed & confused people around
[01:13] <ajmitch> I didn't know that MOTUs had so much power :)
[01:17] <dtchen_> I know seb128 replied to the first post the first time this whole crack came about (https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2009-October/009541.html), but I guess that was lost on many people, too :/
[01:30] <EzraR> whats the command to look at a dsc and show what gets installed and what it contains etc...
[01:35] <micahg> mannyv: nope, I believe that's it
[01:46] <micahg> is this still correct: https://wiki.ubuntu.com/UbuntuDevelopment/FAQ#I%20need%20to%20fix%20a%20bug%20in%20the%20upstream%20provided%20source,%20modify%20the%20source%20or%20add%20a%20patch?
[01:48] <nhandler> micahg: Yeah, it looks correct. Although, it could be expanded on a little more
[01:48] <micahg> ok, I should have specified, I was wondering about the part about modifying the source
[02:01] <jgoppert> #join ubuntu
[02:02] <jgoppert> sorry about that
[03:34] <LucidFox> http://brainstorm.ubuntu.com/idea/2073/
[03:35] <LucidFox> ^ I bet most people who downvoted this did it just because it's Mono.
[03:50] <ajmitch> LucidFox: that one's been talked about a bit
[03:50] <LucidFox> I know. :)
[05:18] <fabrice_sp> porthose_, there? About bug #484678
[06:58] <AnAnt> Hello, could someone help me with this wierd build failure: https://launchpad.net/~aelmahmoudy/+archive/ppa/+sourcepub/871610/+listing-archive-extra
[06:58] <AnAnt> it builds for i386 only
[07:39] <LucidFox> AnAnt> The i386 build does binary while the amd64 build does binary-arch
[07:39] <AnAnt> LucidFox: huh ?
[07:40] <AnAnt> LucidFox: so ?
[07:40] <LucidFox> The amd64 build doesn't build the binary-indep package, and the builder tries to access a file resulting from building the pcb-common package.
[07:40] <AnAnt> why is that different behaviour ?
[07:41] <LucidFox> Binary-indep packages are built only once, since there is no need to build them on every architecture
[07:41] <AnAnt> so, does the package needs fix or what ?
[07:41] <LucidFox> http://paste.ubuntu.com/322218/
[07:42] <LucidFox> Yes, you need to fix the binary-arch phase so that it doesn't need files from debian/pcb-common in the arch-dependent package.
[07:43] <LucidFox> Let me look at debian/rules
[07:43] <AnAnt> ok, please do
[07:45] <LucidFox> Oh, nice, I wasn't aware of these override_dh_* makefile rules.
[07:47] <AnAnt> LucidFox: dh 7 !
[07:47] <LucidFox> You need to ensure that what's written in override_dh_fixperms only executes for dh binary-arch, not dh binary-indep.
[07:47] <LucidFox> I know :)
[07:48] <AnAnt> dh_fixperms -i would do the trick ?
[07:49] <AnAnt> hmm, nope
[07:50] <AnAnt> how to do that ?
[07:50] <LucidFox> The problem is not with dh_fixperms
[07:51] <LucidFox> We could eschew override_dh_fixperms and modify the binary-arch rule explicitly, but I'm hoping for a cleaner solution
[07:52] <LucidFox> Apparently there's no way. Hmm...
[07:53] <LucidFox> Well
[07:56] <AnAnt> thanks for help
[07:57] <AnAnt> LucidFox: could it be by checking wether debian/pcb-common exists or not before doing the chmod ?
[07:57] <LucidFox> You could do that, too!
[07:59] <LucidFox> [ ! -d debian/$(package)-common ] || chmod <....>
[08:19] <AnAnt> btw, anyone interested in testing texlive 2009 ?
[08:22] <LucidFox> AnAnt> I am
[08:22] <LucidFox> I want it for an updated xetex.
[08:23] <AnAnt> ppa:aelmahmoudy/tl2009
[08:24] <AnAnt> it's sync'ed from Debian's experimental
[08:26] <siretart`> AnAnt: cool! thanks!
[08:27] <AnAnt> I hope it will be in lucid !
[08:28] <siretart`> AnAnt: I would support syncing it early in lucid to get maximum testing done. and we really do not want to have a tex from 2007 in a LTS release
[08:31] <LucidFox> YES
[08:31] <AnAnt> siretart`: you mean file sync request from experimental ?
[08:31]  * LucidFox adds the PPA
[08:32] <LucidFox> My "other software" tab in Software Sources now contains 11 external sources, all PPAs.
[08:32] <siretart`> AnAnt: perhaps in parallel with a discussion on the mailing list
[08:32] <LucidFox> At this rate, it will be Karmic in name only.
[08:33] <siretart`> oh, the ppa has no packages for lucid. :-( - well, I guess the karmic package should do fine as well
[08:35] <AnAnt> siretart`: I'm still using karmic
[08:36] <hyperair> LucidFox: i've got 19 ;-)
[08:37] <LucidFox> AnAnt> http://paste.ubuntu.com/322240/
[08:37] <AnAnt> oh !
[08:37] <AnAnt> because I appended ~ to versions
[08:38] <AnAnt> ok, I think there is no need to append this ~, right ?
[08:39] <LucidFox> You can relax the dependencies
[08:39] <LucidFox> >= 2009-0?
[08:41] <siretart`> or just >= 2009
[08:42] <siretart`> aptitude is having troubles to install any of those packages, it seems..
[08:42] <LucidFox> How do I make dh_auto_clean use make clean rather than make distclean?
[08:42] <AnAnt> LucidFox: override_dh_auto_clean
[08:42] <LucidFox> Yes, I know, but does it execute anything other than make distclean?
[08:43] <AnAnt> I don't think I understand the question
[08:43] <AnAnt> override_dh_auto_clean:
[08:43] <siretart`> have you looked at the source? It's perl, but the scriptless are rather short...
[08:43] <AnAnt>   make clean
[08:43] <AnAnt> siretart`: source of texlive ?
[08:44] <siretart`> no, that was for LucidFox
[08:47] <AnAnt> if I got dsc,orig & diff.gz files already, can't I just generate a source.changes file for them ?
[08:48] <geser> you can, unpack the source and run dpkg-genchanges inside the package dir
[08:50] <LucidFox> Actually, the problem was elsewhere, as it turned out.
[08:50] <LucidFox> dh_auto_clean does invoke make clean if make distclean isn't possible.
[08:51] <LucidFox> But apparently CDBS's makefile.mk just ignores errors, while dh_auto_clean doesn't ignore them if the makefile exists.
[08:51] <AnAnt> yes, that's true
[08:51] <AnAnt> oh, CDBS
[08:51] <AnAnt> dunno about that
[08:51] <LucidFox> This is why the clean rule broke in the transition from CDBS to dh 7.
[08:51] <LucidFox> Basically, there's an upstream custom-written makefile that invokes an autogenerated makefile in src, unconditionally.
[08:52] <LucidFox> Need to file an upstream bug about that, but for now, [ ! -f src/Makefile ] || dh_auto_clean
[08:54] <LucidFox> I really like the override commands, they allow to transition from CDBS seamlessly in many cases.
[09:06] <AnAnt> LucidFox: the fix worked, thanks !
[09:15] <LucidFox> AnAnt> By the way
[09:15] <LucidFox> you can also use >= 2009~
[09:15] <LucidFox> er
[09:15] <LucidFox> >= 2009-1~
[09:16] <AnAnt> LucidFox: why not just upload the correct version ?
[09:17] <LucidFox> Well, using the same version number in PPAs as in official archives is a Bad Thing(tm)
[09:17] <AnAnt> I thought it is a bad thing to do so BEFORE release
[09:17] <AnAnt> but after ?
[09:18] <Laney> you should make sure that users get automatically upgraded to the primary archive package if one is forthcoming
[09:20] <AnAnt> hmmm
[09:20] <AnAnt> well, I started uploading already
[09:20] <AnAnt> delete & repeat again ?
[09:28] <SevenMachines> hi there, i was wondering if someone could have a quick look at something ifupdown-scripts-zg2 0.3-4 in karmic for me? All i'm trying to do is rm debian/ifupdown-scripts-zg2.dirs but dpkg-source is ignoring deletion of it so it doesnt show up in the debdiff. does someone know the reason? i could leave the file empty instead but i was curious
[09:29] <SevenMachines> http://paste.ubuntu.com/322269/
[10:04] <geser> is the .dirs file perhaps in the orig.tar.gz and not in the .diff.gz?
[10:06] <SevenMachines> thanks geser, its obvious now! the orig tarball has the debian directory, i thought that was not supposed to be in there?
[10:07] <geser> it's preferable if it's not there but sometimes it is
[10:09] <SevenMachines> is the best method here just to remove the entries from the .dirs and leave the empty file in place?
[10:18] <geser> in this case yes (or you could rm it in the clean target
[10:20] <LucidFox> I think it's best to repack the upstream tarball to remove the debian directory from there.
[10:20] <LucidFox> And file an upstream bug report about it.
[10:24] <DktrKranz> with format 3.0 (quilt), this is no longer necessary
[10:25] <LucidFox> Ubuntu doesn't support it yet, though.
[10:25] <LucidFox> Or rather, LP doesn't.
[10:25] <LucidFox> AnAnt> I see you uploaded pcb to m.d.n too, great!
[10:25] <DktrKranz> it's WIP, and I read it will be available in two/three weeks
[10:25] <AnAnt> LucidFox: yeah
[10:26] <LucidFox> DktrKranz> Excellent news, I'll migrate my packages to the new format when support lands.
[10:26]  * DktrKranz too, at least some of them
[10:27] <DktrKranz> with new format, packages which requires some patching hacks will benefit a lot
[10:27] <SevenMachines> would removing the entry in .dirs to fix for now and filing a debian bug for repackaging be ok? since lucid will be syncing for a while
[10:28] <geser> LucidFox: I don't think it makes sense to repack an .orig.tar.gz which is already in Debian (and Ubuntu) just to get rid of the debian dir within
[10:28] <LucidFox> :)
[10:31] <SevenMachines> i noticed 3.0 allowed --include-removal option to dpkg-source, that would have made me happy
[10:46] <LucidFox> When I have multiple language versions of a document in subdirectories, should I only register en with doc-base, or all of them?
[12:07] <LucidFox> Is there any way to get sponsorship requests in feed form?
[12:12] <siretart`> LucidFox: IIRC launchpad offers the bug lists as rss feed, doesn't it?
[12:14] <LucidFox> Well, I'd like to receive a notification via RSS/Atom when someone subscribes ubuntu-universe-sponsors.
[12:19] <LucidFox> siretart`> So what's our stance on debian-multimedia.org? Historically some of our packages have been merged from it, are we going to move away from it?
[12:23] <siretart`> LucidFox: well, I can only suggest to very very carefully inspect before touching anything from marillat
[12:23] <siretart`> LucidFox: that site is a one-man show, who doesn't give a sh*t about licensing, compatibility with anything but his own systems, debian/rules or debian/copyright cleaness, etc
[12:24] <siretart`> the only plus: he has an impressive amount of interesting packages
[12:24] <LucidFox> I know about all that. :)
[12:25] <siretart`> LucidFox: if you ask me directly, I'd suggest maintain the packages independently
[12:26] <LucidFox> And to be fair, for some packages, merging them is 95% applying existing Ubuntu changes for cleanliness from version to version.
[12:26] <LucidFox> He refuses to repack the qdvdauthor upstream tarball to remove binaries, for example.
[12:27] <siretart`> so it seems to me that merging from him doesn't seem to help much
[12:28] <LucidFox> Except for new packages.
[12:28] <LucidFox> And I'm considering joining the debian-multimedia team, although I have no experience with package development using a VCS.
[12:29] <siretart`> oh, sending in debdiffs is great as well, you don't really have to learn git if you don't want to :-)
[12:30] <LucidFox> I've worked with git before, just not in conjunction with Debian packages.
[12:32] <siretart`> git-buildpackage is really helpful here. it feels like debuild with a few extra options
[13:02] <LucidFox> Any reason mjpegtools is in multiverse?
[13:03] <siretart`> I wondered about that as well, but didn't investigat the sources yet deeply. given that we promoted x264, we can maybe promote it.
[13:04] <LucidFox> And it's not in Debian because of patent issues?
[13:06] <siretart`> LucidFox: since debian's ftpmaster currently seem to want to remove all of ffmpeg, I didn't really feel like finding out what they might or might not do with mjpegtools
[13:07] <LucidFox> Remove ffmpeg? Why?
[13:07] <LucidFox> Patent issues?
[13:07] <siretart`> yes
[13:16] <LucidFox> What's the purpose of packages in git that aren't in Debian itself?
[13:45] <siretart`> either for ubuntu, or debimedia.
[13:45] <siretart`> debimedia is (at least its supposed to be) an repository with the 'missing bits'
[15:34] <bddebian> Heya gang
[15:34] <siretart`> hey bddebian!
[15:35] <bddebian> Heya siretart
[15:37] <iulian> Hi bddebian.
[15:39] <bddebian> Hi iulian
[15:46] <\sh> emgent, ping... your exploit thingy where do I find more informations?
[15:57] <emgent> \sh: ola, i reply to you on FB:)
[16:12] <emgent> \sh: check again :)
[16:14] <\sh> emgent, somehow like mod_security?
[16:19] <emgent> no really
[16:19] <emgent> it`s a service-product
[16:19] <emgent> we send via webapps all updates, user can delegate all to us
[16:19] <emgent> also, we are more aggressive to mod_security
[16:19] <emgent> and we can manage rules per domain
[16:20] <emgent> also in 2010 you will see the jesys appliance ;)
[16:22] <emgent> \sh:
[16:23] <sproaty> I've already got my program packaged in a PPA, so I just submit a [needs packaging] bug for it?
[16:23] <\sh> emgent, I hope those appliances can be scaled horizontally ;)
[16:33] <sproaty> I want to get my package into ubuntu, but I don't know if it's good enough
[16:34] <cyphermox> sproaty, you should file a [needs-packaging] bug, assign it to yourself, and upload it to revu
[16:35] <sproaty> but how about measuring the quality of the app? It's pretty functional, even at a 0.39 release, but I've been working on it for over a year
[16:35] <cyphermox> sproaty, is this an app you wrote yourself?
[16:35] <sproaty> yes
[16:35] <sproaty> I have it in the ppa
[16:37] <cyphermox> sproaty, REVU will allow MOTU to look at your *package*, and see if it's in order, it's less about the overall functionality of the software in it (as long as it's not completely broken)
[16:37] <sproaty> well the package should be good, it's just some source python - real simple
[16:37] <cyphermox> the quality of the software itself is your responsibility, wrt being the package maintainer (the one to get the bugs from Ubuntu), and the upstream maintainer :)
[16:38] <sproaty> ah right
[16:38] <cyphermox> so if you have users for your program, and it's something that can reasonably be added to the archives, there shouldn't be too much of an issue
[16:38] <sproaty> I just thought they may have some policy against pretty active development, like I've released 4, 5 versions over the past month
[16:39] <sproaty> cool, I've got around 5000 downloads so far, with a few people talking to me about the program, so I guess it's functional enough :D
[16:39] <cyphermox> what I mean by reasonably added is that it serves a real purpose, and if something similar already exist, maybe it does something more, or different, that is really good
[16:41] <sproaty> it's nothing special, sort of an image editor, but not -exactly- pixel-based, since you can draw shapes, and move/edit these shapes (rather than pixels)
[16:41] <sproaty> but I'll file it, and see what happens :)
[16:41] <adama> i've not been brave enough to attempt to package my app yet
[16:42] <adama> seems somewhat complicated :$
[16:43] <sproaty> I found it really simple
[16:43] <sproaty> only problem is I keep re-creating my package from scratch and not .diff from the previous release
[16:43] <adama> i've got to interact with dbs and stuff, that's the bit which seems complex
[16:44] <cyphermox> sproaty, perhaps then you should consider using bzr or something similar to keep your packaging
[16:44] <adama> will probably copy the cacti package at some point, that seems to do pretty much the same
[16:44] <sproaty> I use bzr, but for my code -- in what context do you use it for a package?
[16:45] <cyphermox> sproaty, you could keep a different branch that holds just the debian/ directory, then make your changes in there, each change in its revision, so you have history
[16:46] <sproaty> ah right
[16:46] <sproaty> but say I've build ppa-1 with debuild -S, as I do
[16:46] <sproaty> that always asks me about "something something no diff.gz file found"
[16:46] <sproaty> so surely there's a way for me to build the new package, ppa-2 against what's already in ppa-1?
[16:47] <cyphermox> sproaty, do you keep a debian/ directory in your source?
[16:47] <sproaty> no, since it's cross-platform
[16:50] <sproaty> ugh, I have to run. Shame, I want to get this done
[16:50] <sproaty> sorry to leave it half-done
[17:12] <vadi2> How does synaptic manage pinning? I just ran into a bug with it and I can't unforce a package version.
[17:13] <joaopinto> vadi2, better ask mvo :P
[17:13] <vadi2> mk
[17:13] <vadi2> he's not on
[17:41] <fahadsadah> Hi
[17:41] <fahadsadah> How would I do an upstream merge with debian?
[17:42] <fahadsadah> I seem to remember reading something about it in the wiki, but I can't find it now
[17:42] <Arc> how should I file a bug about a debian library package not including the pkg-config file for itself?
[17:43] <Arc> upstream includes it, it was not packaged to install though
[17:43] <LucidFox> fahadsadah> Start with the Debian version, examine the Ubuntu changes and apply them.
[17:43] <LucidFox> Attach the diff.gz for the merged version to LP when ready.
[17:43] <Laney> NO!
[17:43] <Laney> not for a merge, attach the debdiff(s)
[17:44] <LucidFox> Oh, right!
[17:44]  * LucidFox facepalms
[17:44] <LucidFox> Attach the debdiff against the debian version.
[17:45] <Arc> is that to me?
[17:45] <LucidFox> diff.gz is for upstream updates within Ubuntu.
[17:45] <LucidFox> Arc> No, towards fahadsadah and Laney.
[17:45] <Arc> ah
[17:46] <fahadsadah> Thanks
[17:47] <fahadsadah> If the Ubuntu delta can be dropped, do I just get the package from Debian?
[17:47] <Laney> yes, that's called a sync
[17:48] <sladen> fahadsadah: you don't do a fresh upload, but order it via the bug-tracker
[17:50] <Arc> nevermind.  the debian package is messed up beyond our ability to use it anyway
[17:51] <Arc> when our app gets packaged it'll have to be bundled with a static copy to avoid getting broke by debian-games team next time they decide to mess with upstream's defaults
[17:52] <Laney> what?
[17:52] <Laney> why don't you take your issues up with the games team?
[17:52] <Arc> oh this has been going around and around
[17:52] <Arc> libode gets built quite often for debian with double precision, which makes it too slow for games
[17:52] <Arc> but whoever at debian "owns" the package doesn't care
[17:52] <Laney> why is it ok for debian but not ubuntu?
[17:53] <Arc> so all the packages that use ODE as a dep end up having to package their own version of ODE
[17:53] <sladen> Arc: wuhhhhh woah!
[17:53] <Arc> I hold Ubuntu members to higher standards ;-)  debian I gave up on years ago.
[17:54] <sladen> Arc: if there's an issue in the Debian package, fix it---and static copies *are not allowed*
[17:54] <Laney> I hope you don't find much support for that here
[17:54] <Laney> you should fix it in Debian
[17:54] <Arc> then we won't be able to package
[17:54] <sladen> *blink*
[17:54] <Arc> until they stop building it with non-default upstream flags it's unusable
[17:54] <fcuk112_> packaging a new upstream release, some patches are still applicable but the line numbers of the changes have changed; do i need to recreate those patches or is quilt smart enough to locate the correct section of code in the file?
[17:55] <Arc> ode-config --cflags
[17:55] <Arc> -I/usr/include -DdDOUBLE
[17:55] <Arc> double precision is non-default and too slow for games, it's only recommended for scientific applications
[17:55] <sladen> Arc: you mean the software you're using is badly written and relies on hard-coded floating point lengths--and is probably going to fail with endian issues too?
[17:56] <Arc> sladen: no I mean that double precision is too slow so we don't support it.
[17:56] <sladen> fcuk112_: fix the patches so that they reliably apply cleanly
[17:57] <sladen> Arc: so it's got *nothing* to do with packing, merely a (likely misguided) belief and 32-bit floats are going to be faster
[17:57] <sladen> packaging
[17:57] <sladen> s/and/that/
[17:57] <fcuk112_> sladen: ok, thanks.
[17:57] <Arc> you believe that double is as fast as float?
[17:58] <sladen> Arc: ever heard of the phrase "premature optimization"
[17:58] <Arc> sladen: you're a debian packager aren't you?
[17:59]  * adama looks at sladen 
[18:00] <sladen> Arc: Ubuntu *is* Debian;  I think you'll find quite an overlap, and a strive to fix issues at the source
[18:00] <Arc> the hubris has exposed you :-P
[18:00] <sladen> what's the piece of software in question?
[18:00] <Arc> no, Ubuntu is not Debian.  Ubuntu is a separate and distinct project which builds up from Debian
[18:01] <Arc> libode1 and libode-dev are in question
[18:01] <adama> Arc: in much the same way that a steak *IS* beef? :>
[18:02] <Laney> we are universe and universe is debian
[18:02] <Arc> that's a disappointing viewpoint.
[18:04] <sladen> standing on the shoulders of giants is how technological advances are made is realistic amounts of time
[18:04] <sladen> everyone is free to re-invent the wheel, but clever people try not to
[18:04] <Arc> Ubuntu standing on Debian's shoulders != (Ubuntu == Debian)
[18:04] <sladen> Arc: so what's the broken piece of software that you're trying to link against libode?
[18:05] <Arc> anyways, back to real work
[18:05] <Arc> this issue will obviously have to wait until MOTU is disbanded
[18:05] <sladen> Arc: if I invent something, and then invent an improved version, who's shoulders am I standing on?
[18:14] <sladen> anyone know who "Arc" was---seems an interesting bit of outreach to follow-up on, even if we scared them away
[18:16] <Laney> he seems to still be connected
[18:16] <Laney> seems like a disappointing viewpoint
[18:25] <StevenK> \sh: So, do we want fai back in the archive? It was removed from Karmic, but it wasn't blacklisted
[18:42] <fabrice_sp> emgent, what happened with bug 279755 ?
[18:53] <fcuk112_> http://www.pastie.org/706305 when i do a test install of the deb, it fails because of the depencies, but the dependencies are specified in the debian/control file - what is wrong here?
[18:54] <Laney> fcuk112_: dpkg doesn't install dependencies
[18:54] <Laney> do apt-get -f install
[18:56] <fcuk112_> Laney: ok, thanks.
[18:57] <fabrice_sp> or use gdebi
[19:04] <fabrice_sp> porthose_ ?
[19:19] <ari-tczew> fabrice_sp: is it true, that new packages in Debian will sync automatically into lucid until end of DebianImportFreeze?
[19:19] <ari-tczew> no new versions, but new packages
[19:39] <fabrice_sp> yes
[19:40] <fabrice_sp> *gone
[20:43] <StevenK> ScottK: Here?
[20:43] <ScottK> StevenK: Yes.
[20:44] <StevenK> ScottK: Is it worthwhile autosyncing boost1.39 from Debian?
[20:44] <ajmitch> no
[20:44] <ScottK> StevenK: We can't sync boost due to Python differences and we'd drop it anyway.  I'd say no.
[20:45] <StevenK> Okay, I'll kick it from the current run. Shall I blacklist it too?
[20:45] <ajmitch> boost1.40 is being fixed in debian to sort similar python issues so might be syncable in the near future
[20:46] <StevenK> Well, when I say blacklist I mean boost1.39
[20:46] <ajmitch> I think 1.39 will disappear soon enough, but I think there are apps that may still need fixed to work with a newer version, sadly
[20:47] <StevenK> Meh, blacklisting is cheap
[20:47] <ajmitch> there's a removal request for boost1.39 in debian, so probably blacklist for now
[20:53] <StevenK> Heh, right
[20:53]  * ajmitch wishes the BTS would hurry up & show me the bug
[20:53] <StevenK> No bug for you
[20:53] <ajmitch> :(
[20:53] <ajmitch> and there it goes
[20:54] <ajmitch> just looking up http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=556924 for your viewing pleasure
[20:59] <porthose_> fabrice_sp, I left a comment on bug #484678.  Please have a look when you have time.  ty :)
[21:16] <fabrice_sp> porthose_, I saw.. But isn't it worth syncing now, to get autosync after?
[21:16] <fabrice_sp> thanks for your comment, by the way
[21:17] <fabrice_sp> some archive admin: what about bug 483813?
[21:18] <fabrice_sp> experimental is allowed?
[21:18] <ajmitch> allowed, but some explanation is usually appreciated I think
[21:18] <ajmitch> I don't know where the current schroot is from (and I'm not an archive admin) :)
[21:18] <fabrice_sp> testing, IIRC
[21:19] <fabrice_sp> !info schroot | karmic
[21:25] <ScottK> fabrice_sp: Syncing from experimental particularly needs justification for Lucid since we are by default taking from Testing and not Unstable.
[21:25] <fabrice_sp> ScottK, ok. I'll request justifications in the sync request then. Thanks!
[21:28] <etaliverto> Hi all, I'm trying to make a package, but I'm having trouble with the debuild stage - it's failing with "secret key not available". I've set my key in devscripts.conf so I'm rather lost....
[21:29] <fabrice_sp> etaliverto, this error does not prevent your pacakge to be built
[21:29] <etaliverto> Any pointers for troubleshooting would be much appreciated. I'm new to this, been following the wiki but I've ended up with four keys in my secring.gpg so I'm not sure I did everything right.
[21:31] <etaliverto> •fabrice_sp• Thanks - can I upload it to REVU unsigned though? I was trying to update an existing package for a bug report.
[21:31] <av`> etaliverto, use -k flag
[21:31] <fabrice_sp> ohh. For REVU, it has to be signed
[21:32] <etaliverto> •av`• OK, thanks, I'll try with the flag....
[21:32] <av`> etaliverto, use -kKEYID
[21:33] <fabrice_sp> etaliverto, also, what is your changelog entry?
[21:35] <etaliverto> I made the changelog with dch -i, it gives my name and email address on the last line - they're the same ones as used when I made the GPG key
[21:36] <etaliverto> •av`• It works with the -k flag, thanks!
[21:36] <av`> etaliverto, np ;)
[21:36] <etaliverto> Any idea why it doesn't work through debuild though?
[22:32] <maco> jdong: motu sru? Bug #369818
[23:06] <sproaty> hi, I've created a needs-packaging bug, assigned it myself, but how do I "upload it to revu"
[23:12] <lucas> if the only ubuntu diff is "add lpia to supported archs", is it worth doing the merge, or can I sync?
[23:12] <lucas> lpia is going away for lucid, right?
[23:13] <StevenK> lucas: Sync!
[23:13] <lucas> thanks
[23:17] <sproaty> ah boo, gotta upload to revu from my linux box