[00:01] <Elbrus> Laney: the page say: (last edited 06.08.2008 11:00:40 by localhost)
[00:01] <Elbrus> is that when you mark the minor changes box?
[00:01] <pangloss> Laney, the same guide is located here: https://wiki.ubuntu.com/PackagingGuide/Complete
[00:02] <Laney> Elbrus: No, the page is a bunch of includes and I edited one of those, that's probably why
[00:02] <pangloss> down in the Updating a package  recipe
[00:02] <Elbrus> ah.
[00:02] <pangloss> Laney, so idk, if you have to change both of them
[00:03] <Laney> pangloss: Not that one, but there are other calls too
[00:04] <pangloss> o ok
[00:05] <crimsun> jdong: RE your pa_tls_set() error, which version were you using?
[00:10] <gouki> How do I tell pbuilder to use the ubuntu name scheme for building packages? If it's even that way.
[00:11] <Hobbsee> er...ubuntu naming scheme for building packages?
[00:11] <ajmitch> gouki: what do you mean?
[00:11] <gouki> Hobbsee, yes.
[00:11] <gouki> I mean ..
[00:11] <Hobbsee> which is?
[00:12] <nhandler> gouki: The package will get built with the correct name if the version in debian/changelog is correct
[00:13] <gouki> When I launch pbuilder create *.dsc, it creates the package with the following name: hydra_5.4-1_i386.deb
[00:13] <ajmitch> as nhandler says, the version number is controlled by debian/changelog
[00:13] <ajmitch> as is the distribution that the upload is targetting
[00:13] <nhandler> gouki: What version do you have in debian/changelog?
[00:14] <ajmitch> you will need to rebuild the source package to regenerate the .dsc file that pbuilder looks at
[00:14] <gouki> 5.4-1, nhandler
[00:14] <gouki> ajmitch, but I was under the impression that the name contained 'ubuntu'.
[00:15] <nhandler> gouki: The version should be 5.4-1ubuntu1
[00:15] <gouki> nhandler, and that is changed on the changelog?
[00:15] <ajmitch> pbuilder doesn't change versions at all
[00:16] <gouki> ajmitch, I see. I didn't thought about changing it on changelog :S
[00:16] <nhandler> gouki: If you use 'dch -i' it will take care of creating a new changelog entry for you with the correct version
[00:16] <gouki> nhandler, ok! I'll try that.
[00:16] <gouki> Thank you all!
[00:16] <nhandler> You are welcome gouki
[00:17] <gouki> Ohh, got it.
[00:17] <Hobbsee> nhandler: well, it's almost always correct.  Sometimes it isn't.
[00:17] <nhandler> Very true Hobbsee
[00:17] <gouki> The changelog was created when I ran dh_make. Should I delete the entry it created and just leave the one made by dch?
[00:18] <nhandler> gouki: Is this a new package that isn't in the repositories yet?
[00:18] <gouki> nhandler, yes, it is.
[00:19] <nhandler> gouki: What is the upstream version of the package?
[00:19] <ajmitch> right, changelogs made by dh_make target debian unstable, so you'll want 5.4-0ubuntu1
[00:19] <gouki> 5.4, nhandler
[00:19] <nhandler> gouki: Ok, so the version in your changelog should be '5.4-0ubuntu1'
[00:19] <gouki> ajmitch, OK! Got it. Thank you.
[00:19] <nhandler> gouki: You should also target 'jaunty' instead of unstable
[00:19] <gouki> nhandler, but that is done manually, correct?
[00:20] <Hobbsee> no
[00:20] <Hobbsee> you need to write that in your changelog.
[00:21] <gouki> Hobbsee, OK.
[00:21] <gouki> Think I got it! :)
[00:23] <gouki> But as for the debian-related entry on debian/changelog, I should delete it?
[00:23] <Hobbsee> yes
[00:23] <gouki> OK. Thank you all very much!
[00:24] <porthose> hey folks :)
[00:25] <nhandler> Hi porthose
[00:36] <gouki> Is there a way to test the package and force it to install the 'Recommends:' packages?
[00:37] <nhandler> gouki: Recommended packages are installed by default in intrepid
[00:38] <gouki> I'm running Hardy. I can create a pbuild environment for Jaunty and test it there, nhandler?
[00:38] <nhandler> Not yet gouki. The Jaunty repositories haven't opened yet
[00:38] <james_w> jaunty is there, so you can create a pbuilder of it
[00:39] <nhandler> james_w: I thought the repositories weren't complete yet
[00:39] <james_w> it's just the floodgates haven't opened yet
[00:39] <james_w> nhandler: intrepid has been copied
[00:39] <nhandler> james_w: I thought they were still in the process of copying it over
[00:40] <james_w> nhandler: all done I believe
[00:40] <james_w> the current task is getting the Jaunty toolchain in place
[00:40] <nhandler> james_w: Great. Any idea when it will be unfrozen?
[00:40] <james_w> when ^ is complete
[00:41] <Laney> JauntyReleaseSchedule says the 6th
[00:41] <ScottK> It'll open when it's ready.
[00:41] <ScottK> No reason you can't upload now though.  Stuff will just sit in queue.
[00:42] <nhandler> I know lintian was throwing warnings about jaunty in debian/changelog. Has this been updated?
[00:42] <ScottK> No.
[00:43] <ScottK> Patches welcome no doubt.
[00:43] <nhandler> ScottK: Would that be lintian that would need to be patched?
[00:44] <ScottK> nhandler: Yes.
[00:44] <ScottK> nhandler: A patch for debchange in devscripts to default to jaunty wouldn't be bad either.
[00:44] <ScottK> nhandler: debchroot will need updating too.
[00:45] <nhandler> Thanks ScottK
[01:02] <NCommander> nhandler, want help making those patches :-)?
[01:04] <ScottK> The lintian one is easy enough even I could do it.
[01:04] <StevenK> lintian has already been patched
[01:04] <ScottK> Ah.
[01:04]  * NCommander needs to install dapper on a PowerPC box
[01:04] <ajmitch> most of them could be done within 5 minutes
[01:04] <StevenK> It's in lintian's git tree
[01:04] <ScottK> OK.
[01:06] <nhandler> NCommander: Thanks, but I think I can handle it
[01:06] <NCommander> yay for uploads to jaunty
[01:06] <NCommander> Speaking of uploads
[01:08]  * ajmitch wonders if universe merges have been completed yet
[01:08] <TheMuso> ajmitch: You're a funny one today.
[01:08]  * NCommander reads MOTU council's archives
[01:09] <ajmitch> TheMuso: I'm sure that there can't be that many to work on
[01:09] <ajmitch> or at least most of the changes will have been pushed to debian, right?
[01:09] <wgrant> Nah, only 400.
[01:10] <ajmitch> 400 isn't too bad
[01:10] <NCommander> ScottK, I just discovered there was a backports mailing list
[01:11]  * TheMuso prepares jaunty chroots./
[01:12]  * ajmitch preps his merge list & pbuilder
[01:12] <TheMuso> One can still bootstrap, since only toolchain packages have been updated so far.
[01:14] <NCommander> TheMuso, no, the entire archive have been imported for jaunty
[01:15] <ajmitch> NCommander: entire debian archive, or do you just mean that intrepid has been copied?
[01:15] <NCommander> Intrepid has been copied, you can debootstrap jaunty AFAIK
[01:15] <ajmitch> isn't that exactly what TheMuso just said?
[01:15] <TheMuso> NCommander: thats what I was saying.
[01:16]  * NCommander drinks more caffiene
[01:18] <ajmitch> wgrant: ok, I count 353 for jaunty at the moment, no doubt I'm missing some
[01:18] <ajmitch> (universe)
[01:19] <wgrant> mdt sees 405 for universe, but that will include build1
[01:19] <ajmitch> right
[01:19] <TheMuso> Can MoM be made to merge with experimental, since debian is frozen?
[01:19] <ajmitch> that's not necessarily safe
[01:19] <NCommander> TheMuso, there are a lot of things in experimental we don't want
[01:19] <TheMuso> More to the point, is MoM set up that way?
[01:19] <TheMuso> ah right.
[01:20]  * NCommander notes that we're going to be hurting if Debian doesn't release soon
[01:20]  * ajmitch is only doing a comparison of debian unstable & jaunty universe to get those 353
[01:20] <ajmitch> NCommander: no, I don't think we'll hurt
[01:20] <ScottK> NCommander: There is?
[01:20] <wgrant> http://qa.ubuntuwire.com/multidistrotools/universe.html is what I'm going by.
[01:21] <ajmitch> so what are the merge rules this time round?
[01:21] <NCommander> ScottK, plenty of people upload SVN snapshots to experimental, I dunno if I want those over a stable release
[01:21] <ScottK> NCommander: Agreed.
[01:21] <NCommander> ajmitch, the main issue is that very few pakacagers are updating packages to sid to perserve the sid->lenny upgrade path
[01:21] <ScottK> One always ought to know  why something is in Experimental.
[01:21]  * NCommander thinks debian-changes has slowed to a trickle ATM
[01:22] <ajmitch> wgrant: you're right, it's the buildX revisions that's throwing off my count
[01:23] <ajmitch> since I'm only looking at versions which contain 'ubuntu'
[01:23] <ScottK> It'd be nice if Lintian knew to treat those as Ubuntu builds too
[01:23] <wgrant> Ah.
[01:23] <wgrant> ScottK: So it doesn't turn them into build1ubuntu1?
[01:23] <ajmitch> mor that lintian doesn't complain about an unknown NMU or bad version
[01:23] <ScottK> wgrant: That'd be dch, but as ajmitch says
[01:24] <wgrant> Oh, damn, yes.
[01:24]  * NCommander *really* wished LP just supported normal binNMUing
[01:24] <NCommander> Or binary rebuilds in Ubuntu terminology
[01:24]  * ajmitch wouldn't mind starting merging, apart from the whole contacting people part
[01:26] <ScottK> ajmitch: You're welcome to all mine
[01:26] <StevenK> NCommander: If you only accept source uploads, you can't have it both ways
[01:27] <NCommander> StevenK, have a binary rebuild button on Launchpad, which causes sbuild to be called with the --binNMU switch
[01:27] <StevenK> You assume Launchpad can actually call sbuild
[01:27] <ScottK> It can retry failed builds.  Retrying unfailed ones shouldn't be so much harder.
[01:28] <NCommander> ScottK, that works by marking the record NEEDS BUILD from FAILED
[01:28] <NCommander> Which means whatever magic process checks for builds sees it and retries it, hence why the build logs get clobbered
[01:28] <ScottK> NCommander: OK. so mark it NEEDS BUILDS from DONE or whatever.
[01:29] <StevenK> You can't
[01:29] <StevenK> The version needs to change
[01:29] <NCommander> Right
[01:29] <ScottK> Picky, picky, picky.
[01:29] <StevenK> Be it the source version or the binary version.
[01:29] <NCommander> dpkg will recongize a version with a +b1 binary as being the same base version
[01:29] <StevenK> Personally, I like buildX
[01:29] <ajmitch> ScottK: I'll have to get in before sebner, I guess
[01:29] <NCommander> StevenK, when a binNMU is done, there is a specific catch in dak and dpkg to allow an out of sync binary and source
[01:30]  * NCommander notes that a binNMU is done internally by recreating the source package, and building that
[01:30] <StevenK> So I have no wish to see this changed
[01:31] <ScottK> I guess I don't have very many merges waiting.
[01:31] <ScottK> I think I mostly sponsored stuff this last cycle.
[01:31] <ScottK> Do we have anything that will give a list of packages not in Debian with new upstream versions?
[01:31] <ajmitch> I've spotted 3, 2 of which are mail
[01:32] <wgrant> ScottK: Yes, gimme a sec.
[01:33] <wgrant> http://qa.ubuntuwire.com/uehs/ shows them and Debian QA-maintained packages.
[01:33] <ajmitch> ScottK: of the 1 other package that's to be merged by you, it's a transitional package
[01:33] <ScottK> wgrant: THanks.
[01:33] <ScottK> ajmitch: As I said, not much.
[01:34] <ajmitch> I guess I won't have much to do then
[01:34] <CarlFK> what is the env var that will cause dpkg-buildpackage to tell gcc build with debug symbols?
[01:34] <CarlFK> probably something like FOO=-g
[01:36]  * NCommander looks forward to jaunty general archive open
[01:46] <gouki> Using the debian/menu file I can create a shortcut, correct?
[01:47] <nhandler> gouki: I believe the debian/menu file is mainly for debian. You want to install a .desktop file.
[01:48] <gouki> nhandler, do you know about documentation for that?
[01:49] <nhandler> gouki: http://standards.freedesktop.org/desktop-entry-spec/latest/
[01:49] <gouki> nhandler, thank you.
[01:49] <nhandler> gouki: You should also read https://wiki.ubuntu.com/PackagingGuide/SupplementaryFiles#.desktop%20Files
[01:51] <gouki> nhandler, that last one is very interesting. Thank you.
[01:52] <nhandler> You're welcome ;)
[02:14] <CarlFK> ﻿script does "apt-get source $PACKAGE" which creates a dir based on package+version- how can I figure out what the dir is so the script can cd into it?
[02:49] <pangloss> anyone have a second to answer a question?
[02:50] <jdong> etiquette here is to ask the question and see if anyone answers it :)
[02:51] <pangloss> hah
[02:51] <pangloss> are there any tutorials on how to use dput to upload source packages to your ppa?
[02:52] <ajmitch> !ppa
[02:52] <pangloss> thanks ajmitch
[02:53] <ScottK> pangloss: In general, PPA questions are best asked in #launchpad.
[02:54] <pangloss> ScottK: Sorry, I figured this would be a good place to ask since its a motu related thing
[02:56] <ScottK> pangloss: If it's a PPA, it's not.
[04:06] <gouki> Matthew Garrett is not the developer of Ultamatix, is he? http://nancib.wordpress.com/2008/11/02/pengs-links-for-sunday-2-november
[04:07] <ajmitch> no, he certainly isn't
[04:08] <ajmitch> he wouldn't have such scathing opinions of it if that were the case
[04:08] <StevenK> If he were, it might actually do sane stuff, too
[04:08] <ajmitch> one would expect some sanity from him
[04:08] <ajmitch> his rants are always rather amusing
[04:08] <StevenK> Hm
[04:09] <StevenK> Matthew didn't write Automatix either
[04:09] <ajmitch> He would have been soundly beaten if he did
[04:09] <Flannel> Ultamatix is the same crap from automatix.
[04:09] <Flannel> The advertised "rewrite to make it safer" didn't happen
[04:11] <StevenK> It's just so full of fail
[04:12] <pangloss> motu
[04:12] <gouki> I was ALMOST sure he didn't do it, but I could be missing something because of my English.
[04:13] <pangloss> youre recipes are broken >.<
[04:13] <nxvl_> gouki: you uploaded the package?
[04:14]  * ajmitch is getting nervous with the water dripping from the ceiling
[04:14] <gouki> nxvl_, no I did not. Did think you'd be back.
[04:14] <gouki> Let me work on that.
[04:16] <pangloss> This guide is broken https://wiki.ubuntu.com/PackagingGuide/Complete#Recipe:%20Updating%20An%20Ubuntu%20Package
[04:16] <pangloss> bad motu..
[04:16] <pangloss> go sit in the corner!
[04:16] <nhandler> What is broked pangloss ?
[04:17] <pangloss> nhandler, first of all, step 4 skips a step
[04:17] <pangloss> it does not show you how to install the old source package
[04:17] <pangloss> secondly
[04:17] <nhandler> pangloss: You don't install the old source package
[04:17] <pangloss> extract is a better term?
[04:17] <nhandler> Yeah
[04:18] <nhandler> And I thought someone said they updated this recipe earlier today
[04:18] <pangloss> because you need the brasero-0.5.2 directory
[04:18] <pangloss> well it does not look very updated
[04:18] <pangloss> and additionally
[04:18] <pangloss> the package does not build when you;re finished
[04:18] <pangloss> so
[04:18] <nhandler> What messages are produced when you go to build?
[04:19] <pangloss> 1 sec
[04:19] <pangloss> here is what I can see, but I will send you the whole file too
[04:19] <pangloss> nhandler: http://paste.ubuntu.com/66592/
[04:20] <nhandler> pangloss: They modified the dget command to be dget -xu. That should create the required folder
[04:20] <nhandler> And how were you building that package pangloss ?
[04:20] <pangloss> well I tried it two ways
[04:21] <pangloss> first with pbuilder on my computer via 'sudo pbuilder build <package.dsc>
[04:21] <pangloss> '
[04:22] <nhandler> What version of Ubuntu is your pbuilder chroot?
[04:22] <pangloss> and the second via launchpads servers incase my pbuilder was broken
[04:22] <pangloss> its intrepid
[04:22] <pangloss> I ran this
[04:23] <pangloss> 'sudo pbuilder create --distribution intrepid \        --othermirror "deb http://archive.ubuntu.com/ubuntu intrepid main restricted universe multiverse"'
[04:24] <pangloss> nhandler here is the whole FAILEDTOBUILD log http://paste.ubuntu.com/66593/
[04:25] <pangloss> I followed the recipe to a tee
[04:26] <nhandler> pangloss: Give me a second to try and follow the recipe
[04:27] <nhandler> pangloss: Are you running your own repo mirror?
[04:28] <pangloss> nhandler: I have my own PPA
[04:28] <pangloss> https://launchpad.net/~james-burkle/+archive
[04:28] <nhandler> Is this the build log from the ppa?
[04:28] <pangloss> yes
[04:28] <nhandler> Ok
[04:29] <pangloss> 3 e-mails, 3 fails
[04:29] <pangloss> thanks for your time nhandler
[04:30] <nhandler> pangloss: I actually have to head of to bed now. I'll finish going through the recipe tomorrow. Sorry.
[04:31] <pangloss> ok, thanks
[04:33]  * Elbrus is also heading to bed
[04:43] <gouki> I uploaded my first package to REVU. I was wondering if someone could point out the stupid things I've done? :)
[04:48] <coppro> who took out the pbuilder completions?
[05:01] <porthose> gouki: give use a link
[05:02] <gouki> porthose, I've been looking at it, but still hasn't showed up.
[05:03] <porthose> NCommander: you can only upload to REVU now if you are a UUC or higher correct?
[05:04] <ScottK> porthose: That's a proposal.  It's not implemented yet.
[05:05] <gouki> So my dput.cf with anonymous works but it just has a delay?
[05:05] <NCommander> gouki, 5-20 minutes
[05:05]  * NCommander can't remember what the crontab is currently set to
[05:05] <gouki> OK, NCommander. Thank you.
[05:05] <NCommander> ScottK, can you upload a merge for me?
[05:09] <ScottK> NCommander: I could, but it won't go anywhere.
[05:09] <ScottK> Can it wait (it's a bit late)
[05:09] <NCommander> Yeah
[05:09]  * NCommander is just attacking his list of merges
[05:10] <ScottK> NCommander: Who plus 1'ed your MOTU app so far?
[05:11] <NCommander> dholbach and
[05:11] <NCommander> uhhhh
[05:11]  * NCommander blanks on the second name
[05:11] <ScottK> nixternal?
[05:11] <NCommander> THere we go
[05:11] <NCommander> (yes)
[05:12] <NCommander> wooo, midori merged
[05:12] <NCommander> one down, four to go
[05:13] <ScottK> Well hopefully soren, geser, or persia will give you an upcheck soon and you can upload yourself.
[05:19] <ScottK> My first Jaunty upload is sitting in unapproved.
[05:31] <NCommander> ScottK, did you do any checking in adept w.r.t. to version pinning?
[05:32] <ScottK> NCommander: Not any successful checking.
[05:33]  * NCommander guesses adept might not have pinning support
[05:33]  * ScottK doens't normally use it, so doesn't know if it's unsupported or he didn't figure it out.
[05:33] <ScottK> I'm guessing not as Adept 3 (for KDE4) was a total rewrite.
[05:35] <NCommander> ScottK, https://blueprints.edge.launchpad.net/intrepid-backports/+spec/backport-pinning-support
[05:36] <coppro> and it sucks
[05:37] <coppro> just wanted it out there
[05:37] <gouki> Hmmm ... Don't think the package went through :S
[05:37] <NCommander> gouki, have you actually added any GPG keys to your Launchpad account (and then signed into REVU?)
[05:37] <jdong> NCommander: personally I prefer the debian backports.org system for this
[05:37] <Yasumoto> hey guys, I've got a debdiff on here that seems to be helping a decent amount of people, I'm wondering what the next steps I should take are
[05:37] <jdong> but the chances of getting LP folks to implement that is zilch
[05:37] <Yasumoto> https://bugs.edge.launchpad.net/ubuntu/+source/libgnomecanvas/+bug/272316
[05:38] <gouki> My GPG is on LP, but I uploaded as anonymous. Do I need to sign in?
[05:38] <NCommander> jdong, that's what we're trying to implement
[05:38] <Yasumoto> I know that Intrepid's just released, and I have no problems waiting on it for a while, but just want to to know if there's anything I can do to help push it along
[05:38] <NCommander> jdong, it needs both work on the GUI to be more user friendly (synaptic has pinning support, but I actually had to use the manual to find it), and it needs modification to Soyuz to pin the repo below 100
[05:38] <ScottK> jdong: We can ask.
[05:39] <NCommander> ScottK, alternatively, we can drop a hack into APT (or ship a conffile) that pins the repo lower
[05:39] <NCommander> Not a pretty solution, but better than no pinning
[05:39] <ScottK> NCommander: Get the gui figured out first ...
[05:39] <jdong> NCommander: I'd rather have separate sections like the Debian implementation
[05:39] <NCommander> ScottK, as I said, synaptic has support, I just need to figure out how to make it more "clean"
[05:39] <NCommander> separate sections?
[05:39] <NCommander> jdong, - ^
[05:40]  * NCommander is just familar w/ pinning on the backports.org repo
[05:40] <jdong> NCommander: yeah, like Debian backports.org puts each application in its own section
[05:40] <NCommander> WHen did that happen
[05:40] <jdong> NCommander: i.e. deb http://backports.org/... all
[05:40] <jdong> specifies every backport
[05:40] <jdong> or you can specify ... gimp firefox bzr
[05:40] <NCommander> Uhhh O_O;
[05:40] <jdong> unless they removed that abilitiy within the past 2 years
[05:40] <NCommander> oh, you mean having to manually install each package, right?
[05:41] <NCommander> (apt-get -t etch-backports intsall *package*
[05:41] <wgrant> That sounds more like a hack.
[05:41] <ScottK> wgrant: It's better than having to enable all of backports to get one package.
[05:41] <jdong> wgrant: do you think pinning is solid enough for selective backport picking?
[05:41] <NCommander> wgrant, no, he's referring to the pinning used by default on the backports repositry
[05:41] <NCommander> Well, the apt-get has the -t branch, which sets the pin on a repo to 990
[05:42] <jdong> NCommander: which doesn't work with source, but still that's another point
[05:42] <NCommander> By default apt will ignore anything with a low enough pin prioity (under 200)
[05:42] <wgrant> I'm not sure if pinning will work well here, but there must be a better solution
[05:42] <stefanlsd> Yasumoto: If you believe the patch addresses the when of a SRU - https://wiki.ubuntu.com/StableReleaseUpdates   - you can follow that process
[05:42] <NCommander> My solution is we pin the backport repo to 100 so backports will not automatically clobber main packages
[05:42] <jdong> I'd like something like add/remove programs for browsing backports
[05:42] <NCommander> And then in synaptic, have a Backport Available section
[05:42] <jdong> NCommander: but then a user can have a weird mix of backports and non-backports that we don't support
[05:43] <jdong> NCommander: I'm SURE our dependencies aren't specified well enough for this to be robuts
[05:43] <jdong> robust*
[05:43] <NCommander> We already don't support backports, and suggest pinning in our directions
[05:43] <jdong> well we suggest it as a hack.
[05:43] <NCommander> jdong, when you have a -t option set, the dependencies are pulled from the backport repo
[05:43] <jdong> NCommander: and how confident are you that all dependencies are represented properly? :)
[05:43] <NCommander> That's a bug and deserves an upload to fix ;-)
[05:43] <ScottK> Ohhh.
[05:44]  * ScottK stops typing since NCommander took the words out of his mouth.
[05:44] <nxvl> NCommander: hi! can you look in the revu queue why is hydra not being showed?
[05:44] <jdong> NCommander: lol I recall my days of mixing testing and sid this way and NASTY things happened.
[05:44] <NCommander> jdong, most people only enable backports for a single package or two
[05:44] <jdong> NCommander: [citation needed]
[05:44] <ScottK> jdong: Key difference is that we're building against the target release and so it should be OK.
[05:45] <NCommander> By having them only install that package and any necessary dependencies should pulled only
[05:45] <jdong> ScottK: alright, if you feel it's okay I have no bojections to it
[05:45] <NCommander> jdong, thats how backports.org works
[05:45] <Yasumoto> stefanlsd: alright, sweet. thanks :)
[05:45] <jdong> ok, so if a-backport depends on b-backport, and user selects a-backport, but later b-backport has an update available, what happens?
[05:45] <nxvl> gouki: you need to subscribe you to revu-uploaders
[05:45] <nxvl> gouki: https://edge.launchpad.net/~revu-uploaders
[05:45] <jdong> does this middle dependency get pulled in?
[05:46] <NCommander> nxvl, er, thats a little out of date :-)
[05:46] <NCommander> nxvl, we haven't allowed that in ages
[05:46] <NCommander> jdong, err, huh?
[05:46] <NCommander> jdong, if at the time of installation a backport requires an updated dependency (that is package a depends on package b which is > than whats in hardy, then that package will get pulled in)
[05:47] <jdong> NCommander: ok, user installs dvdrip backport which pulls in new x264 backport. Two weeks later a critical security bug appears in x264 and we update it.
[05:47] <nxvl> NCommander: what? revu-uploaders?
[05:47] <jdong> NCommander: does this automatically get pulled in with the pinning config?
[05:47] <NCommander> nxvl, yeah, that's been unused for months now
[05:47] <coppro> I don't think so
[05:47] <NCommander> jdong, no
[05:47] <coppro> I don't think you can pin a specific repo
[05:47] <jdong> NCommander: well, that's broken IMO.
[05:47] <coppro> I just don't pin
[05:47] <NCommander> jdong, our current methodology is also broken. ONe bad backport and we can break a load of users not using an existing package
[05:48] <NCommander> coppro, you can, you can pin specific packages and repos
[05:48] <nxvl> gouki: then you don't
[05:48] <ScottK> NCommander: Not implemented in Adept, but upstream is open to implementing for Jaunty if we can get a design done.
[05:48] <nxvl> :P
[05:48] <jdong> NCommander: agreed. but I'm not happy with pinning as a proposed solution.
[05:48] <gouki> nxvl, haven't.
[05:48] <coppro> oh so you can pin a package from updating from a specific repo?
[05:48] <nxvl> NCommander: so, can you check why is that package not being listed please
[05:48] <NCommander> gouki, are your GPG keys on Launchpad properly set?
[05:48] <NCommander> (what was the package?)
[05:48]  * coppro eagerly awaits the oo.o3 backport
[05:48] <jdong> NCommander: and please rewrite blueprints in a non-implementation-specific manner.
[05:49] <StevenK> Argh
[05:49] <gouki> NCommander, yes, they are.
[05:49] <NCommander> gouki, have you actually logged into REVU since last updating your keys?
[05:49] <jdong> pinning is not necessarily the *ONLY* way to accomplish what we want, and in fact rigth now I disagree with implementation by pinning.
[05:49] <jdong> I DO want the behavior of selective backports
[05:49] <ScottK> jdong: OK.  Then let's agree on that.
[05:49] <jdong> let's keep the spec at that until we figure out a sane implementation
[05:49]  * NCommander edits the spec
[05:49] <gouki> NCommander, yes.
[05:49] <coppro> you could give each backport its own repo [/badidea[
[05:50] <ScottK> jdong: I do think pinning would be an improvement over the current situation, but certainly if we can do better ...
[05:50] <jdong> coppro: not any worseofanidea than pinning
[05:50] <jdong> coppro: the problem is shared dependencies
[05:50] <jdong> actually... what *if* each backport was in a separate repo?
[05:50] <NCommander> Well, maybe we can get a security-backports repo then
[05:50] <coppro> can't you do it like PPAs do and allow dependency on specific other ones only?
[05:50] <wgrant> jdong: Then  we would murder you!
[05:50] <NCommander> Or just make sure security annoucements are released
[05:50] <jdong> wgrant: lol is it that unreasonable an idea other than launchpad dev overhead to implement?
[05:51] <jdong> coppro: exactly
[05:51] <jdong> that's what I'm thinking. What if it was like each backport was in an independent "PPA"
[05:51] <jdong> and the GUI for selecting backports simply enables each one of these.
[05:51] <coppro> then it would be awesome
[05:52]  * NCommander gets an idea
[05:52] <coppro> uh oh
[05:52] <StevenK> Then you need to add six or seven PPAs if you backport something large
[05:52] <jdong> there would need to be some magic on the implementation side to get this workflow easier for archive admins
[05:52] <NCommander> We can use APT pins
[05:52] <coppro> and the difference is?
[05:52] <NCommander> But we need to expand the scope
[05:52] <coppro> we could also modify apt
[05:52] <NCommander> Every time you install a package, we need to pin that package to 200, so it will get installed and ugpraded automatically
[05:53] <jdong> StevenK: well why is that a horrible thing if a UI represents the dependency properly?
[05:53] <StevenK> jdong: Because it means Software Sources turns into a cesspoll
[05:53] <NCommander> When a security fault is found, we modify the package to explicately depend on the new version in backports. As long as the installed package is pinned, apt-get dist-upgrade will pull the updated dependency
[05:53] <NCommander> ^- jdong
[05:53] <StevenK> cesspool
[05:54] <NCommander> That means APT need a way to programmability change pins
[05:54] <jdong> NCommander: can't we still run into situations where one bad backport breaks more backports?
[05:54] <coppro> here's a worse idea than making every backport a PPA
[05:54] <NCommander> jdong, no
[05:54] <NCommander> jdong, ok, if we have a depends on a (>= 0.2)
[05:54] <coppro> modify apt to allow an archive not to be selected for default updates, and then make it so that it will update if it is a package from that repo or depended on by one in it
[05:55] <NCommander> And APT sees 0.2, and 0.22, but the repo 0.22 is pinned below 200
[05:55] <NCommander> It will install 0.2 over 0.22
[05:56] <NCommander> If we ever find a security fault in a backported version, we simply change the dependencies in the rdepends that we've backported to pull in the newer dependencies explicately
[05:56] <jdong> well I still don't personally like the idea of one big monolithic backports pool
[05:56] <jdong> I think using pinning is a HACK to make something MONOLITHIC appear MODULAR.
[05:56] <NCommander> I can't see the soyuz developers changing that anytime soon though
[05:56]  * coppro likes his idea, even though it's mostly ridiculous
[05:56] <jdong> I think ideally backports would be modular enough that you can enable one channel at a time
[05:56] <NCommander> and there are people who still want the entire backports repo open totally
[05:57] <NCommander> so any apps that get backported with new features they can still take advantage of
[05:57] <jdong> but I think we're bordering on the limits of APT.
[05:57] <coppro> NCommander: my suggestion allows that, but it means modifying the apt and any other package system sources
[05:57] <jdong> note that we could use sources.list.d to manage this stuff :)
[05:57] <NCommander> Well, I think backports would have to leave Launchpad if we did it
[05:57] <NCommander> And we'd have to run repopro or something equivelent
[05:58] <jdong> nobody's leaving launchpad anytime soon.
[05:58] <ScottK> We don't want to go that direction.
[05:58] <jdong> NCommander: I still have issues with backports-building-on-backports. you *WILL*. that's read *WILL* end up with a clusterfsck situation that pulls everything in.
[05:58] <NCommander> I don't think we can fessibly make a new pocket with each new backport
[05:58] <jdong> NCommander: think about a subversion 1.5.0 backport, a git backport, and then a bzr backport.
[05:58] <jdong> you isntall bzr. what happens?
[05:58] <NCommander> point taken
[05:59] <ScottK> jdong: Backports already build on backports, so that's not making things worse.
[05:59] <jdong> ScottK: right, I'm saying it doesn't solve the problem with not being able to granularly select backports
[05:59] <NCommander> I still think pinning support is best rewards for the lowest cost
[05:59] <jdong> perhaps that's true.
[05:59] <jdong> I'll agree with that
[05:59] <ScottK> jdong: You've got to bring the depends in.  There's no way around that.
[06:00] <NCommander> We can't elimate risk of regressions
[06:00] <jdong> ScottK: right, but what if I want a git backport but I'm not interested in subversion 1.5?
[06:00] <ScottK> The problem with the svn backport was not enough rdpends testing.
[06:00] <NCommander> jdong, well, if you want bzr-svn, you still need subversion 1.5 due to the dependency of bzr-svn
[06:00] <ScottK> jdong: As long as you don't install git-svn your'e fine.
[06:00] <jdong> I'm just using subversion and git as an example of a common library backport plus a bunch of rdepends backports.
[06:00] <jdong> just the first example that came to mind
[06:01] <NCommander> As a general rule of thumb, we attempt to avoid library backports for this very reason
[06:01] <ScottK> Well historically we don't do so many of those.
[06:01] <ScottK> svn had to happen though.
[06:01] <jdong> what if.... crack idea... backports were a per-user service?
[06:01] <jdong> i.e. right click, backport this
[06:01] <jdong> and some prevu/pbuilder backend on the local system built the backport?
[06:01] <ScottK> jdong: Getdeb.
[06:01] <NCommander> Isn't that what prevu designed to do an extent?
[06:01] <jdong> ScottK: oh god that's not what I meant.
[06:01] <jdong> NCommander: yes but it needs to be integrated within our package management tools
[06:02] <jdong> and made even MORE zero-setup friendly
[06:02] <NCommander> actually
[06:02] <NCommander> I just got an insane idea
[06:02] <NCommander> Launchpad is implementing two features
[06:02] <NCommander> Multiple PPAs per user
[06:02] <NCommander> and native syncing
[06:02] <ScottK> OK.  It was how it sounded.
[06:02] <NCommander> What we could do is when a user requests a backport
[06:02] <NCommander> We backport as normal
[06:02] <jdong> ScottK: lol I could argue that it's completely different :D
[06:02] <NCommander> BUT we can also copy that backport into a users PPA
[06:02] <NCommander> The user enables their own PPA
[06:02] <NCommander> ANd gets said backport
[06:03] <jdong> NCommander: well that depends on users being launchpad zombies
[06:03] <NCommander> Add a mechanism where someone can pick and choose their own backports and ...
[06:03] <jdong> and with our resident launchpad critic nearby I have to say, we need a local alternative.
[06:03] <NCommander> They already are to request them in the first place :-)
[06:03]  * NCommander watches ScottK just approve the idea :-) *shot*
[06:03] <jdong> NCommander: using LP to communicate with devs is not the same as requiring LP to use -backports :)
[06:03] <NCommander> Well, I think its saner.
[06:04] <jdong> NCommander: haha you're asking Ubuntu's biggest LP critic to support your idea that 100% depends on Launchpad for correct operation? :)
[06:04] <NCommander> We're not going to get away from a massive pool of backports
[06:04] <jdong> ok, why NOT, have prevu on local systems build each user's backports?
[06:04] <jdong> that way users can customize which backports they want.
[06:04] <NCommander> How do you handle backports that need porting
[06:04] <ScottK> Until PPAs are signed, they can't be a replacement for backports.
[06:04] <jdong> NCommander: patch repo?
[06:04] <NCommander> Oooh
[06:04] <NCommander> Now THERE is an idea
[06:04] <jdong> NCommander: like a debdiff repo :)
[06:05] <NCommander> We could just offer a source based repo
[06:05] <NCommander> (deb-src *backports*
[06:05] <ScottK> Oh dear lord you all need to look for simplicity, not complexity.
[06:05] <NCommander> I just don't like the ideas of users compiling an entire chain of backports
[06:05] <jdong> NCommander: right. then prevu would check this repo for a source package and prefer it to launchpadding an intrepid package.
[06:05] <NCommander> jdong, we could just have that source repo in APT, no need to get too fancy
[06:05] <NCommander> For most users, thats not going to blow the world up :-P
[06:06] <ScottK> Step back and look at your design goals.  Don't dive straight into implementation.
[06:06] <jdong> NCommander: nah we don't need to use a APT source repo in sources.list
[06:06] <NCommander> Ok
[06:06] <NCommander> ScottK is right
[06:06] <NCommander> THe objection is to allow selective installation of backports
[06:06] <jdong> yeah, let's first get a correct spec written.
[06:06] <jdong> objective, use cases.
[06:06] <NCommander> Who wants to start writing
[06:06]  * NCommander looks at jdong
[06:06] <jdong> well I need to start sleeping :)
[06:06] <jdong> classes tomorrow :)
[06:06] <tbielawa> can some one tell me what started this convesation?
[06:07] <tbielawa> and how I can jump in?
[06:07] <jdong> tbielawa: lol I don't know but I somehow got sucked into it
[06:07] <tbielawa> :)
[06:07]  * NCommander wrote a blueprint
[06:07] <NCommander> I don't think either of you are going to be at UDS, are you ?
[06:07]  * NCommander knows ScottK won't ...
[06:07] <tbielawa> NCommander, I'm trying hard to get there
[06:07] <ScottK> Nope.
[06:07] <NCommander> jdong, how about you?
[06:08] <jdong> NCommander: I'm not going to be
[06:08] <jdong> I wish I had the time to be :)
[06:09]  * NCommander shall be alone then at UDS
[06:09] <StevenK> NCommander: Pack tissues.
[06:09] <tbielawa> sonicmtails?
[06:09] <NCommander> tbielawa, ?
[06:09] <NCommander> yeah?
[06:10] <tbielawa> NCommander, trying to find your blueprint
[06:10] <NCommander> thats me
[06:10]  * ScottK decides to let the two youngsters fight it out and heads to bed.
[06:12] <stefanlsd> heh. off 2 work. bbl :)
[06:41] <dholbach> good morning
[06:41] <ajmitch> hi dholbach
[06:41] <dholbach> hi ajmitch
[06:42] <iulian> Hey dholbach, ajmitch.
[06:42] <dholbach> hiya iulian
[06:48] <tbielawa> any revu admins on?
[06:48] <tbielawa> oh ajmitch
[06:49] <tbielawa> perhaps I'm being silly, or something happened I don't know about. But I'm getting Permission denied (publickey) on revu uploads
[06:50] <wgrant> tbielawa: uh, why are you trying to upload over SSH?
[06:51] <tbielawa> it appears to be the default mechanism for upload.
[06:52] <tbielawa> I see a small notice now on the wiki about ftp, but it's not my default upload method. and the wiki doesn't have it defined as ftp. Should it be?
[06:53] <tbielawa> it's uploaded now. thanks for pointing that out.
[06:55] <StevenK> I don't think REVU or Ubuntu has every allowed uploading via ssh
[06:55] <StevenK> s/\(ever\)y/\1/
[06:56] <tbielawa> I see what my problem was now
[06:58] <tbielawa> can anyone take a look at my lucidlife upload on revu please?
[06:59] <wgrant> Are the licensing and duplication issues resolved?
[07:05] <tbielawa> was unable to replicatate the ftbfs
[07:05] <tbielawa> licensing is taken care of
[07:06] <wgrant> Mine was also rejected partly on the grounds that it was similar to gtklife or whatever it is that it derives from.
[07:07] <tbielawa> ah
[07:07] <tbielawa> xlife was the first I think
[07:07] <porthose> tbielawa: are you still working on symmetrica?
[07:08] <tbielawa> no work to be done. I should archive it. it was a straight sync from debian.
[07:08] <porthose> tbielawa: k
[07:09] <tbielawa> revu fails at archiving :(
[07:12] <tbielawa> If anyone is around to debug revu, here's the fail message when archiving an upload http://pastebin.ubuntu.com/66630/
[08:37] <laga> can someone fom motu-sru look at https://bugs.launchpad.net/bugs/292319 ?
[08:41] <huats> morning
[08:42] <porthose> huats: mornin (well it's soon to be bed time for me) :)
[08:43] <huats> hey porthose :)
[10:53] <Laney> all quiet on the universe front
[10:54] <orly_owl> Everyone jumped ship.
[12:56] <flithm> Hey everyone... I'm the author of an app (gizmod) that's available in universe, and users are reporting an error with boost.python1.34.1 missing a symbol on amd64 only.  This is a bug in boost, and I'm wondering if it's possible to have gizmod recompiled with the new boost (1.35) that's available in the repos?  Am willing to help with this process!  Could even push out a new source release requiring 1.35 if desired
[12:57] <flithm> PriceChild: you around?
[12:58] <james_w> hi flithm, is this bug in Intrepid?
[12:58] <flithm> james_w: yes
[12:58] <james_w> flithm: is it reported on launchpad?
[12:59] <flithm> james_w: the boost bug is, but not the gizmod one I don't think, should I open a ticket?
[12:59] <james_w> yeah, we'll need something for the SRU process
[13:00] <flithm> james_w: okay no problem
[13:00] <james_w> if you could add a "TEST CASE:" as explained in https://wiki.ubuntu.com/StableReleaseUpdates that would be fantastic
[13:00] <james_w> flithm: and please add a pointer to the boost bug
[13:01] <flithm> will do
[13:15] <flithm> james_w: bug opened: https://bugs.launchpad.net/ubuntu/+source/gizmod/+bug/293082
[14:44]  * ScottK leaves Bug #271453 for jdong.
[14:50] <bddebian> Heya gang
[14:53] <ScottK> Heya bddebian.
[14:53] <Laney> sup
[14:54] <bddebian> Hi ScottK, Laney
[14:54] <ScottK> bddebian: So did you switch to using Debian?
[14:55] <bddebian> Well I had 1 Debian laptop and 1 Ubuntu still but my Ubuntu laptop died last week :-(
[14:56] <bddebian> Though I don't think I did a single upload for Intrepid :'-(
[14:56] <ScottK> Yeah.  I ended up grabbing some of your Debian RC bug fixes.
[14:56] <geser> Hi bddebian
[14:57] <bddebian> Heya geser
[14:57] <Laney> Can someone review http://revu.ubuntuwire.com/details.py?package=goocanvasmm for me? It already got one advocate from RainCT
[14:58] <bddebian> Shit, getting a new ISP is a PITA.  Do I re-subscribe to the Ubuntu MLs with ubuntu.com, debian.org, or verizon.net address? :)
[15:00] <azeem> bddebian: use bddebian.com
[15:01] <bddebian> Well that's untested with verizon.  Comcast had issues with my mailhop forwarding :(
[15:03] <ScottK> bddebian: Got FIOS?
[15:03] <bddebian> ScottK: Yeah though now I'm regretting it
[15:03] <bddebian> They freakin block port 80
[15:03] <ScottK> bddebian: Really?  Ah.  I've got the business package so that's not a problem.
[15:03] <ScottK> I'm finding it quite nice.
[15:04] <bddebian> Yeah the speed is nice but now I'm hosed for the Hurd wiki I was hosting
[15:04] <ScottK> IME reliability is MUCH better than Comcast.
[15:05] <bddebian> A lot of people have said that.  I actually rarely had any downtime with Comcast
[15:31] <henrik-kabelkaos> i'm curious. are there any periods in particular you're doing REVU stuff?
[15:33] <coppro> right now I think
[15:33] <Laney> there are REVU days
[15:33] <RainCT> henrik-kabelkaos: there'll be a REVU Day next Friday (and the following Fridays too)
[15:33] <coppro> hmm... my update isn't going through to revu
[15:34] <coppro> dput worked but it's not showing up
[15:34] <RainCT> let me check
[15:34] <coppro> RainCT: package is metakit
[15:35] <RainCT> coppro: I can't see it
[15:35] <coppro> hmm... I'll dput again
[15:36] <coppro> just says "already uploaded"
[15:37] <henrik-kabelkaos> coppro: you need to bump ubuntu version.
[15:37] <coppro> henrik-kabelkaos: oh, ok
[15:37] <coppro> last time I did that I was told not to, I think
[15:37] <coppro> anyway, gotta leave for school
[15:37] <coppro> bye
[15:39] <RainCT> coppro: you don't have to, just use dput -f
[15:39] <RainCT> coppro: and.. you did "dput revu" (and not just "dput"), right?
[16:23] <loeppel> anyone here who can help me with a dapper ppa?!
[16:23] <loeppel> got some strange build errors
[16:26] <loeppel> http://launchpadlibrarian.net/18533338/buildlog_ubuntu-dapper-i386.php5_5.2.4-2ubuntu5.3ppa1.6_FAILEDTOBUILD.txt.gz
[16:39] <RainCT> loeppel: seems like debian/control is wrong
[16:40] <RainCT> loeppel: can you paste it somewhere?
[16:45] <loeppel> RainCT, yes
[16:45] <loeppel> this control seems to work on feisty
[16:45] <loeppel> maybe the variables changed
[16:47] <loeppel> http://de.pastebin.ca/1244097
[16:47] <loeppel> but i don't understand why this build on feisty also on dapper
[16:47] <RainCT> loeppel: because of ${source:Version}, that's new
[16:47] <RainCT> I think it had another name before
[16:48] <loeppel> ${Source-Version}
[16:48] <loeppel> ?!
[16:48] <loeppel> i just copied the control over from the feisty package
[16:48] <loeppel> what's the easiest method to fix this?
[16:48] <loeppel> (sorry for my bad english - i'll try my best ;)
[16:50] <slytherin> loeppel: is the version string split over multiple lines?
[16:51] <loeppel> what is the version string split?!
[16:51] <loeppel> php5 - 5.2.4-2ubuntu5.3ppa1.6
[16:51] <loeppel> this is the version
[16:51] <loeppel> of the package
[16:51] <slytherin> loeppel: I am talking about Depends of libapache2-mod-php5.
[16:51] <RainCT> slytherin: he's using ${source:Version}, which iirc had another name back on Dapper
[16:51] <RainCT> but I don't remember which
[16:52] <slytherin> RainCT: or the problem may be here
[16:52] <slytherin> php5-common (=
[16:52] <slytherin> ${binary:Version}),
[16:52] <RainCT> slytherin: i
[16:52] <loeppel> this is one line
[16:52] <loeppel> Depends: ${shlibs:Depends}, ${misc:Depends}, mime-support (>= 2.03-1), ${apache2:Depends}, php5-common (= ${binary:Version}), libmagic1, ucf
[16:52] <RainCT> slytherin: *I'm pretty sure that's the problem because the log seems to complain about empty parentheses in the Depends
[16:52] <loeppel> maybe the pase service malformed it
[16:53] <slytherin> loeppel: I checked it directly from your PPA, not from pastebin
[16:53] <loeppel> oh ok
[16:53] <loeppel> you are clever ;)
[16:53] <loeppel> so what can i do?
[16:53] <loeppel> it's so anyoing that there is no port of php 5.2 for dapper
[16:54] <loeppel> just for this reason i learned many things about packaging in debain and ubuntu
[16:54] <slytherin> loeppel: when ever you want to have values over multiple lines, start the 2nd, 3rd line with a blank space so that it is parsed in continuation of previous line
[16:55] <loeppel> ok, but there are only single lines in my control
[16:55] <loeppel> for Depends and Suggests etc
[16:56] <RainCT> slytherin: Ah right, I missed the space. So did ${source:Version} already work on Dapper?
[16:57] <loeppel> on feisty it works - and both use debhelper 5.x - but maybe they changed it too...
[16:58] <loeppel> which space you are talking about?
[16:59] <RainCT> loeppel: you've to add an empty space on the line after "Depends:", so that the tools know that the depends still continue there
[16:59] <loeppel> same as with Description
[16:59] <RainCT> yep
[16:59] <loeppel> but a line ends normaly with \n or \r\n right?
[17:00] <loeppel> and there is no \n and/or \r\n before i finish with my Depends:
[17:00] <loeppel> also i just copied this from another ppa, and there its working, so i can't understand your suggestion ;-)
[17:01] <RainCT> btw, anyone up for giving http://revu.ubuntuwire.com/details.py?package=goocanvasmm a second advocation?
[17:03] <loeppel> RainCT, so where you think my control is wrong? Either i'm stupid or there is jut no line break within any Depends ?!
[17:04] <slytherin> loeppel: My suggestion is based on the control file found in your PPA.
[17:05] <loeppel> yes, and i can't see there any line breaks within "Depends: ..." - can you?
[17:05] <slytherin> loeppel: I am seeing them in gedit, let me check in VI
[17:05] <loeppel> ok
[17:06] <loeppel> or look at the diff, there you see a + for each line, so its very easy: http://launchpadlibrarian.net/18532555/php5_5.2.4-2ubuntu5.3ppa1.6.diff.gz
[17:06] <karooga> Hi, anyone got a few minutes to revu a package of mine?
[17:07] <slytherin> loeppel: I am not seeing line break in vi. SO that reason is rules out. Next check if binary:Version is the right variable.
[17:07] <RainCT> karooga: including a link and a description increases your changes of getting a review
[17:08] <loeppel> ok, but thats the problem, i don't know where the variables came from?!
[17:08] <loeppel> so which variables exist?
[17:09] <loeppel> i've searched in the debian manual, but couldn't find anything
[17:09] <slytherin> loeppel: Can't help much. I have no idea about that variable.
[17:09] <loeppel> hmm, thats bad
[17:09] <loeppel> maybe a should replace it by another?!
[17:10] <loeppel> i've compard the control file with the one found in dotdeb.org packages of php5.2.x
[17:10] <loeppel> this guy builds up to date php versions for debian etch
[17:10] <RainCT> slytherin: do you remember where the file explaining all changes to Debian Policy is?
[17:10] <loeppel> dapper and etch, have similar release dates...
[17:11] <RainCT> ah found it
[17:11] <RainCT> loeppel: replace that with   ${Source-Version}
[17:11] <loeppel> this guy just using ${Source-Version} instead of ${source:Version} and ${binary:Version}
[17:11] <loeppel> yes
[17:11] <loeppel> ok
[17:11] <loeppel> i'll try taht
[17:11] <loeppel> that
[17:11] <loeppel> but i think it very strange that this variable works in feisty and up (including intrepid)
[17:11] <slytherin> loeppel: you will need to do that replacement in lot of places.
[17:12] <loeppel> i know
[17:12] <loeppel> i'll using search and replace function in medit ;)
[17:12] <slytherin> nothing strange in that
[17:12] <karooga> RainCT: http://revu.ubuntuwire.com/details.py?package=pyephem  (A python package that  provides scientific-grade astronomical computations).
[17:13] <loeppel> why isn't that strange? Is the Change of Varibales in control files normal?!
[17:13] <RainCT> karooga: (was just a typ, I'm busy right now :))
[17:14] <RainCT> *tip
[17:15] <karooga> RainCT: I know, was just a hint on my part.  :-)  This package seems very straight forward - I think. Still waiting for upstream on that other one btw you revued.
[17:15] <slytherin> can anyone help with the watch file error here - http://dehs.alioth.debian.org/maintainer.php?name=electric
[17:17] <loeppel> slytherin, maybe look at uscan.pl and search for the error, and see witch code is causing it, so you see whats missing, but i've no expierence with uscan or watch ;)
[17:22] <slytherin> loeppel: not in mood for that much analysis. :-)
[17:24] <RainCT> slomo: there are two spaces
[17:25] <RainCT> err, sorry, that was for slytherin
[17:27] <james_w> I'm looking at goocanvasmm
[17:27] <Laney> :>
[17:27]  * RainCT ^5 james_w :)
[17:27] <james_w> Laney: nice work, it's pretty much perfect
[17:28] <james_w> Laney: care to teach me something?
[17:28] <Laney> It had some comments from reviewers
[17:28] <Laney> sure
[17:28] <james_w> DEB_SHLIBDEPS_INCLUDE <- what's that do?
[17:28] <sebner> james_w: I'll finally attach a debdiff for twiki tomorrow (which fixes the 2 important bugs). /me is just curious if that's a normal SRU or a security thing
[17:29] <james_w> sebner: I'm not sure, I can't remember the bug it was fixing now
[17:29] <sebner> james_w: it was somehow secrity related but not a CVE
[17:30] <james_w> k, probably a normal SRU, but you may want to ask #ubuntu-hardened
[17:30] <sebner> james_w: sure, thx
[17:31] <Laney> james_w: It just specifies the dir to search for shlibs stuff
[17:31] <james_w> Laney: and why is that different to the default?
[17:33] <Laney> I don't know what the default is...
[17:33] <Laney> hang on
[17:34] <sebner> james_w: and *after* I finally got this twiki thing finished I'll write my application. I suppose you tell me that you haven't sponsored enought right? (anyways, you surely can add positive or negative comments)
[17:34] <james_w> someone else was asking me that as well, I'm having trouble remembering what I have sponsored from people :-)
[17:35] <james_w> I can certainly comment though
[17:35] <bobbo> james_w: did you get the email I sent you the other day?
[17:35] <james_w> bobbo: yeah, you were who I was referring to :-)
[17:35] <james_w> I was just going to reply
[17:36] <james_w> if you can give me pointers to the things I sponsored for you that would help
[17:36] <Laney> james_w: I don't know where I got the template from
[17:36] <slomo> RainCT: two spaces?
[17:36] <bobbo> james_w: sure 2 minutes
[17:36] <james_w> bobbo: I have only found one upload, but I remember some sync requests as well
[17:36] <james_w> bobbo: /msg is fine
[17:37] <james_w> Laney: hmm, it's not going to break anything, but checking if it is needed would be good
[17:37] <james_w> Laney: really picky comments:
[17:37] <sebner> james_w: kk, fine then
[17:37] <james_w> Laney: ${misc:Depends} for the -dev package wouldn't hurt
[17:37] <james_w> Laney: calling the docs junk might not win you any friends if upstream looks at your rules file
[17:38] <james_w> Laney: and the package takes too long to build :-)
[17:38] <Laney> hah
[17:38] <james_w> Laney: I'm really having to scrape the barrel though
[17:38] <Laney> What does the misc:Depends do?
[17:39] <apachelogger> soren, geser: please take a look at ncommander's MOTU application if you get a chance, so far only dholbach and nixternal voted :)
[17:40] <james_w> Laney: it allows debhelper to add certain depends to a package automatically, e.g. whatever package contains the gtk icon cache thing if you use dh_icons
[17:40] <james_w> Laney: it rarely makes a difference though, don't bother changing it now or anything
[17:40] <Laney> right
[17:46] <RainCT> slomo: sorry, bad tab completion, that was for slytherin
[17:54] <james_w> Laney: where does glom use the canvas?
[18:24] <Laney> james_w: Sorry, I was doing some work. Try the relationship overview under Developer
[18:26] <james_w> Laney: I've managed to move a table such that I can't see it or grab it anymore
[18:26] <james_w> Laney: would that be a bug in the canvas?
[18:27] <Laney> murrayc is upstream ;)
[18:27] <james_w> it seems to only be drawing a small part of the canvas, rather than the full area given for it in the window
[18:27] <Laney> I see that too.
[18:28] <Laney> It's probably a glom bu
[18:28] <Laney> g
[18:28] <james_w> yeah, that's what I think
[18:29] <james_w> anyway, tag, you can report it :-)
[18:29] <Laney> shall do
[18:31] <james_w> Laney: anyway, are you happy for me to upload?
[18:32] <Laney> james_w: I am. It seems like the include line in rules is redundant, at least from my smoke testing, but I'd leave it in if you're going to upload now and fix it on the next upload. You can fix the comment in rules if you'd like.
[18:33] <james_w> nah, I'll upload as is, next upload you can change things as you like
[18:33] <Laney> righto
[18:33] <james_w> though I may have to fix a bug first
[18:34] <james_w> gnome has stopped mounting my luks usb key
[18:43] <james_w> Laney: Uploaded. https://edge.launchpad.net/ubuntu/+source/goocanvasmm is available for you to subscribe to the bug mail. Thank you for your contribution to Ubuntu :-)
[18:43] <james_w> and I hope next time you can upload it yourself
[18:44] <bobbo> What should I do with this bug: https://bugs.edge.launchpad.net/ubuntu/+source/feedparser/+bug/274750 The sync was ACKed but no archive admins team subscribed. Is it just a case of waiting until Jaunty is open and subscribing them?
[18:44] <Laney> james_w: Woohoo!
[18:45] <Laney> thanks for your review, and RainCT too
[18:45] <james_w> er, sorry bobbo
[18:45] <Laney> I just need to prod huats to get bakery2.6 up
[18:45] <Laney> then we can upload glom 1.8
[18:45] <bobbo> james_w: heh, its all good :D
[18:46] <james_w> bobbo: fixed
[18:46] <bobbo> james_w: took my mentor long enough to work out what had happened :D
[18:56] <james_w> can someone put http://revu.ubuntuwire.com/details.py?package=goocanvasmm in to the correct bucket please, or do I have the power for that?
[18:58] <porthose> james_w: done
[19:01] <loeppel> can anybody here explain where the variables in control files defined?
[19:01] <azeem> which variables?
[19:01] <loeppel> things linke ${apache:Depends}
[19:01] <loeppel> like
[19:02] <azeem> do you mean when/where they are substituted?
[19:02] <azeem> or are you looking for a list of all those variable names and their purpose?
[19:02] <loeppel> both ;)
[19:02] <azeem> I don't think the latter exists
[19:03] <porthose> If someone has some time would you please have a look at http://revu.ubuntuwire.com/details.py?package=quickplay
[19:03] <loeppel> my problem is at backporting a package, things went wrong
[19:03] <loeppel> the depends are false
[19:03] <loeppel> my package depends on apache2.2-common but in dapper is only apache2-common
[19:03] <loeppel> and in control there is only a ${apache2:Depends}
[19:04] <loeppel> so i thorght this will replaced with the right version in my pbuilder environment
[19:04] <loeppel> but this seems to be wrong
[19:04] <loeppel> so it must be defined anywhere
[19:04] <loeppel> maybe in the "./debian" directory?!
[19:04] <loeppel> you understand my problem?
[19:05] <azeem> did you check your build log that you don't drag an apache2.2 dapper backport into it?
[19:05] <azeem> otherwise, the variables are getting written to debian/substvars and put into debian/control by dpkg-shlibdeps or dpkg-gencontrol I believe, both are called from a similar sounding dh_ script
[19:08] <loeppel> azeem, i use ppa build system
[19:08] <loeppel> so i don't think there is a apache2.2-common in the dapper section, is it?
[19:08] <azeem> dunno
[19:08] <azeem> I'd check nevertheelss
[19:09] <azeem> nevertheless*
[19:09] <loeppel> ok
[19:09] <azeem> otherwise, if you grep -R apache2.2 debian/ and there's no result, it's indeed weird
[19:10] <loeppel> oh, in rules there is something
[19:10] <loeppel> thank you!!
[19:29] <fabrice_sp> Hi. I have to update a package with that version: 0.0.20080102-2.1build1
[19:30] <fabrice_sp> dch is proposing 0.0.20080102-2.1build2. Is it right? It's for a SRU
[19:32]  * NCommander notes there is no hardline "correct" versioning for an SRU
[19:32] <fabrice_sp> I would say that the right version would be 0.0.20080102-2.1ubuntu0.1 for that
[19:33] <fabrice_sp> as it's not only a rebuild
[19:33] <nxvl> james_w: what is the magical line for building a native package from bzr
[19:33] <nxvl> ?
[19:39] <nxvl> james_w: neverminf found it
[19:39] <nxvl> :D
[20:01] <fabrice_sp> geser: are you there? You're the one that updated openmovieeditor version to 0.0.20080102-2.1build1
[20:08] <mathiaz> fabrice_sp: 0.0.20080102-2.1ubuntu0.1 seems a good option. See https://wiki.ubuntu.com/SecurityUpdateProcedures for more information on choosing a version number ( Preparing an update section, point 4).
[20:09] <fabrice_sp> mathiaz: great! Thanks for the link :-) (and the answer ;-) )
[20:21] <fabrice_sp> by the way, it seems that bug #283762 is solved by a rebuild (at least in my pbuilder, the dependencies updates). Do I just upload a debdiff with a version update to force rebuild?
[20:24] <DktrKranz> fabrice_sp, yes please.
[20:25] <fabrice_sp> ok, DktrKranz. I have to fill a SRU, I suppose
[20:27] <DktrKranz> fabrice_sp, yes, but seems trivial enough
[20:27] <fabrice_sp> ok. I'm on it. Thanks
[20:27] <DktrKranz> as version, you could use 0.0.20080102-2.1build1.1 (and build2 in jaunty, I guess it's affected too)
[20:28] <fabrice_sp> It would have been my next question ;-) Thanks
[20:28] <DktrKranz> fabrice_sp, when ready, feel free to ping me for sponsoring
[20:28] <fabrice_sp> great! thanks ;-)
[20:32] <geser> fabrice_sp: yes, I'm here
[20:34] <sebner> geser: I just want to warn you that you will be mentioned as one of my major sponsors for my MOTU Application (which I'll send *this* week) :P
[20:34] <NCommander> hey DktrKranz
[20:34] <DktrKranz> hoy NCommander!
[20:34] <NCommander> DktrKranz, I need your two cents on a bug
[20:34] <DktrKranz> fire t
[20:35] <DktrKranz> *it
[20:35] <NCommander> #286175
[20:35] <NCommander> ...
[20:35] <fabrice_sp> geser: too late :-) I was just looking for the reason why you named the last version of openmovieeditor 0.0.20080102-2.1build1, but since then, I understood it. Thanks for showing
[20:35] <NCommander> Bug #286175
[20:35] <NCommander> There we go
[20:36] <NCommander> DktrKranz, can you reproduce, and add your two cents
[20:36] <DktrKranz> NCommander, need SRU ACK?
[20:36] <NCommander> Not yet
[20:36] <DktrKranz> fontconfig is in main, so I can not help for that, thouth
[20:37] <NCommander> We can try and patch the affected applications (so far OOo, evince, and firefox (maybe), although evince and FF are probably bombing out due to pango)
[20:37] <DktrKranz> ah... the EVIL bug :)
[20:40] <ScottK> RainCT: Konsole in KDE4 does that automatically (re your last blog post).
[20:40] <RainCT> ScottK: can windows be split?
[20:41] <ScottK> RainCT: Yes.
[20:41] <ScottK> RIght/Left or Top/Bottom.  Your choice.
[20:42] <RainCT> ScottK: cool, I may try KDE4 out once I get a laptop
[20:43] <DktrKranz> fabrice_sp, while preparing the SRU, please provide a good test case to reproduce the issue.
[20:44] <fabrice_sp> DktrKranz: I've just uploaded the package to my ppa, to be sure to reproduce exactly the issue before, and check the correction after
[20:45] <DktrKranz> NCommander, tried to reproduce it, but it worked here. I "upgraded" to jaunty, though.
[20:45] <gouki> Guys ... Something I'm trying to package is license under GPL2, but the author added a new file with LICENSE.HYDRA and wrote quite a few things there. How does this reflect to the package?
[20:49] <afflux> Is there any special steps to be taken for an intrepid SRU at the moment?
[20:50] <afflux> s/is/are/g
[21:16] <gouki> When submitting a bug about a new package (needs packaging), one should file it against Ubuntu and Debian or submit it too on debian bts?
[21:17] <ScottK> Only submit a Debian ITP bug if you intend to get it into Debian too (this is a good idea and highly recommended).
[21:18] <directhex> much much preferred. improving debian is a much better cause than improving ubuntu. with at least as much benefit
[21:19] <gouki> ScottK, thanks. ITP is done via their BTS, right?
[21:19] <ScottK> gouki: Yes.
[21:19] <gouki> OK
[21:19] <james_w> gouki: the wnpp package to be exact
[21:20] <gouki> james_w, thank you.
[21:21] <gouki> After submitting an ITP, and when creating the bug on LP, one should point to the bug number on Debian BTS. Correct?
[21:21] <ScottK> If you use reportbug (the Ubuntu one needs to be told to send to Debian, see man reportbug) it'll help you with all the specifics of an ITP.
[21:21] <ScottK> Yes.
[21:21] <gouki> ScottK, yes, I'm thinking about using reportbug. Thank you, I'll look into the manual.
[21:50] <fabrice_sp> DktrKranz: sru part filed for bug #283762
[21:53] <DktrKranz> fabrice_sp, thanks. I'll have a look at it later or tomorrow evening at last. If nothing happens, ping me again: I tend to forget things ;)
[21:54] <fabrice_sp> ok. thanks!
[21:55] <DktrKranz> fabrice_sp, get ready to upload a rebuild for jaunty too when archive opens (unless autosync happens)
[22:17] <pochu> jibel: hi :) JFYI, we support upgrades of dbg packages
[22:17] <pochu> jibel: (as they are in the archive, and we support everything in the archive)
[22:22] <james_w> pochu: hey, is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=500468 fixed?
[22:22] <james_w> pochu: it appears you didn't main -done, so it wasn't closed, but your Version: pseudo-header suggests you meant it to be
[22:27] <jibel> pochu: Hi, I've seen your comment. I'm sorry about this mistake.
[22:35] <pochu> jibel: np :) thanks for triaging bugs ;)
[22:35] <pochu> james_w: hey, looking at it
[22:36] <pochu> james_w: yeah, it should. let me check it anyway
[22:37] <james_w> thanks pochu
[22:38] <jibel> pochu: you're welcome.Thank you for maintaining packages ;)
[22:42] <pochu> james_w: yes, it's fixed. I'm properly closing the bug now, thanks for letting me know :)
[22:54] <DktrKranz> fabrice_sp, done.
[23:03]  * DktrKranz points to http://hattory.no-ip.info/sru/, it shows intrepid tasks too, waiting for ubuntuwire's to be updates
[23:14] <wgrant> Erm, UbuntuWire's *does* show Intrepid tasks.