[00:00] <bdrung> Laney: it's time to clear the u-m-s queue. i am not a core dev, so i can go to bed now.
[00:46] <bdrung> geser, Laney: http://overbenny.wordpress.com/2010/01/04/empty-ubuntu-universe-sponsors-queue/
[00:52] <geser> I hope the u-m-s queue gets started processing again next week, I've there several merges waiting
[00:56] <bdrung> geser: i wonder if i should become core dev. then i could work on the main queue, too
[01:20] <bjsnider> does the linker in a build system try to link the object file to code inside a shared library?
[01:20] <bjsnider> in other words, some_file.o linked to some_library.so?
[01:25] <RAOF> It'll link the resulting binary, but “some_file.o" won't be linked to “some_library.so".  It'll just have an unresolved symbol which could be found in some_library.so when some_file.o is being linked.
[01:25] <bjsnider> i'm getting "undefined reference to" errors, and i thought it could be because the code in the shared library doesn't matcht he code in the object file. is that possible?
[01:26] <persia> Certainly.  If you're getting that at compile time, it's likely that either the API has changed or that you don't have the required -dev installed.
[01:27] <bjsnider> i do have the -dev installed. i made the dev myself and installed it
[01:27] <persia> If you're getting that at link time for a previously compiled binary, it could just be ABI shift, in which case recompile.
[01:27] <bjsnider> it passes the configure check that it's there
[01:28] <RAOF> Possibly the library API changed and some_file.o hasn't been updated.  Or, possibly, they just don't check for this in configure.
[01:28] <RAOF> (This provides _endless_ fun for mono apps)
[01:28] <persia> configure usually just checks to see if -lfoo works when passed to the linker, rather than for the contents of the ABI.
[01:29] <bjsnider> ok, this is an old patch and new linbraries, but the header and the patch are both the same age, and the libraries are 5 months newer, so i'm going to assume that's the problem
[01:29] <RAOF> persia: Or pkg-config's it up, for the classes of libraries that I seem to be working with. :)
[01:29] <persia> bjsnider: So you're compiling code and get the link failure at the last step, for a just constructed .o file?
[01:30] <persia> RAOF: Oh fun :)
[01:30] <bjsnider> that's right
[01:30] <bjsnider> it happens during make
[01:30] <bjsnider> the configure check is also a patch and obviously it isn't sophisticated enough to check abi changes
[01:31] <persia> bjsnider: I usually only encounter that when there's been an API change to the library.  Fixing it involves porting the old code to the new API.
[01:31] <persia> You wouldn't have that for just an ABI change, as your .o is compiled to the latest ABI.
[01:32] <bjsnider> well, there's the header and the c file that are both old, and i ain't no programmer, so my work is doneski
[01:33] <persia> Don't count yourself out.  90% of API porting is relatively easy.
[01:33] <RAOF> It's a fun way to learn C :)
[01:33] <persia> Just check the function definiton in the API docs and the call int he code.
[01:33] <persia> Sometimes it's as simple as s/int/long/ or s/char*/const char*/
[01:34] <bjsnider> you mean just reaplce one function with what appears to be its replacement?
[01:34] <persia> Depends on the nature of the API change, but it's often as easy as that.
[01:34] <bjsnider> its successor i mean
[01:35] <persia> Mind you, most functions are called with variables, so you may have to retype the variable, etc.
[01:35] <bjsnider> the trouble is i can't test the resulting code because i don't have the hardware
[01:36] <persia> Can you find someone who does?
[01:37] <bjsnider> probably not
[01:37] <persia> What code is this that interests you yet involves hardware you neither have nor know someone who has?
[01:38] <bjsnider> mplayer +bluray playback
[01:38] <persia> And it's the bluray hardware you don't have?
[01:39] <bjsnider> and the discs
[01:39] <persia> Anyone have a bluray player and some time to help bjsnider test something in a few hours?
[01:40] <bjsnider> no, forget it
[01:40] <bjsnider> waste of time
[01:43] <RAOF> Does mplayer have blueray decrypting abilities now?
[01:44] <RAOF> I wasn't aware that the DRM had been sufficiently broken to a libdvdcss-level yet.
[01:44] <bjsnider> everything does
[01:44] <bjsnider> bluray encryption is a joke
[01:44] <directhex> RAOF, i don't think it's broken to that level. it can play rips though
[01:45] <RAOF> bjsnider: But substantially less of a joke than CSS
[01:45] <directhex> Playing St Trinians.m2ts.
[01:46] <bjsnider> RAOF, there's an ubuntu wiki page about this very thang
[01:47] <directhex> better behaved than with hd-dvd rips ¬_¬
[02:27] <ripps> Hmmm.... it seems that the em8300-headers are missing from the Ubuntu repos
[02:27] <ripps> in Lucid
[02:31] <persia> ripps: For which architecture?  https://launchpad.net/ubuntu/+source/em8300 implies they ought be present.
[02:31] <persia> Err, nevermind.  It implies precisely the opposite.
[02:32] <persia> Debian bug #553690 may explain more
[02:32] <ubottu> Debian bug 553690 in ftp.debian.org "RM: em8300 -- RoM; buggy, unmaintained" [Normal,Open] http://bugs.debian.org/553690
[02:42] <ripps> persia: I'm making a custom mplayer package, and the debian packaging I've based it has em8300-headers as a dependency
[02:43] <persia> ripps: Well, if it's for your own use, you could use the hardy package.  If you're looking to get it into Ubuntu, you could reinstroduce em8300 and solve some of the outstanding bugs.
[02:44] <persia> More than anything, this package mostly needs a maintainer.
[03:12] <ripps> persia: I wonder if em8300 is even needed, what exactly does it do?
[03:13] <persia> ripps: I believe em8300 was drivers for a set of television cards available at some time.  I may even have one gathering dust somewhere.
[03:14] <persia> dxr3.sourceforge.net has more info.
[03:14] <ripps> ah, my mplayer is being compiled specifically for coreavc support, so I can probably just remove it.
[03:15] <persia> Well, I'd recommend checking the site to make sure.  I also had a special hardware video injector for my DVD player in that machine, and may be confusing the two.
[03:28] <HFSPLUS> UBUNTU AND LINUX ARE CANCER IN A SENSE IF YOU USE IT YOUR BODY WILL GET SEPSIS AND YOU WILL GET CANCER EVERYWHERE IN YOUR BODY
[03:28] <HFSPLUS> !ops
[03:28] <ubottu> Help! Hobbsee, Riddell, sladen, fbond, mneptok, gnomefreak, Seveas, dholbach, elkbuntu, PriceChild, or jpds!
[03:29] <HFSPLUS> !staff
[03:29] <ubottu> Hey nalioth, jenda, rob, SportChick, seanw, Dave2, Christel, tomaw, Gary, PriceChild, niko or stew, I could use a bit of your time :)
[03:30] <Hobbsee> afternoon all
[03:31] <StevenK> Heh, k-lined
[03:32] <RAOF> That dude /again/?
[03:32] <crimsun> (I wish people would actually use "cancer" properly if they're going to troll)
[03:36] <Hobbsee> RAOF: yeah, some people get really bored, it seems
[03:39] <ripps> *sigh* even libxvidcore4 is missing in the lucid repos
[03:53] <persia> ripps: Most of what ends up being removed is removed because nobody is caring for it.  If you wish to use these packages, and want to get them in shape, I suspect they can be restored.
[03:57] <StevenK> ripps: I can still see libxvidcore4 in lucid?
[03:58] <ripps> StevenK: I'm trying to build mplayer in a ppa and I'm getting a dependency error with libxvidcore4-dev
[03:59] <ripps> it seems the +debian in the version string is confusing it.
[04:00] <StevenK> No, libxvidcore4-dev is the old name, the package has been renamed to libxvidcore-dev
[04:02] <ripps> StevenK: oh, well there's the problem, but why is livxvidcore4-dev still in the repos than? it should be removed.
[04:05] <StevenK> ripps: A few minutes ago, you thought something had been removed, and now you want something removed. :-)
[06:07] <crimsun> I think I need to do a screencast or something on these FTBFS ;-)
[06:07] <crimsun> this beats reading data sheets anyday
[06:09] <ScottK> That or convince sistpoty to come back of hiatus and make him fix them all.
[06:09] <crimsun> oooh
=== asac_ is now known as asac
[07:12] <dholbach> good morning and happy new year! :-)
[07:18] <fabrice_sp_> Hey dholbach ! Happy new year to you too!
[07:18] <dholbach> hey fabrice_sp_! thanks :)
[07:19] <fabrice_sp_> thanks ;-)
=== Whoopie_ is now known as Whoopie
[07:56]  * Yagisan sighs. I wholeheartedly recommend that no one else here experience the pain of removing 1040 files that should never have been committed to a git repo, with the commits made over 3000 commits before head ...
[07:57] <Yagisan> git filter branch could really use wildcard globbing ...
=== dholbach_ is now known as dholbach
[08:10] <alkisg> I'm trying to have the following dependencies, but it's not really working with apt-get, can anyone see why?
[08:10] <alkisg> Package "A" conflicts with "C". Package "B" depends on "C | D".
[08:10] <alkisg> I want this: when users install "B", they also get "C", unless they have "A" installed, in which case they get "D" instead.
[08:13] <slytherin> alkisg: What did you try exactly?
[08:15] <alkisg> slytherin: My goal is to test & propose a slightly different set of dependencies for pulseaudio, so that it conflicts with libsdl1.2debian-alsa, so that libsdl1.2debian-pulseaudio is selected when someone has pulseaudio installed and wants to install something sdl-related.
[08:15] <slytherin> alkisg: OK. And what changes did you try and what is not working?
[08:18] <alkisg> (sorry, phone, be back in 10'... :()
[08:28] <alkisg> Sorry for the delay. I tried it first directly with pulseaudio (made a newer package that conflicted with libsdl1.2debian-alsa and uploaded it to my PPA) but that gave me an error about not satisfiable dependencies and broken packages, so I tried to simplify it:
[08:29] <alkisg> so I made a dummy ubuntu-sdl-pulse package with just "Conflicts: libsdl1.2debian-alsa, libsdl1.2debian-all, libsdl1.2debian-esd, libsdl1.2debian-nas, libsdl1.2debian-oss" in it.
[08:29] <alkisg> Then I did the following steps:
[08:29] <alkisg> 1) Removed everything sdl related
[08:30] <alkisg> 2) Installed the dummy ubuntu-sdl-pulse package
[08:30] <alkisg> 3) Tried to install tuxpaint.
[08:31] <alkisg> tuxpaint uses libsdl, so at that point I was hoping that libsdl1.2debian-pulseaudio would be pulled in
[08:31] <alkisg> And indeed aptitude was able to offer me that solution, with score=100
[08:32] <alkisg> But apt-get instead proposed the removal of the dummy ubuntu-sdl-pulse package, and the installation of libsdl1.2debian-alsa
[08:32] <alkisg> slytherin: ^^^ that's what I tried, any thoughts?
[08:58] <slytherin> alkisg: sorry I was away. I think this may have something to do with priority of the packages specified in debian/control file
[08:59] <alkisg> slytherin: any way to solve the problem?
[09:00] <slytherin> no idea
[10:37] <hakaishi> Hi folks, anyone up to review qt-shutdown-p? It's a little Qt4 program to shutdown the system after a given number of minutes or at a given time, while one can always see how much time is left. http://revu.ubuntuwire.com/p/qt-shutdown-p
=== noodles775_ is now known as noodles775
[12:05] <hakaishi> Hi everyone, anyone up for reviewing qt-shutdown-p? It's a little Qt4 program to shutdown the system after a given number of minutes or at a given time, while one can always keep an eye on how much time is left. http://revu.ubuntuwire.com/p/qt-shutdown-p
=== freeflyi1g is now known as freeflying
=== cyphermox_ is now known as cyphermox
[14:43] <coder> mmm, it seems impossible to install 9.10 desktop x64 on softraid
[14:47] <mok0> coder, huh? I thought that was possible using ext4
[14:47] <coder> there's no even option on the installer
[14:47] <mok0> coder, alternate installer?
[14:47] <coder> no
[14:48] <mok0> Hm. Disappointing
[14:48] <coder> installer doesn't even recognize disks, while at console they are ready
[14:48] <mok0> coder, I have to admit, I've not installed a new Ubuntu in a while... I'm on an update streak
[14:49] <mok0> coder, just heard from my colleague that he did it with /boot on an LVM partition
[14:54] <coder> I find no benefits of putting /boot on a LVM2 volume
=== ripps is now known as ripps|sleep
[15:11] <bddebian> Heya gang
[15:11] <sebner> huhu bddebian
[15:12] <bddebian> Heya sebner
[15:12] <directhex> it's a bddebian!
[15:12] <bddebian> heh
[15:12] <BlackZ> hi bddebian
[15:13] <sebner> bdmurray: happy new year + have you ever thought about updating warsow? :P
[15:14] <bddebian> sebner: Was that for me? :)
[15:14] <sebner> bddebian: argh. sure!
[15:15] <bddebian> sebner: Do you mean to upstream 0.5?
[15:15] <sebner> bddebian: yep
[15:16] <bddebian> I can take a look
[15:16] <sebner> bddebian: no rush, just there for some months already :P
[15:18] <BlackZ> sebner, hello
[15:18] <sebner> BlackZ: hoi
=== highvolt1ge is now known as highvoltage
[15:58] <Quintasan> hmm I get permission denied on uploading to REVU, what's wrong?
=== \vish is now known as mac_v
=== mac_v is now known as \vish
=== yofel_ is now known as yofel
[17:33] <kamalmostafa> Help with 'requestsync'?  I would like to make a sync-request for xvnc-0.9.9-1 from http://packages.debian.org/source/sid/x11vnc but "requestsync x11vnc lucid" gets "E: The versions in Debian and Ubuntu are the same already (0.9.8-2)."   What am I doing wrong?
[17:34] <ScottK> kamalmostafa: We are syncing from testing by default and that's what's in Testing.  You need to specify you want to sync from Unstable.
[17:36] <kamalmostafa> ScottK: requestsync -d unstable x11vnc lucid    ... gets the same error.
[17:37] <ScottK> kamalmostafa: Then it's a bug in requestsync.  Debian recently started keeping more than one version around in Unstable and it's picking the wrong one.  Please file a bug against ubuntu-dev-tools.
[17:38] <Laney> no
[17:38] <Laney> I already fixed that one
[17:38] <Laney> grab requestsync from bzr and try that versino please, kamalmostafa
[17:38] <ScottK> Laney: Is the fix in Karmic?
[17:39] <kamalmostafa> ScottK: Yes, that package does have more than one version in 'unstable'
[17:39] <Laney> ScottK: I dunno. I didn't backport it, at least.
[17:39] <ScottK> Laney: I think it's SRU material.
[17:39] <kamalmostafa> I am running Karmic FWIW -- I will try grabbing requestsync from bzr.
[17:40] <ScottK> OK, well Laney then we ought to get it fixed in Lucid first
[17:41] <Laney> ScottK: It is in the latest Lucid release (0.86)
[17:41] <ScottK> Laney: OK, then kamalmostafa shouldn't be having the problem.
[17:41] <ScottK> Oh, nevermind
[17:41] <ScottK> I read that wrong
[17:41] <ScottK> Laney: I do think it's worth an SRU.
[17:41] <Laney> revision 547 if someone wants to SRU it
[17:41]  * Laney is running Lucid
[17:42] <Laney> wait, that's not the one
[17:42] <ScottK> Laney: Was there a bug for this or did you just fix it?
[17:42] <Laney> ScottK: I was mistaken, geser did the fix (I did it for pull-debian-source)
[17:43] <Laney> (AFAIK)
[17:43] <ScottK> Laney: OK.  Both those ought to be fixed.
[17:43]  * ScottK uses pull-debian-source from unstable a lot
[17:43]  * Laney too
[17:47] <Laney> kamalmostafa: does it work if you use --lp?
[17:48] <kamalmostafa> Laney:  Why yes... yes it does!
[17:49] <kamalmostafa> Laney:  Yes, with --lp, it detects the proper (latest) version number from Debian unstable.  Without --lp, it gets the wrong version number.
[17:50] <Laney> That's right. Without --lp we use rmadison which wasn't parsed correctly
[17:50] <kamalmostafa> Laney:  The exact command I mean is:   requestsync [--lp] -s -d unstable x11vnc lucid
[17:50] <Laney> 547 and 546 for the SRU
[17:51] <kamalmostafa> Laney:  Do you wish me to request an SRU for those changes?  (I'm new here, but eager to help).
[17:52] <Laney> if you want to prepare the SRU you can grab the diffs from those two commits and apply them to the karmic-updates version of ubuntu-dev-tools. Then test it works correctly and if so file a bug with the debdiff.
[17:54] <kamalmostafa> Laney:  Okay, I will do so.  Thank you both very much for your help.
[17:54] <Laney> kamalmostafa: let me know when it's up
[17:55] <kamalmostafa> Laney: will do.
[18:06] <james_w`> can anyone tell me how to find out whether LaserJock has upload permission to qcad?
[18:06] <james_w`> I know he doesn't have either component upload rights or package upload rights for it
[18:06] <james_w`> I'm not sure how to determine package set rights
[18:07] <james_w`> err, wrong channel, sorry
[18:22] <kamalmostafa> Laney:  I have the relevant ubuntu-dev-tools trees extracted -- but what exactly are "547" and "546"?  The lucid tree "bzr log" lists revno 86 as the latest revision.
[18:24] <Laney> kamalmostafa: are you looking in the changelog? I see 553 revisions here. Try bzr diff -r 545..546
[18:24] <chrisccoulson> james_w - only ubuntu-core-dev can upload qcad can't they?
[18:25] <chrisccoulson> == All uploaders for package 'qcad' ==
[18:25] <chrisccoulson> Archive Upload Rights for ubuntu-core-dev: package set 'edubuntu' in karmic
[18:25] <chrisccoulson> Archive Upload Rights for ubuntu-core-dev: package set 'edubuntu' in lucid
[18:27] <kamalmostafa> Laney:   bzr diff -r 545..546     bzr: ERROR: Requested revision: u'545' does not exist in branch: ...
[18:28] <kamalmostafa> Laney:  maybe I don't have the correct tree after all.  Which tree should I be looking at here?
[18:28] <Laney> bzr branch lp:ubuntu-dev-tools
[18:31] <kamalmostafa> Laney:  Okay, got it.   I had pulled "ubuntu/lucid/ubuntu-dev-tools".   Too many trees.   I now have 533 changes.  I'll let you know when I'm stuck again :-)
[18:32] <james_w`> chrisccoulson: "package set 'edubuntu'" has me suspicious
[18:36] <Laney> laney@pheasant> bin/ubuntu-archive-tools/edit_acl.py -P edubuntu -S lucid query                                                                            ~
[18:36] <Laney> == All uploaders for package set 'edubuntu' in 'lucid' ==
[18:36] <Laney> Archive Upload Rights for ubuntu-core-dev: package set 'edubuntu' in lucid
[18:38] <Laney> james_w`: ^
[18:38] <james_w`> ah, so the set hasn't been delegated yet?
[18:38] <Laney> looks like it
[18:39] <james_w`> thanks
[18:41] <ScottK> james_w`: laserjock is core-dev
[18:42] <james_w`> not according to LP
[18:43] <ScottK> Weird.  Maybe he quit?
[18:44] <ScottK> He certainly was.
[18:44] <james_w`> it says he was deactivated from the team in 2007
[18:44] <Laney> you can query with -p person query
[18:44] <james_w`> maybe he had an indirect membership after that
[18:44] <Laney> == All rights for laserjock ==
[18:44] <Laney> (none)
[18:44] <highvoltage> that's quite odd, I'm quite sure he was a core-dev last year still
[18:44] <highvoltage> stgraber: do you know about the above?
[18:47] <ScottK> 2007 is when he joined core-dev
[18:51] <james_w`> oh
[18:56] <stgraber> jordan must still be a coredev, otherwise he couldn't have done seed changes for the last 6 months
[18:56] <stgraber> or he recently left the teams and I didn't notice ...
[18:58] <geser> unfortunately LP stores the date when someone expired but not when someone deactivated himself
[19:11] <james_w`> sync spam!
=== Nafallo_ is now known as Nafallo
[19:17] <kamalmostafa> Laney:  I have built and tested the requestsync fix -- inspect the changelog?: http://paste.ubuntu.com/351396/
[19:18] <kamalmostafa> Laney:  And how exactly should I push it?  To "karmic-proposed" somehow?
[19:19] <ScottK> kamalmostafa: Attach the debdiff to a bug and subscribe ubuntu-universe-sponsors
[19:20] <geser> and change the version to "0.81.2" (it's an Ubuntu-specific package, it doesn't need the ubuntu1 suffix)
[19:20] <geser> and target "karmic-proposed"
[19:21] <Laney> kamalmostafa: you should say that you are backporting the fixes from lucid
[19:22] <Laney> also...
[19:22] <Laney> !sru
[19:22] <ubottu> Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates
[19:22] <kamalmostafa> gezer:  Do I understand you to mean:  change "karmic" to "karmic-proposed" in debian/changelog?  Version change understood.
[19:22] <ScottK> kamalmostafa: Yes
[19:23] <kamalmostafa> Where should I say that I am backporting fixes from Lucid?  In debian/changelog, or bzr log, or both?
[19:23] <ScottK> debian/changelog
[19:24] <emet> hey if I am packaging something and I am having problems, can I ask for help here?
[19:24] <highvoltage> james_w`: "(21:23:25) Jordan Mantha: I deactivated over the weekend some time"
[19:24] <emet> I'm new to debian packages
[19:25] <Laney> kamalmostafa: Also you should remove the Closes (and maybe not credit us in [ Name ] blocks as it makes it look like we made the change in Karmic)
[19:26] <Laney> mmm syncs
[19:26] <hakaishi> Could some please review qt-shutdown-p? It's a small Qt4-program to shutdown the system, while one can keep an eye on the countdown. One can both enter a number of minutes or a time. http://revu.ubuntuwire.com/p/qt-shutdown-p
[19:29] <hakaishi> ah... I meant: could someone... ^^'
[19:30] <randomaction> !ask | emet
[19:30] <ubottu> emet: Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-)
[19:32] <kamalmostafa> Laney, geser, ScottK:  Can I just use this bug https://bugs.launchpad.net/ubuntu/+source/ubuntu-dev-tools/+bug/498349 for the SRU, or do I file a new one?     Should I ref that bug in the changelog?   My revised debian/changelog for your review:   http://paste.ubuntu.com/351400/
[19:32] <ubottu> Ubuntu bug 498349 in ubuntu-dev-tools "[lucid] requestsync bails attempting to parse the changelog for haskell-src-exts from Debian unstable main (1.3.0-1)" [Undecided,Fix released]
[19:32] <ScottK> kamalmostafa: Same one.
[19:33] <ScottK> kamalmostafa: I opened a karmic task on the bug.
[19:34] <kamalmostafa> ScottK:  For my edification, how did you do so?
[19:35] <ScottK> kamalmostafa: I clicked on nominate for release.
[19:35] <ScottK> Since I'm an Ubuntu Dev, it opened the task.  You would have to nominate it and then wait for someone to approve it.
[19:36] <kamalmostafa> ScottK:  Got it.  Okay, I await further comments on my revised debian/changelog before submitting the debdiff:  http://paste.ubuntu.com/351400/
[19:44] <kamalmostafa> ScottK: Please review again?:  http://paste.ubuntu.com/351400/
[19:44] <kamalmostafa> Laney: Please review again?:  http://paste.ubuntu.com/351400/
[19:44] <kamalmostafa> geser: Please review again?:  http://paste.ubuntu.com/351400/
[19:45] <Laney> kamalmostafa: looks good
[19:46] <Laney> if you want you can say what problem it fixes too (our changelog entries could be better)
=== Quintasan1 is now known as Quintasan
[19:48] <Quintasan> persia: I get "permission denied" when uploading to REVU, noticed it yesterday, do you have any idea what's wrong?
[20:07] <kamalmostafa> Laney:  I have attached the requestsync debdiff to LP: #498349 and subscribed "ubuntu-universe-sponsors".   Do I now *also* need to "bzr push" the package to karmic-proposed per Step 4 of the SRU wiki page "Procedure"?
[20:08] <Laney> kamalmostafa: no, but please subscribe ubuntu-sru
[20:09] <sebner> hihi Laney :=
[20:09] <sebner> :)
[20:09] <Laney> hiya
[20:10] <kamalmostafa> Laney:  Ok, ubuntu-sru is subscribed.   What does Step 4 mean?:  "4. Upload the fixed package to release-proposed with the patch in the bug report, a detailed and user-readable changelog, and no other unrelated changes."
[20:10] <Laney> the sponsor does that
[20:11] <kamalmostafa> Laney:  Ok, got it.  So... Next step for me then?
[20:12] <bmm> How long do you guys think it will take for the launchpad PPA to include Lucid? I've just installed Lucid and only now I remember how much I love my PPA :D
[20:13] <Quintasan> persia: I would be also grateful if you could remove (or poke the one who can) all acetoneiso, krunner-kopete, plasma-widget-* since they are my uploads, they were not accepted and not maintained so I won't work on them -> http://revu.ubuntuwire.com/u/quintasan
[20:14] <ScottK> Quintasan: I can do it (I think)
[20:15] <Laney> kamalmostafa: you should follow the SRU procedure (particularly steps 1 and 4)
[20:15] <Quintasan> ScottK: That would be nice since they only sit there and waste space and time
[20:18] <ScottK> Archived all of them
[20:19] <kamalmostafa> Laney:  Do you mean Procedure steps 2.1 and 2.4?... that I should add an impact statement and detailed instructions to the bug?
[20:19] <Laney> right
[20:19] <Quintasan> ScottK: Oh just remembered to ask. What's the difference between Archive and Nuke?
[20:19] <Laney> someone will need to verify the upload before it can get to karmic-updates, and they will need instructions on how to do so
[20:20] <Laney> Quintasan: archiving is reversible, nuking is not
[20:20] <ScottK> Quintasan: Archive means it still exists, but isn't listed.
[20:20] <ScottK> Nuking means deleting
[20:20]  * bmm moving hist PPA question to the launchpad channel
[20:20]  * bmm does not know how to spell appoligize
[20:20] <ScottK> bmm: It's supported for a long time alread
[20:20] <ScottK> y
[20:20] <Laney> kamalmostafa: I just looked at that bug and it doesn't look like one which is fixed by your SRU
[20:21] <kamalmostafa> Laney: Oh boy... now where did I find that bug number?...
[20:22]  * Laney shrugs
[20:22] <kamalmostafa> Laney:  Okay, I see where I misfired here.  :-(
[20:23] <bmm> ScottK: ah, just noticed that. Sorry for the question all together :D
[20:23] <bmm> ScottK: oh and thanks for the answer!
[20:25] <kamalmostafa> Laney: I grabbed completely the wrong bug-id from the debian/changelog in the lp:ubuntu-dev-tools tree.   But the one listed as being relevant to this issue is (Closes: #560758) which is not a LP bug.  Now what?
[20:26] <Laney> kamalmostafa: you can open a new one
[20:26] <Laney> and "nominate for release" it to Karmic
[20:26] <Laney> 560758 s a Debian bug
[20:26] <kamalmostafa> Ok, and how do we undo the mess we made with 498349?
=== mac_v is now known as \vish
[20:27] <Laney> just make the status Invalid and add a comment :)
[20:28] <kamalmostafa> What about the "nominate for release" that you did?
[20:29] <kamalmostafa> Oh, you mean make that "Karmic" line Invalid?  Yes?
[20:29] <Laney> yes
=== james_w` is now known as james_w
[21:11] <kamalmostafa> Laney:  Okay, I have filed a new LP bug for requestsync:  https://bugs.launchpad.net/debian/+source/ubuntu-dev-tools/+bug/503111        When I click "Nominate for release", I get a list of Debian (not Ubuntu) releases.   Where did I go astray?
[21:11] <ubottu> Ubuntu bug 503111 in ubuntu-dev-tools "False: The versions in Debian and Ubuntu are the same already during requestsync" [Undecided,In progress]
[21:13] <Laney> kamalmostafa: I did it
[21:15] <kamalmostafa> Laney:  Thank you.  Do you know why I got Debian versions list there?
[21:15] <Laney> kamalmostafa: See "debian" in the URL
[21:16] <kamalmostafa> Laney:  I guess I mean to ask -- How did you attach the Karmic task there?
[21:17] <Laney> I changed the URL
[21:17] <Laney> s/debian/ubuntu/
[21:21] <kamalmostafa> Laney:  Magic!  I do not have a grasp of the bugs.launchpad.net URL structure yet.   Okay...  is 503111 all set then?
[21:22] <Laney> kamalmostafa: yep, looks good
[21:27] <kamalmostafa> Laney:  Okay, then I will keep an eye on 503111.  Thank you VERY much for all your help today (geser and ScottK also).   We took care of the requestsync problem, and it looks like my Lucid x11vnc FTBFS that started all this is on its way to ubuntu-archive.   I hope to work with you fine folks again soon.
[21:48] <rickspencer3> hi
[21:49] <rickspencer3> looks like I did my first upload to Revu, but there are a couple of lintian errors (oops)
[21:49] <rickspencer3> shall I just fix them, nuke the built files (.changes, .dcs, etc..., targ.gz, etc...)
[21:49] <rickspencer3> rebuild and re dput?
[21:50] <ScottK> rickspencer3: Yes.
[21:51] <rickspencer3> thanks ScottK
[21:51] <ScottK> You don't actually need to nuke the files, they'll get over-written when you rebuild
[21:51] <rickspencer3> ScottK, even easier
[21:54] <sebner> hoi rickspencer3, happy new year! :)
[21:55] <rickspencer3> hi sebner
[21:55] <rickspencer3> happy new year to you!
[21:55] <sebner> :)
[21:55] <sebner> let's see if it'll be happy though :P
[22:02] <rickspencer3> looks like I have a couple of issues to tackle, they look easy, maybe someone can help?
[22:02] <rickspencer3> the first is...
[22:02] <rickspencer3> This is a native Debian package, with no .orig.tar.gz tarball.
[22:03] <ScottK> rickspencer3: Why?
[22:04] <rickspencer3> ScottK ... that's in the "warnings/notices" section of the review page, is it a problem?
[22:04] <Laney> depends what it is (but likely yes)
[22:05] <ScottK> It's not inherently a problem, but that's almost always wrong.
[22:05] <rickspencer3> well, it's my own code
[22:05] <rickspencer3> so it's not like I have an "upstream" to package
[22:05] <ScottK> Sure, but it's not inherentlty Debian/Ubuntu specific.
[22:05] <ScottK> So you should talk to upstream about making one ....
[22:05] <rickspencer3> ScottK, I am upstream
[22:05] <rickspencer3> I am *the* upstream
[22:05]  * ScottK knows
[22:05] <rickspencer3> hehe
[22:05] <Laney> exactly
[22:06] <rickspencer3> Laney, ScottK, I appreciate you guys helping me with this, debian packaging is not my forte
[22:06] <ScottK> rickspencer3: The trick to this (I found the first time I tried to do it) was to first put on an upstream release hat and do what you would do to release it.  Then put on your packager hat and package it.
[22:07] <rickspencer3> so I just rename quidgets_0.3~public1.tar.gz
[22:07] <ScottK> So make an orig.tar.gz with no Debian dir in it.
[22:07] <ScottK> move the debian dir aside and reroll it.
[22:10] <rickspencer3> ScottK, I just put it back next to other files now, and dput takes care of it
[22:10] <rickspencer3> ?
[22:10] <ScottK> debuild, but yest
[22:11] <ScottK> Then you should have a .diff.gz
[22:11] <Laney> rickspencer3: If you have an orig.tar.gz present then debuild will work out the diff (which is your debian/ directory) and make a .diff.gz out of it
[22:11] <ScottK> You do need to be mindful of naming.
[22:11] <Laney> read what debuild -S says — it should tell you if (and what) orig.tar.gz it's using
[22:12] <ScottK> Your directory should be quidgets-0.3 and the tarball quidgets_0.3.orig.tar.gz
[22:12] <rickspencer3> Laney, I moved the orig.tar out of the way, reran dpkg
[22:12] <rickspencer3> so I have two tar.gz files
[22:12] <siretart> ScottK: can you promote yasm? pitti already set the MIR bug to 'fix committed', but I wonder what is left to be done about that
[22:12] <ScottK> siretart: I can't.  That takes shell access.
[22:13] <siretart> aah, ok
[22:13] <rickspencer3> Laney, am I better off with the diff, or am I good now?
[22:14] <Laney> rickspencer3: you want three files - orig.tar.gz, diff.gz, dsc
[22:14] <rickspencer3> k
[22:15] <rickspencer3> Laney, got those now, thanks
[22:15] <Laney> cool
[22:15] <Laney> lsdiff -z blah.diff.gz should show just files in debian/
[22:19] <rickspencer3> Laney, how about this one:
[22:19] <rickspencer3> This package has no debian/watch file or get-orig-source rule.
[22:19] <rickspencer3> ?
[22:19] <rickspencer3> do I need to point to my PPA or something?
[22:20] <ScottK> That should point to the upstream source for the package.  Don't sweat it for now.
[22:20] <Laney> Ideally you publish your releases somewhere and then write a watch file to download them with uscan
[22:20] <Laney> (see man uscan)
[22:21] <rickspencer3> Laney, like I just pick an arbitrary ftp server location?
[22:21] <ScottK> rickspencer3: Wherever you expect people to come find new versions.
[22:21] <rickspencer3> ScottK, ok
[22:21] <Laney> see apt-get source gnome-do for an example which uses tarballs published on Launchpad
[22:21] <rickspencer3> ScottK but I can skip that for now?
[22:21] <ScottK> Yes.
[22:22] <rickspencer3> next was ..
[22:22] <rickspencer3> #  The changelog does not close a bug from Launchpad. New packages should have a needs-packaging bug and the upload close it using the syntax "(LP: #nnnn)".
[22:22] <rickspencer3> can I skip that as well?
[22:23] <ScottK> I think the odds that anyone else is packaging this are low enough you don't need to worry about the needs-packaging bug.
[22:25] <rickspencer3> ScottK appreciate that
[22:26] <rickspencer3> so finally, it looks like it wants me to include a copy of GPL-3 rather than just refer to it here: /usr/share/common-licenses/GPL-3
[22:26] <rickspencer3> is this a problem?
[22:26] <ScottK> Yes.
[22:27] <ScottK> Your package has to have a full copy of the license in it.
[22:27] <ScottK> Usually you just have a file called COPYING that has it in there.
[22:27] <ScottK> You'll need to redo to tarball for this.
[22:28] <rickspencer3> ScottK, shall I just copy the text into the Copyright file?
[22:29] <ScottK> No.  debian/copyright and upstream COPYING are two different, but related things.
[22:29] <ScottK> debian/copyright is just in the diff.gz, so it doesn't support having a distributable source tarball
[22:31] <rickspencer3> so I take the text for the license, create a file debian/COPYING, and fill debian/COPYING with the text of the license?
[22:32] <rickspencer3> then re-run dpkg?
[22:32] <ScottK> rickspencer3: No, COPYING doesn't go in debian, it goes in your upstream tarball
[22:32] <rickspencer3> ah
[22:33] <rickspencer3> so start over
[22:33] <ScottK> Then in debian/copyright you have the license snippet, the link to common-licenses, copyright info, etc.
[22:33] <rickspencer3> I mean, I start over
[22:33] <ScottK> Right, move the debian dir aside again, add COPYING, and then reroll the tarball
[22:42] <rickspencer3> ScottK, does this matter:
[22:42] <rickspencer3> The Maintainer  field is invalid. It has to contain an @ubuntu.com address (usually the Ubuntu MOTU Team's). The packager can leave his/her name as XSBC-Original-Maintainer.
[22:42] <rickspencer3> I used my canonical email, I can change it to @ubuntu I suppose
[22:42] <ScottK> Make yourself original maintainer
[22:43] <ScottK> That update-maintainer script in ubuntu-dev-tools should do the right thing
[22:44] <rickspencer3> ScottK - I assume this is referring to the Control file
[22:44] <ScottK> Yes
[22:44] <ScottK> Back later
[22:44] <rickspencer3> ScottK, ok
[22:44] <rickspencer3> thanks for your help
=== RAOF_ is now known as RAOF