[00:13] <serialorder> i have a question regarding updating a library package
[00:14] <serialorder> for protobuf in intrepid the library was libprotobuf0  in intrepid the current version is libprotobuf2 based on upstream version 2.0.2-1. I am trying to update the package so it is based on 2.0.3
[00:15] <serialorder> do i need to rename libprotobuf2 to something else or can it remain as libprotobuf2
[00:26] <pochu> serialorder: only rename it if the SONAME changed
[00:27] <pochu> e.g. if you have libfoo.so.2 and it changes to libfoo.so.3 with the new version, then it changed the SONAME
[00:33] <serialorder> pochu: thanks, is there a place I can look to check if that is the case?
[00:33] <serialorder> i found out by compiling but I am sure there is some easier way to tell without having to compile
[00:38] <pochu> serialorder: check out https://wiki.ubuntu.com/PackagingGuide/Recipes/CheckingLibrarySymbols
[00:38] <pochu> serialorder: but the SONAME is usually bumped in configure.ac
[00:39] <pochu> so you can do a `diff libfoo-1.0/configure.ac libfoo-2.0/configure.ac`
[00:47] <serialorder> thanks pochu
[02:54] <et3>  I want to make a package of my .bash_profile, .bash_aliases, .vimrc etc...
[02:54] <et3> Is there a way I can do that?
[02:55] <et3> I know there are theme packages...
[02:56] <et3> right now I can reinstall everything from repos except config files.
[02:57] <jmarsden> et3: The defaults are in /etc/skel, do you want to create modified packages for bash, vim, etc to include your own variant config files?
[02:58] <et3> jmarsden : it's more like I want all my ~/."${CONFIG_FILES} in one package
[02:58] <et3> like ./bash_aliases
[02:59] <et3> I suppose I could customize each individual package...
[02:59] <jmarsden> Well,  if you always use the same username everywhere, you could create a package containing them that puts them all into /home/et3/
[03:00] <jmarsden> Are you building a variant distro with this package in it?? Why does it need to be a package?
[03:00] <et3> couldn't I use the system's "~" ?
[03:00] <et3> easier to install
[03:00] <jmarsden> The system doesn't have one... you mean /root/ ?
[03:00] <et3> no...
[03:01] <jmarsden> ~ is defined as the home dir for the current user... ;)
[03:01] <et3> yeah...  That'd be the one I'd want to install the package for... but I suppose packages are meant to be a "system-wide" thing.
[03:02] <et3> ...hmmm
[03:02] <jmarsden> I just stick a tarball up on the web somewhere and then I can do   wget http://www.example.com/mytarball.tar and then tar xf mytarball.tar   and I'm done.
[03:02] <et3> I'd rather go with git
[03:02] <jmarsden> That way I have my files even on systems that are not Debian/Ubuntu based.
[03:02] <et3> and if I'm using a cvs thing, why not package it?
[03:03] <et3> good point
[03:03] <jmarsden> Not ever machine you ssh into will have git installed... will it?  But almost all will have wget or curl.
[03:03] <et3> another good point.
[03:04] <et3> What about your other files?  Do you have a packaging system for your media?
[03:04] <et3> maybe I'm just going package crazy since I learned how to make them.
[03:04] <jmarsden> For music/photos etc?  No... I don't need them to travel with me around the Internet ;)
[03:05] <et3> I plan on setting up a server for my media files.
[03:05] <ScottK> There is a package called etckeeper for putting /etc/ in a VCS.
[03:05] <et3> right now I can use filezilla... but I want to make it a browser-based thing.
[03:05] <jmarsden> If you have ssh access to it you can grab them via sshfs or (if necessary) with scp or sftp...
[03:06]  * et3 googles etckeeper
[03:06] <et3> right.
[03:08] <et3> mercurial looks cool
[03:09]  * et3 waves goodbye
[03:10] <jmarsden> Bye et3, have fun!
[03:10] <et3> jmarsden : thanks  bye ^^
[03:31] <nellery> Lutin: Hi, were you planning on doing the babel merge?
[03:51] <serialorder> when upgrading a package what needs to be provided in LP?
[03:54] <ScottK> diff.gz
[03:55] <serialorder> that is a diff between?
[03:55] <serialorder> is it a debdiff between the previous version and the upgraded version?
[03:58] <ScottK> serialorder: No.  Make the upgraded package.  A source package has the orig.tar.gz, the diff.gz, and the .dsc.
[03:58] <ScottK> The diff.gz is the only part a sponsor needs to reconstruct your package.
[03:58] <serialorder> ahh
[03:59] <ScottK> They'll fetch the orig.tar.gz themselves.
[03:59] <RAOF> Aww, man.  How do you get $(addprefix $(FOO)) to work when some of the files in FOO have spaces in their names?
[04:02] <coppro> "$(addprefix $(FOO))"?
[04:02] <coppro> or something akin to that?
[04:03] <RAOF> The function is actually $(addprefix bar/,$(FOO)), so that won't work; it'll add bar/ to the start of each space-separated component of FOO.
[04:04] <coppro> oh. That's a tough one; how do you build FOO?
[04:04] <serialorder> ScottK I dont see a diff.gz
[04:05] <serialorder> i see a .dsc,.build, .changes, .tar.gz
[04:05] <ScottK> serialorder: You've got your updated package prepared?
[04:05] <ScottK> serialorder: Then you've got a native package.
[04:05] <ScottK> serialorder: What package are you upgradingin?
[04:05] <serialorder> well I wasnt sure how to name it actually
[04:05] <serialorder> protobuf
[04:06] <serialorder> previous version was protobuf-2.0.2-1ubuntu1
[04:06] <serialorder> trying to upgrade to 2.0.3
[04:07] <ScottK> Yeah.  It shouldn't be a native package.
[04:07] <ScottK> What's the name of your tar.gz
[04:09] <serialorder> i think i messed that part up
[04:10] <serialorder> i have protobuf-2.0.3.orig.tar.gz and protobuf_2.0.3ubuntu1.tar.gz
[04:10] <ScottK> I'm guessing.
[04:10] <serialorder> i wasnt sure what to call it because the version isn't in debian yet
[04:11] <ScottK> The existing orig.tar.gz is protobuf_2.0.2.orig.tar.gz
[04:11] <ScottK> So you want protobuf_2.0.3.orig.tar.gz
[04:11] <ScottK> The revision doesn't go on the orig.tar.gz.
[04:11] <ScottK> In debian/changelog you'll want to say it's 2.0.3-0ubuntu1
[04:14] <NCommander> serialorder, pinmg
[04:14] <NCommander> *ping
[04:14] <NCommander> oh :-)
[04:14] <NCommander> serialorder, I'm test building your patch on sparc right now
[04:14] <NCommander> DO you know if the new upstream builds correctly on sparc/ia64?
[04:15] <serialorder> the new upstream fixed the sparc FTBFS but it hasnt fixed ia64 yet
[04:16] <RAOF> coppro: How do I build FOO?  FOO = file1 \ file2 \ Stupid Space Including Dir/file3 \ etc...  That will obviously have to change, but I don't know how.
[04:16] <NCommander> serialorder, I have access to both SPARC and ia64
[04:16] <NCommander> I can kick builds off on both
[04:16] <NCommander> if necessary
[04:16] <NCommander> serialorder, do you want me to sponsor the existing patch, or should we wait for the new upstream?
[04:17] <coppro> RAOF: replace each space in the arguments with "\\ "
[04:17] <coppro> (what language is that, btw?)
[04:17] <serialorder> NCommander: lets hold off, i just finished upgrading to the latest upstream
[04:18] <NCommander> oh cool
[04:18] <RAOF> coppro: Make
[04:18] <serialorder> ScottK: thanks for the help have the diff.gz now =)
[04:18] <ScottK> serialorder: You're welcome.
[04:18] <coppro> RAOF: ah. Hmm... never really gotten into that complex of Make before
[04:18] <NCommander> serialorder, if you can kick it onto REVU or into a PPA (someplace where I can get it), I can test build on both SPARC and IA-64
[04:18] <RAOF> coppro: Sorry, thought that would have been obvious from the syntax :)
[04:18] <coppro> as I said, never gotten that complex
[04:18] <serialorder> this is my first upgrade =)
[04:18] <coppro> in my experience though, escaping spaces works
[04:19] <ScottK> serialorder: Glad to have you here helping out.
[04:20] <RAOF> coppro: Yeah, escaping them doesn't work here :(
[04:22] <coppro> RAOF: you can't escape them as they go into FOO?
[04:23] <RAOF> I can escape them as they go into FOO, but it doesn't help; the escaping is undone when FOO is processed by $(addprefix
[04:25] <coppro> oh
[04:25] <coppro> double-escaping?
[04:33] <serialorder> NCommander: protobuf is now on REVU
[04:34]  * NCommander wanders over to REVU
[04:34] <NCommander> serialorder, link?
[04:34] <serialorder> NCommander: http://revu.ubuntuwire.com/details.py?package=protobuf
[04:35] <NCommander> serialorder, I already see a mistake
[04:35] <NCommander> YOu forgot to change a depends :-)
[04:35] <serialorder> doh
[04:35] <NCommander> lintian is your friend
[04:36] <NCommander> serialorder, did you try test building in pbuilder or a PPA?
[04:38] <coppro> anyone up for a REVU of my package?
[04:39] <serialorder> oh, i see the mistake
[04:39] <serialorder> sorry
[04:39] <serialorder> haven't used lintian before, actually haven't heard of it before, must have missed that wiki page
[04:41] <jmarsden> serialorder: https://wiki.ubuntu.com/PackagingGuide/Complete
[04:56] <serialorder> NCommander: I think I fixed all the problems, also test built with pbuilder and installed  http://revu.ubuntuwire.com/details.py?upid=4284
[04:56] <NCommander> execellant!
[04:57] <NCommander> serialorder, did you toss the ia64 fix in?
[04:57] <NCommander> ah
[04:57] <NCommander> yup
[04:58] <NCommander> I'll testbuild on bot sparc and amd64
[04:58] <serialorder> i did and now im going to go report that upstream
[04:58] <NCommander> sparc build started
[04:59] <serialorder> not amd64, ia64
[04:59] <NCommander> no, both
[04:59] <NCommander> my ia64 is slow
[04:59] <NCommander> So I'm not going to bother test building on it unless its really necessary
[05:00] <NCommander> uh
[05:00] <NCommander> This script requires setuptools version 0.6c8 to run (even to display
[05:00] <NCommander> THat's not going to work
[05:01] <NCommander> Buildds do builds as non-root, and don't have internet connectivity
[05:01] <NCommander> I'll fix it if I can
[05:03] <serialorder> it was like that in 2.0.21ubuntu1 and those built fine except on ia64 and sparc
[05:04] <NCommander> It pulled in the pbuilder root for me
[05:04] <NCommander> I'm just adding the explicate build-deps
[05:05] <ScottK> NCommander: We do patch setuptools to not pull stuff from the internet that's already installed, so that should do it.
[05:05] <NCommander> I didn't have setuptools installed :-)
[05:05] <NCommander> The build-dep wasn't there at all
[05:06] <NCommander> it works fine if setuptools is installed
[05:17] <serialorder> NCommander: is there anything else i need to do now?
[05:18] <NCommander> I got a test suite failure ...
[05:18] <NCommander> It went boom on amd64
[05:18] <NCommander> which caused an FTBFS
[05:19] <NCommander> serialorder, http://paste.ubuntu.com/87553/
[05:19] <NCommander> serialorder, I won't upload it since that test suite failure will break the build on amd64
[05:20] <NCommander> serialorder, I left a comment on REVU
[05:20] <serialorder> so then should we just patch the current version?
[05:30] <coppro> pbuilder is stupid; it insists on using hardy
[05:30] <coppro> how do I tell it I want intrepid?
[05:31] <ScottK> Depends on how you set it up.
[05:31] <jmarsden> https://wiki.ubuntu.com/PbuilderHowto
[05:31] <coppro> wait, I think I figured it out
[05:35] <serialorder> NCommander: I checked and that but has been reported upstream but there is not fix. I am thinking maybe we should just patch version 2.0.2-1 and hold off on the upgrade
[05:36]  * NCommander falls over
[05:38] <serialorder> yeah your telling me, spent all day trying to figure out how to do an upgrade =|
[07:07] <Koon> good morning
[07:08] <serialorder> NCommander, ping
[07:08] <NCommander> serialorder, semi-pong
[07:09] <serialorder> actually found a fix  build failure, but i can save it for tomorrow if necessary
[07:09] <NCommander> the amd64?
[07:09] <serialorder> yeah
[07:09] <serialorder> built it on PPA and it built fine
[07:10] <NCommander> I'll upload
[07:10] <NCommander> link to your PPA
[07:10] <NCommander> serialorder, stupid question, are you using a patchsystem?
[07:10] <serialorder> no, there was no patch system in place
[07:10] <serialorder> so ive just been modifying source
[07:10]  * NCommander normally perfers if you add one in that case
[07:11] <NCommander> Which makes merging it a headache later on
[07:11] <NCommander> a very big headache
[07:11] <NCommander> :-/
[07:11] <serialorder> i see, i got scolded when i first started for adding a patch system
[07:11] <NCommander> Who scolded you?
[07:11] <persia> Well, except when the maintainer decides to add a different patch system ...
[07:11] <NCommander> Oh, the package had a patch system already?
[07:11] <serialorder> jwestby
[07:11] <NCommander> If the package has a patch system, use that
[07:11] <NCommander> if it doesn't have one, add one, or at least that's what I do
[07:12] <serialorder> there was none so i added one
[07:12] <serialorder> but then i was told not to
[07:12] <NCommander> Did this happen on IRC or a bug?
[07:12] <persia> NCommander, Please don't, unless you know that the maintainer in Debian prefers a given patch system, and you are adding that one.
[07:12] <NCommander> persia, and then it becomes a pain when you need to carry your changes forward another revision because the debian developer didn't take your patches
[07:12] <NCommander> persia, because then you need to find the changes, and reapply them
[07:13] <serialorder> https://launchpad.net/~serialorder/+archive
[07:13] <serialorder> there is my PPA
[07:13] <persia> NCommander, Well, if you are adding lots of unrelated changes, and you don't want to use a VCS, I suppose I could support that, but in the vast majority of cases, it adds unnecessary complication.
[07:14] <NCommander> cdbs-simple-patch system is one line in rules, and possibly one additional build-dep
[07:15] <persia> Hrm?  If a package already uses CDBS, it's small enough.  Adding cdbs as a build-dep can cause confusion.
[07:15]  * NCommander sighs
[07:16] <NCommander> A difference of opinion. I personally feel that the weight of a patch system is worthwhile since it makes it possible to find patches easily and tweak them if need be
[07:16] <persia> Oh, I do as well.  I'm just opposed to *adding* one if it's not previously in use.
[07:17] <NCommander> And that's where we disagree
[07:17]  * NCommander has issues with people changing inplace patch systems
[07:18] <NCommander> persia, right now, I'm looking at the debdiff, and I can't tell at all what was or was not added
[07:18] <persia> Which debdiff?  I suspect there is one that shows the specific set of changes that might be more useful to generate.
[07:19] <NCommander> persia, its a new upstream version
[07:19] <NCommander> which also needs patches
[07:21] <NCommander> serialorder, it looks good so far, I'm just doing a second test build so I can run lintian on the binaries
[07:21] <persia> Ah, then debdiff isn't the useful diff :)  Anyway, I'll walk you through useful diff generation if you like, but I suspect you've already gone far enough with this one as to make it not matter.
[07:22] <NCommander> persia, sure, I'd apperiate that
[07:22] <persia> OK.  Which package?
[07:22] <serialorder> i wouldn't mind such a lesson either
[07:23] <NCommander> persia protobuf
[07:23] <NCommander> serialorder, just so we're clear, you do know how to use a patch system, right?
[07:23]  * NCommander would be willing to teach that for future reference
[07:23] <persia> And it's a new pull from upstream, a merge from Debian, bugfixes, what?
[07:23] <serialorder> i have added a dpatch system once before
[07:24] <NCommander> merge with Debian with new upstream
[07:24] <persia> OK.  Let me get some files then.
[07:25] <NCommander> serialorder, good
[07:25] <NCommander> the only patch system thats very different is quilt
[07:26]  * persia is confused.  sid has 2.0.2-1 and jaunty has 2.0.2-1ubuntu1
[07:27] <serialorder>  2.0.2-1ubuntu1 didnt build on sparc and upstream (as in google) fixed that problem in 2.0.3
[07:27] <NCommander> the version to be uploaded is 2.0.3-0ubuntu1
[07:27] <persia> OK.  So not a merge from Debian: just a new upstream version.
[07:27] <NCommander> I thought we were also merging stuff from Debian
[07:29] <NCommander> serialorder, it looks good
[07:29]  * NCommander grabs his GPG key
[07:30] <NCommander> persia, any objections if I upload this now? (I already reviewed his changes by checked the diff.gz :-))
[07:31] <persia> NCommander, no objections, if you think it's good.  My only point was about patch systems, and reviewing methods.
[07:31]  * NCommander nods
[07:31] <NCommander> serialorder, upload in progress
[07:32] <persia> Anyway, `debdiff protobuf_2.0.2-1.dsc protobuf_2.0.2-1ubuntu1.dsc` shows that the previous changes were just build-dependencies from Debian.
[07:32] <NCommander> right but debdiffing against a new upstream is pointless
[07:32] <persia> As a result, we would expect the changes in the diff.gz to be broadly similar between 2.0.2 and 2.0.3
[07:34] <NCommander> is this a case where you use interdiff between both diff.gz's?
[07:34] <persia> `lsdiff -z protobuf_2.0.2-1ubuntu1.diff.gz` and `lsdiff -z protobuf_2.0.3-0ubuntu1.diff.gz` have about the same list of stuff: the interesting patch appears to be inpython/google/protobuf/internal/decoder_test.py
[07:34] <persia> Yep :)
[07:34] <NCommander> oooh
[07:34] <NCommander> I didn't know about lsdiff
[07:34] <NCommander> Now THAT's handy
[07:35]  * NCommander waits for the accepted email
[07:35] <persia> `interdiff -z -p1 protobuf_2.0.2-1ubuntu1.diff.gz protobuf_2.0.3-0ubuntu1.diff.gz` shows the relevant changes
[07:35] <NCommander> still not ideal, but I can dig it :-)
[07:35] <NCommander> serialorder, [ubuntu/jaunty] protobuf 2.0.3-0ubuntu1 (Accepted)
[07:35] <NCommander> serialorder, Thank you for your contribution to Ubuntu
[07:36] <serialorder> NCommander, awesome thanks
[07:36] <persia> The first interesting bit is that it referes to libprotobuf3 rather than libprotobuf2, which makes me wonder about compatibilitity with rdepends
[07:37] <NCommander> persia, we have nothing that uses it expect protobuf itself ;-)
[07:38] <persia> Just pointing things out: like I said, I'm not objecting to the upload, nor have I reviewed it in detail.
[07:38]  * NCommander nods
[07:39] <NCommander> serialorder, anyway, nice job on your first package update
[07:39] <persia> control seems updated to use the new name, so that's all good.  Next interesting thing is that the maintainer scripts seem to have dropped the ldconfig call.
[07:39] <persia> And then we get to the actual source patches
[07:40] <persia> Later we see the maintainer scripts were only a side effect of the binary name change (this will need binary NEW)
[07:40] <NCommander> serialorder, do you know about the NEW queue?
[07:41] <persia> And the most exciting bit is that neither the build-depends patch nor the 64-bit patch from Debian appears in the interdiff, which means they are preserved.
[07:42] <NCommander> serialorder did a good job on the update
[07:42] <serialorder> thanks, it took a long time =)
[07:42] <serialorder> i don't know about NEW, remmeber reading about it somewhere
[07:42] <NCommander> Ok
[07:42] <persia> Another interesting thing to do sometimes is to pipe the interdiff output through lsdiff, which shows a list of all the files changed by a given revision.
[07:43] <serialorder> might have had to reorganize my firefox bookmarks because of all the MOTU wiki bookmarks i made recently
[07:43] <NCommander> Every NEW package gets stuck in a special holding area called the NEW queue
[07:43] <NCommander> new source packages don't even get built, and packages with new or changed binaries (such as the updated version) get built, but not published
[07:43] <NCommander> They get stuck in a queue until an archive admin creates overrides to allow them to proceed into the archive
[07:44] <NCommander> serialorder, https://edge.launchpad.net/ubuntu/jaunty/+queue?queue_state=0&queue_text= you can see the new queue, and your package in it
[07:48] <serialorder> ubuntu packaging is way more fun than my dissertation =)
[07:52] <dholbach> good morning
[08:36] <soren> nhandler: Wazzup?
[08:41] <alex_21> Nothing
[08:41] <alex_21> I was going to build a package but found something that works as well
[08:42] <alex_21> And BTW: how do you get a very basic Gome install onto Ubuntu Server and tell it to start at system startup?
[08:46] <alex_21> Well thanks for your help
[08:46] <alex_21> Good night. Bani bash
[09:09] <dholbach> stgraber: thanks a lot - posted! :)
[09:16] <dholbach> nhandler: CONGRATULATIONS!
[09:23] <Laney> go nhandler!
[09:23]  * Laney waves pompoms
[09:23] <ara> nhandler: congratulations!
[09:23] <Laney> *\o/*
[09:23] <dholbach> yooohoooo! :)
[09:26] <zerwas> who has birthday?
[09:26] <dholbach> zerwas: nhandler just joined the MOTU team :)
[09:26] <zerwas> ah, well. congratulations :D
[09:54] <pochu> stgraber: congrats :-)
[09:54] <pochu> nhandler: likewise!
[09:55] <\sh> stgraber/nhandler: welcome on board...
[10:09] <didrocks> congrats nhandler :)
[10:57] <quadrispro> dholbach, thanks for your reply to my U-U-S application :)
[10:59] <Laney> dholbach: You uploaded bakery! YAY!
[10:59] <Laney> quadrispro: u-u-c? ;)
[10:59] <quadrispro> Laney, yes :D
[11:00] <quadrispro> dholbach, s/U-U-S/U-U-C
[11:01] <Laney> the final piece of my glom puzzle is almost complete
[11:10] <dholbach> quadrispro, Laney: no worries :)
[11:13] <quadrispro> anyone on bug #296398?
[11:59] <ScottK> nhandler: Congratulations.
[12:02] <jack_> can you build and upload packages for Ubuntu if you're not a MOtu (yet)?
[12:03] <persia> jack_, Prepare, but not upload.
[12:03] <jack_> persia, ok what do you mean by prepare?
[12:03] <persia> jack_, Generally, one prepares fixes for a while, and works with the sponsors to get them uploaded.  See https://wiki.ubuntu.com/MOTU/Contributing
[12:04] <persia> jack_, Make any adjustments as if one were uploading, and then show the patch for these changes to the sponsors
[12:04] <jack_> persia, and new packages, which are not yet in ubuntu?
[12:05] <persia> One generally submits those to REVU.  See the bottom of the link.
[12:08] <jack_> is it better to build a package from a debian unstable package or just from tar.gz?
[12:10] <persia> jack_, If it's in Debian unstable, and it's not in Ubuntu, it will be in a few days.
[12:10] <jack_> persia, ok
[12:10] <directhex> hmph. openjdk-6-source-files is incomplete
[12:10] <persia> This will continue to be true until 25th December.
[12:12] <directhex> where's a javaish person when you need one? /me prods persia
[12:12] <handschuh> jack_: see https://wiki.ubuntu.com/SyncRequestProcess for requesting a sync manually (that might be no neccessary in this case but it is good to know)
[12:12] <nhandler> Well, I just got up. Thanks everyone for the congratulations.
[12:12] <handschuh> nhandler: congrats! it was about time
[12:13] <persia> directhex, Do you have a bug number?
[12:13] <directhex> persia, no. it might be intentional!
[12:14] <directhex>                  [exec] javac: file not found: ../../openjdk-b13/control/build/linux-i586/gensrc/com/sun/accessibility/internal/resources/accessibility.java
[12:14] <directhex> can't find a accessibility.java anywhere
[12:15] <persia> directhex, What's the result of this error?
[12:17] <directhex> well, i can't build this app, that's what. i'm wondering how feasible it is to actually use system source packages
[12:18] <directhex> erk, compiling it eats all my RAM ^_^
[12:20] <persia> Hmm.  Unfortunately, I'm not sure enough of the specifics to provide advice.  I'd recommend asking slytherin or doko
[12:21] <directhex> i can see why this package's maintainer orphaned it
[12:45] <sebner> nhandler: congratulations also from me =)
[12:45] <nhandler> Thanks sebner!
[12:54] <norsetto> congrats nhandler!
[12:54] <nhandler> :)
[12:55] <norsetto> nhandler: now, start uploading crack to the archive :-D
[12:56] <nhandler> norsetto: You need 2 MOTUs to ack a new package, you know that ;)
[13:15] <NCommander> soren, upstream's solution was to unplug the test suite, there is a warning label that it will not work correctly on non-intel architectures
[13:15] <NCommander> er, Debian's
[13:16] <NCommander> er
[13:16]  * soren likes how "solution" can be interpreted so very broadly.
[13:16] <NCommander> wrong channel
[13:19] <zul> thats why he has his own target audience
[13:21] <sebner> nhandler: crack can also be merges :P
[13:34] <ScottK> sebner: I'm pretty sure he, of all people, knows that already.
[13:36] <sebner> ScottK: sure, that was more something like a joke because he immediately refered to REVU after norsetto told him to upload stuff
[13:36] <ScottK> sebner: Yes, I'm just continuing it (and failing apparently).
[13:37] <sebner> ScottK: you should use a smiley like I did :P
[13:37] <ScottK> Too early in the morning for smileys (still on the first cup of coffee).
[13:39]  * sebner is glad to never get up too early in the morning :)
[14:16] <norsetto> morning ScottK , hi sebner
[14:16] <sebner> heya norsetto =)
[14:16] <ScottK> Hello norsetto
[14:21] <DaveMorris> question regarding packaging for libraries.  I've previously packaged up opensg 1.8 which has been accepted since hardy.  Now the new version is been worked on (2.0) which has major api/abi changes.  The easy option would be to conflict them, however it would be nice to have them installed in parallel. Which can easily be done with the headers etc, however I'm unsure as to what I should do with the libs to enable this to happen.  Are there an
[14:22] <azeem> DaveMorris: your line got cut off at "Are there an[...]"
[14:22] <persia> DaveMorris, Have -dev use the new one, and have differing package names for the libs packages.
[14:22] <DaveMorris> Are there any packages which I can look at as examples for this?
[14:23] <azeem> DaveMorris: did the filename of the library change?
[14:23] <DaveMorris> azeem: no
[14:23] <azeem> from /usr/lib/libfoo.so.0.0.0 to /usr/lib/libfoo.so.1.0.0, e.g.
[14:23] <azeem> DaveMorris: what is the filename?
[14:24] <DaveMorris> they don't produce the version part of the so, I did it within the packagin script
[14:24] <DaveMorris> so I guess I need to change that so it's diff
[14:24] <azeem> why did you choose 1.0.0?
[14:25] <DaveMorris> I'm unsure, it may have been suggest to me
[14:25] <DaveMorris> I guess it needs chaning to 1.8 then
[14:25] <azeem> eh
[14:25] <azeem> no
[14:25] <azeem> are there any reverse-Depends for libopensg-core1?
[14:26] <DaveMorris> not in Ubuntu (apart from the others flibs built from that source package)
[14:26] <persia> DaveMorris, Are you expecting new users to want them installed in parallel, or just current users?
[14:27] <DaveMorris> just current users
[14:27] <azeem> what users are there?
[14:27] <DaveMorris> who don't want to port their applications, but want to fix the bugs etc
[14:27] <azeem> users as-in, applications using this libaray
[14:27] <persia> OK, if it's just current users, then you can use the same source package name (which makes it easier).
[14:27] <DaveMorris> mainly research projects in different users
[14:27] <DaveMorris> s/users/unis
[14:28] <persia> azeem, Rather, users being installed systems.
[14:28] <azeem> persia: hrm? DaveMorris said there are no reverse dependencies of those libraries, so I wondered which applications need them
[14:28] <persia> DaveMorris, Oh, so you do have users who want to recompile against a selected version, and not be upgraded?
[14:28] <DaveMorris> yes
[14:29] <DaveMorris> I guess I can point them at the right so via pkg-config
[14:29] <persia> DaveMorris, In that case, you need to have multiple versioned source packages.  See e.g. wxwindows2.6 + wxwindows2.8.  Also, these tend to get rejected without very compelling reasons, so you might want to first package something that can't easily be migrated.
[14:30] <persia> azeem, Remember that the archives don't yet include all available software.  While we only support that in the archives, when working with libraries, it is also useful to consider the uses to which it may be put external to the archives.
[14:30] <RainCT> anyone knows which application this is? http://launchpadlibrarian.net/20543025/WindowManager_screenshot.png
[14:30] <DaveMorris> sorry, I don't understand what you mean by " you might want to first package something that can't easily be migrated."
[14:30] <azeem> persia: right, that was my question
[14:31] <persia> DaveMorris, Essentially, when we have multiple source packages providing the same library, it's harder for the security folks, and we have to keep track of which ones are still active, and which can be dropped.  This is a bunch of extra work.
[14:32] <DaveMorris> so you'd rather I just dropped the old one and did the new one
[14:32] <persia> So, it's nice to have something to justify the extra work: some someware which requires that extra work to be supported.
[14:32] <persia> Yeah: that makes it easier.  You'll want to have a new binary name, and a new soversion if they are incompatible.
[14:33] <persia> Then, advise users that need the older version to compile against hardy or intrepid, and users that want the newer version to compile against jaunty.
[14:33] <DaveMorris> so libopensg-core1 would move to libopensg-core2 but  libopensg-core-dev will stay the same
[14:33] <azeem> yes
[14:33] <persia> That's the ideal solution, from a distro-maintenance perspective.
[14:34] <DaveMorris> that sounds reasonable to me, since hardy will stay around for a while, if they want it after that they can build the software themselves
[14:36] <persia> Right.  For widely used libraries, with a large number of reverse dependencies, it sometimes becomes worth carrying two versions of the library source in the archive to reduce porting pressure, but without the rdepends, there's just not a lot of incentive.
[14:53] <norsetto> RainCT, that link doesn't seem to be working
[15:00] <RainCT> norsetto: Here it works. But well, isn't that important.
[15:02] <norsetto> RainCT, hmmm, I think I know why, I just downloaded the newer firefox update
[15:08] <bddebian> Heya gang
[15:13] <RainCT> norsetto: I have it too :)
[15:38] <RainCT> norsetto: ah, right, you need to restart
[15:39] <RainCT> norsetto: I too was sorta "wtf??" for the first seconds when it refused to load any page :P
[15:46] <norsetto> RainCT: :-) I ALWAYS forget that ....
[15:53] <iulian> nhandler: Congratulations.
[17:45] <slytherin> what is the way to specify multiple bugs in one line in debian/changelog?
[17:48] <pochu> slytherin: lp: #1234, #12345, #123...
[17:49] <slytherin> pochu: thanks
[18:09] <slytherin> calc: ping
[18:25] <calc> slytherin: hi
[18:26] <slytherin> calc: libitext-java has depwait in latest version due to libbcprov-java being in universe. Will you add libbcprov-java to the list of packages to be promoted to main for OOo?
[18:34] <calc> slytherin: probably should file a bug against libitext-java and subscribe ubuntu-mir to it since it is already in main
[18:34]  * calc isn't sure what is normally done for packages that are sync's that gain more deps
[18:34] <slytherin> calc: you mean file bug against libbcprov-java, right?
[18:35] <slytherin> calc: anyway, I thought I would tell you since you are handling MIR for all new OOo dependencies.
[18:35] <calc> i filed the bug
[18:35] <calc> hmm maybe i'm not sure
[18:35] <calc> i'll reassign to libbcprov-java
[19:10] <slytherin> RainCT: I am motu now. Can you please give me the powers on revu. :-)
[19:59] <loic-m> Hi. I'm trying to backport a package from jaunty to intrepid (and paybe later to hardy)
[19:59] <loic-m> The package builds well and works ok, now I'm trying to do it well
[20:00] <loic-m> I get the source with lget, then dpkg-source -x  and dch -i, update the changelog
[20:01] <loic-m> however when I debuild -S then pbuild it, it says it's building packages for jaunty
[20:02] <directhex> loic-m, does it say jaunty on the top line of changelog?
[20:04] <loic-m> no, I changed it to intrepid-backports
[20:04] <loic-m> when doing dch -i (then chosed nano, CTRL-O then CTRL-X and I checked the changelog was changed
[20:16] <bbs> where can i find a good example of the use of the policy tool
[20:16] <bbs> i was told i can come in here
[20:17] <bbs> or where can i find the whole prerolled java-jre debian file
[20:17] <bbs> so that i can modle off of it
[20:17] <ScottK> bbs: There is also #ubuntu-java for Java specific questions.
[20:18] <bbs> this isn't java specific
[20:18] <bbs> this is packaging
[20:18] <bbs> i need to find a wayt o pop up the terms of use notifier for synaptic
[20:18] <bbs> i have never packaged a deb before
[20:18] <bbs> :)
[20:18] <bbs> and a good example / documentation of making debs
[20:18] <bbs> i wanted to know if there is an ubuntu specific set of documentation vs. debian
[20:20]  * bbs googles
[20:20] <Pici> !packaging
[20:30] <loic-m> !backports
[20:42] <bbs> Pici: thanks
[20:42] <bbs> the problem here is this is a company
[20:43] <bbs> and the only thing provided is a binary
[20:43] <bbs> so there is no compilation
[20:43] <bbs> really just properly moving the binary and init scripts to thier proper locations
[20:43] <bbs> and popping up our terms of service
[20:48] <ScottK> bbs: Look in the Canoncial partner repository.  Some of the non-free stuff they have there does exactly that.
[20:48] <bbs> ScottK: kk where is that stuff :)
[20:48] <bbs> sry i'm a debian nood
[20:48] <bbs> noob
[20:49] <bbs> but i know how to program and script well
[20:51] <ScottK> bbs: Look for the deb-src line for partner in /etc/apt/sources.list
[20:52] <loic-m> Ow does one pbuild packages for Intrepid or Hardy instead of the default (jaunty)?
[20:59] <bbs> ScottK: i don't have an ubuntu installation
[20:59] <ScottK> Oh.
[21:01] <ScottK> bbs: http://archive.canonical.com/ubuntu/
[21:10] <bbs> ScottK: just booted a live cd
[21:10] <bbs> thx for link too
[21:10] <bbs> ScottK: i only see dapper and edgy -commercial delineations
[21:11] <ScottK> bbs: Partner is what you want for newer
[21:12] <bbs> in dists pool or projects
[21:12] <bbs> sry for stupidity
[21:14] <bbs> so pool
[21:14] <bbs> partner
[21:14] <bbs> thx
[21:30] <RainCT> btw, what was decided to do with Ctrl+Alt+Backspace?
[21:31] <RainCT> (iirc there was a topic about it at UDS)
[21:33] <loic-m> The new xorg GUI option editor will allow setting the option or removing it for users that can't edit their xorg.conf
[21:33] <ScottK> RainCT: Go with off by default (new upstream default) and a GUI way to revert to useful behavior
[21:34] <norsetto> ScottK, what is upstream in this context, xorg or?
[21:34] <loic-m> xorg
[21:34] <ScottK> norsetto: As loic-m says
[21:34] <RainCT> Cool, thanks.
[21:34] <ScottK> You can probably tell I have an opinion on the matter.
[21:35] <loic-m> loic-m loves his CTRL-ALT-BACKSLASH
[21:35] <norsetto> right, so instead of fixing the rendering to pixmap mess that just play with that ... grrrrr
[21:35] <RainCT> ScottK: yes, I prefer the the proposal to show a warning the first time you press it and restart X at the second hit
[21:42] <sebner> RainCT: I suppose you can't press 3 keys accidently O_o
[21:42] <RainCT> sebner: oh, it happened to me more than once :P
[21:44] <RainCT> and beside my madness, new users don't know that ctrl+alt+backspace is evil
[21:44] <pochu> I like the proposal of hitting it 3 times in a row for it to work
[21:44] <jpds> sebner: Some people do appartently.
[21:44] <sebner> O_o
[21:44] <pochu> or to hold them for 2 seconds
[21:45] <sebner> pochu: I wouldn't have a problem with 2 seconds
[21:45] <sebner> but hitting that 3 times
[21:45] <sebner> :\
[21:45] <mgdm>  my machine at work sometimes requires that... :)
[21:45] <sebner> Besides I use it hardly
[21:45] <pochu> sebner: well, you press ctrl+alt, then with the other hand you press del 3 times :)
[21:46] <mgdm> There's a bug somewhere in Compiz and the nVidia drivers which sometimes causes Compiz.real to chew 60% of RAM, and to stop responding to ctrl-alt-backspace
[21:46] <pochu> it's not that annoying IMHO
[21:46] <sebner> pochu: I still can't believe that some users press it accidently  ^ ^
[21:47] <quadrispro> anyone on bug 292696?
[21:47] <sebner> quadrispro: I just uploaded the fix for jaunty as you might know but I thought you claim to do the rest
[21:48] <sebner> or do you think of sponsoring?
[21:49] <quadrispro> sebner: yes, I'm looking for a sponsor for SRU, but I have to ask you another thing :) -> http://revu.ubuntuwire.com/details.py?package=uck
[21:49] <sebner> debian-upstream folder? urgh
[21:49] <wgrant> I often used to press it manually, by flipping between Compiz desktops and hitting backspace in a terminal for some reason I don't recall now.
[21:49] <RainCT> sebner: you don't believe I exist? *g*
[21:49] <wgrant> s/manually/accidentally/
[21:50]  * RainCT ponders sponsoring something
[21:51] <sebner> RainCT: hehe. I think I pressed it accidently at my beginning ubuntu time. Maybe it's only me but normal users don't press 3 keys at the same time that often
[21:51]  * sebner only killed his b0rken games with xserver restart ^ ^
[21:51] <wgrant> sebner: Compiz. Switching desktops.
[21:52] <wgrant> That takes you two thirds of the way there very often.
[21:52] <sebner> wgrant: but cursor keys are less dangerous than delete key :P
[21:53] <quadrispro> sebner: yes, debian-upstream... can I remove it?
[21:53] <RainCT> sebner: but you're pressing Ctrl+Alt.. then delete something after that
[21:54] <RainCT> sebner: well, I guess you can't type as fast as us and that's why you have no problem! *g*
[21:54] <sebner> quadrispro: you can repack the tarball but it's usually a good idea to teach upstream to not do our business  ^  ^
[21:54] <sebner> RainCT: bah :P
[21:55] <RainCT> is there any Python thingie to sponsor?
[21:57] <RainCT> nellery: is the .diff.gz at bug #256267 ready to upload?
[21:57] <quadrispro> sebner: I'm in touch with upstream author, I'm asking him to remove debian from svn trunk, however I m going to remove it from tarball
[21:58] <sebner> quadrispro: last tipp. remove the 2-3 unnecessary newlines in debian/rules. now I'm too tried and go to bed :P
[21:59] <goshawk> hi
[21:59] <quadrispro> sebner: thank you very much ;)
[22:01]  * sebner testbuilds uck to find some lintian warnings to throw at quadrispro :P
[22:02] <goshawk> if somebody has free time, can review http://revu.ubuntuwire.com/details.py?package=dsss please? thanks
[22:03] <quadrispro> sebner: *cough cough* -> http://home.alessiotreglia.com/jaunty/result/uck_2.0.5-0ubuntu1/uck_2.0.5-0ubuntu1_amd64.build
[22:03] <sebner> quadrispro: aha!
[22:03] <quadrispro> sebner: and http://home.alessiotreglia.com/jaunty/result/uck_2.0.5-0ubuntu1/
[22:03] <sebner> quadrispro: sebner@ubuntu:~/Desktop/uck-2.0.5$ licensecheck -r .
[22:03] <sebner> ./libraries/gui.sh: GPL (v2)
[22:03] <sebner> ./libraries/remaster-live-cd.sh: GPL (v2)
[22:03] <sebner> debian/copyright only says GPL-3
[22:04] <quadrispro> sebner: noooooooooo! :(
[22:04] <quadrispro> uff
[22:04] <sebner> quadrispro: and copyright in gui.sh says 2006-2007
[22:04] <quadrispro> ok, working on it...
[22:05] <jpds> RainCT: If you want to sponsor something, can you look into python-crontab on revu?
[22:05] <sebner> quadrispro: also in remaster*.sh it's 2006-2007
[22:05] <RainCT> jpds: sure
[22:06] <sebner> uck only consists of shell scripts. funny
[22:08] <sebner> RainCT: every source file in uck is gpl3 expect 2 files that are gpl2. COPYING is GPL2. Does upstream also has to ship a copy of gpl2 then?
[22:08] <DRebellion> If anybody is looking to revu something, could I point them towards http://revu.ubuntuwire.com/details.py?package=cifer ?
[22:09] <sebner> RainCT: COPYINg is GPL3 I mean.
[22:09] <sebner> DRebellion: I'll check tomorrow and reACK then
[22:09] <DRebellion> sebner, great :D
[22:09] <sebner> DRebellion: though I don't see any benefit of the debhelper update :P
[22:10] <DRebellion> sebner, me neither. Oh wellz...
[22:10] <sebner> nvm
[22:10] <quadrispro> sebner: license is GPL-3, copyright in those files are wrong
[22:10] <sebner> quadrispro: so he has to relicense that
[22:10] <sebner> or correct
[22:10] <sebner> whatever
[22:11] <quadrispro> sebner: yes, I'm asking upstream to make all the corrections
[22:11] <sebner> quadrispro:         ßo/
[22:12] <RainCT> sebner: yes
[22:12] <RainCT> sebner: if it's "only GPl2"
[22:12] <RainCT> sebner: if it's "GPLv2 or later" then just GPL-3 is fine
[22:13] <sebner> RainCT: cool thx. It was a mistake by upstream btw =)
[22:14] <RainCT> sebner: then clarifying it in debian/copyright and pointing to a statement from upstream *may* be enough
[22:14] <sebner> RainCT: *may* :) , he has to do other stuff as well so now worries
[22:15] <sebner> *now = no
[22:18] <loic-m> Are people still using pbuilder-ubuntu (where ubuntu is any ubuntu release) and if yes does anyone know where to find the script?
[22:19] <sebner> loic-m: dunno. /me uses pbuilder --create --distribution jaunty
[22:20]  * sebner goes to bed. gn8 folks
[22:20] <ScottK> loic-m: I think pbuilder-dist-simple (or some such) in ubuntu-dev-tools
[22:21] <loic-m> Thanks. pbuilder-ubuntu was the first tool I used to build packages (for feisty), but it's been deleted in one of many upgrades on my hd. Before I use it again, is it still an advised option?
[22:22] <ScottK> I still use it.
[22:24] <emet> there are people having MD5 errors with the flash installer, could it be possible that Adobe change the binary?
[22:30] <loic-m> thanks ScottK, I found the script as /usr/share/doc/pbuilder/examples/pbuilder-distribution.sh
[22:31] <ScottK> loic-m: I think the difference between that one and the one I was pointing you too is the other is set up to have Universe enabled by default.
[22:36] <loic-m> I couldn't find pbuilder-dist-simple with a locate
[22:36] <loic-m> Ok, just found it with find sorry
[22:39] <RainCT> loic-m: pbuilder-dist and pbuilder-dist-simple are in ubuntu-dev-tools (and are installed into /usr/bin/)
[22:41] <loic-m> Thanks, I'm pbuilding-intrepid create atm ;)
[22:52] <RainCT> alright, I've rejected a package.. now I'm happy ;P
[22:53]  * Hobbsee rejects RainCT
[22:53] <RainCT> :(
[22:55]  * Hobbsee puts RainCT back in the new queue
[22:56] <RainCT> Hobbsee: you should relax a bit from your admin work :P
[22:57] <bbs> ScottK: i'm all set and working now -- one last question for you
[22:57] <Hobbsee> RainCT: hehe, i have been :P
[22:57] <bbs> is there actual documentation for handling "rules" for binaries
[22:57] <loic-m> Thanks ScottK, thanks RainCT, I managed to build amd64 and i386 packages (ended up using pbuilder-dist to get i386 packages), now I can fill the backport request !
[22:57] <Hobbsee> RainCT: i've been using my buildd admin hat for a while
[22:58] <bbs> or actual rules for handling *.debs that are like the adobe-flash-player -- where its a single binary and its just cp /desired/install/dir : uninstall rm /desired/install/dir/binary
[22:58] <loic-m> Is it ok for the backported packages to end up with -1ubuntu2 (Intrepid) when the jaunty package was -1ubuntu1?
[23:07] <bbs> +++ parallels-2.2.2232/debian/parallels.templates
[23:07] <bbs> i need to do something like that^^^^
[23:07] <bbs> where it pops up in synaptic
[23:07] <bbs> the whole other thing works beautifully
[23:11] <serialorder> a packaged i am merging depends on inetd-superserver but I cannot find such a package. I see it is a debian virtual package but i cannot find it in ubuntu. Am I missing something?
[23:12] <bbs> serialorder: do you have multiverse and all of those things installed
[23:13] <bbs> the defaults only seem to be the openbsd-inetd and the xinetd
[23:14] <serialorder> i havent tried installing yet, i just did a search for it at packages.ubuntu.com didn't see it there
[23:14] <RainCT> good night
[23:17] <serialorder> nm found it
[23:29] <skorasaurus> hi, i'm compiling a package. when i issued debuild, i received several errors, here is what debuild returned: http://pastebin.ca/1288869\
[23:29] <skorasaurus> http://pastebin.ca/1288869
[23:30] <skorasaurus> it appears that gtk is not installed, but im not sure which gtk package i am missing.
[23:32] <mrooney> anyone know how I might debug this python-central issue for my package? http://pastebin.ca/1288875
[23:42] <skorasaurus> mrooney, sorry i don't know.
[23:57] <blueyed> skorasaurus: libgtk2.0-dev maybe?
[23:57] <skorasaurus> blueyed, will I have to install that ?
[23:57] <blueyed> yes. Try "apt-cache search libgtk | grep -- -dev" for more
[23:59] <skorasaurus> i didnt have the libgtk2.0-dev installed, so im installing it.
[23:59]  * skorasaurus is compiling his first package