[00:26] <MTecknology> how do I sign something with my gpg key if the changelog has somebody else?
[00:27] <geser> debsign -k0xyourkeyid the_package_source.changes
[00:28] <MTecknology> thanks
[01:30] <MTecknology> I installed a newer package from a ppa; but I don't want that anymore so I tried to remove the package, remove the ppa, update apt, install that package again
[01:30] <MTecknology> it still wants to install that newer version
[01:31] <MTecknology> You guys know how I can make it stop trying to install that version?
[01:54] <persia> MTecknology: For that sort of thing, #ubuntu is probably better.  I think there's a way to reinstall from the archive, but I don't remember the commands.
[01:54] <MTecknology> persia: alrighty thanks
[01:55] <rhpot1991> hmmmm, I did a dput to revu yesterday and it never showed up on the web site
[01:55] <rhpot1991> no email or nothing, and now when I try to dput again it says its already up ther
[01:56] <persia> What package?
[01:56] <rhpot1991> persia: hdhomerun-config-gui
[02:00] <persia> rhpot1991: Well, it's not most of the common mistakes.  I'm looking a bit more.
[02:03] <persia> rhpot1991: I can't find your key on the Ubuntu keyserver (http://keyserver.ubuntu.com:11371/pks/lookup?search=B1C7AfA8&op=vindex)
[02:03] <persia> Have you pushed your key to the keyservers?  Does LP know about it?
[02:04] <rhpot1991> persia: yes, I did change the primary email address though, not sure if that should matter
[02:05] <rhpot1991> I can still push to my bzr and ppas all the same
[02:05] <persia> bzr is the ssh key, rather than the gpg key.  I don't know how ppas work.
[02:05] <rhpot1991> ppas are gpg I think, I could be wrong
[02:05] <persia> But the package was clearly signed with B1C7AFA8, and I don't see that (see URL above), so I'm guessing REVU didn't see it, which would explain why it's in rejected/
[02:06] <rhpot1991> http://keyserver.ubuntu.com:11371/pks/lookup?search=0x64218F18CFA01CA04B85257C2B496BF2B1C7AFA8&op=index
[02:06] <rhpot1991> thats the key in mention right there
[02:07] <rhpot1991> LP knows that key too: https://launchpad.net/~rhpot1991
[02:07] <persia> Grumble.  The search should really show that.
[02:10] <rhpot1991> persia: want me to force a dput and you can see what happens?
[02:10] <persia> rhpot1991: Won't make any difference.
[02:10] <persia> I have the package,
[02:11] <persia> I7m just not sure why it fails.  The checksums in the ,.changes file match, and you havce a valid signture.
[02:12] <persia> I'll toss it back in the queue, and see if it gets rejected again.  If it does, someone else will have to fix it.
[02:12] <persia> (because none of the things I usually see wrong are wrong)
[02:12] <rhpot1991> persia: you push the .changes file with revu right?
[02:12] <rhpot1991> want to double check I didn't do something wrong
[02:12] <rhpot1991> with dput that is
[02:13] <rhpot1991> hmmm I have a hdhomerun-config-gui_20100121-0ubuntu1_source.revu.upload hanging around
[02:13] <persia> It's not an issue with dput.  You successfully uploaded.
[02:14] <persia> Yes, that is the record dput created after successfully uploading.
[02:14] <rhpot1991> ya, and the timestamp matches
[02:14] <rhpot1991> toss it back in the queue, I'll check on it later
[02:14] <rhpot1991> thanks for the help again :)
[02:16]  * persia finds another rejected package, and preemtively investigates
[02:22] <persia> rhpot1991: http://revu.ubuntuwire.com/p/hdhomerun-config-gui
[02:23] <jsplice> what's a good way to debug c/c++ in linux?
[02:24] <RAOF> jsplice: All sorts of options, depending on is actually wrong.  gdb is generally a good start, though.
[02:25] <jsplice> gdb...cool, I'll check it out..thanks
[02:59] <rhpot1991> thanks persia
[03:47] <micahg> if I want one target to go to another in a rules file, how do I do that?
[03:47] <RAOF> You make the second target depend on the first.
[03:47] <RAOF> MyDependantTarget: ThisTargetWillGetRunFirst
[03:49] <micahg> there's no way to do it the other way around?
[03:50]  * micahg thinks he'll make a new target that just runs both...
[03:51] <RAOF> You want one target to run after the other, right?
[03:51] <micahg> yep
[03:51] <RAOF> Making A run before B is exactly equivalent to making B run after A.
[03:51] <micahg> but it's weird to run the second one on the command line
[03:51] <RAOF> Ah.
[03:51]  * micahg just added a target to run both :)
[03:51] <micahg> thanks RAOF
[03:54] <kamalmostafa> micahg: You've got the right idea with the target to run both -- If what you want is to "replace" the old "A" rule with "A then B" while retaining the name "A", then you should rename the original "A" to "originalA" and then add a new rule "A: originalA B".
[03:54] <micahg> kamalmostafa: yeah, that didn't quite work either, the name for the first is good :)
[03:55] <micahg> what's the equiv of sed -p -n on ubuntu?
[03:56] <kamalmostafa> micahg: versus on what other platform?  What's "-p" supposed to do?
[03:56] <micahg> print matches
[03:56] <micahg> is that by default?
[03:57]  * micahg read an old shell scripting book :)
[03:57] <kamalmostafa> micahg: sed -n :  suppress automatic printing of pattern space    Default is that pattern space would be printed.
[03:58] <micahg> kamalmostafa: right, but it still prints matches, right?
[03:58]  * micahg guesses that's the whole point...
[03:58]  * micahg wonders why that option ever existed
[03:58] <kamalmostafa> micahg: Yes.  Like this:
[03:59] <kamalmostafa> $ sed s/foo/bar/
[03:59] <kamalmostafa> foozoofoo
[03:59] <kamalmostafa> barzoofoo
[03:59] <kamalmostafa> That wasn't clear.  I typed "foozoofoo" -- sed *printed* "barzoofoo".
[04:00] <kamalmostafa> Had I done "sed s/foo/bar/g" (note the added "g" for global" then both instances of foo would have been replaced.
[04:01] <micahg> ok, so now I get warned that my %: target is being run after it
[06:02] <fabrice_sp> I was beginning to upload packages for the liblo transition, but the builds are still getting the old liblo0-dev package. AFAIK, the new liblo-dev provides the old liblo0-dev packages, so it should be used automatically, right? Or liblo0-dev should be deleted first from the archive?
[09:12] <hakaishi> Hello everyone! Anyone up to advocate/review qt-shutdown-p? (I've got one advocate XD ) http://revu.ubuntuwire.com/p/qt-shutdown-p
[10:50] <amarillion> What does a dependency of "default-jdk" mean exactly? I'd expect that it would work with both openjdk and sun jdk, but that doesn't seem to be the case
[10:51] <amarillion> I've got the sun jdk installed. When I try to debuild a package that depends on default-jdk, it complains. When I do apt-get install default-jdk, it wants to pull in openjdk
[11:02] <amarillion> How can I make a package that doesn't care which jdk there is, and works with anything that is installed?
[11:07] <directhex> amarillion, piped build-depends tend to be a really bad idea
[11:07] <directhex> amarillion, so you need to distinguish between what you build against and run against
[11:08] <amarillion> Right, I wasn't clear about that
[11:08] <directhex> amarillion, in the general case, you can have a binary depend on (for example) java6-runtime
[11:08] <amarillion> Right now my control file has
[11:08] <amarillion> Build-Depends: debhelper (>= 5), ant, default-jdk
[11:08] <amarillion> Depends: Depends: default-jre | sun-java6-bin | sun-java5-bin
[11:08] <directhex> that's not a good depends line.
[11:09] <amarillion> But that means if I want to test building the package on my own computer with debuild, I have to install openjdk, right?
[11:09] <directhex> for binary depends, think more along the lines of "preferred | general-alternative" - for example, openjdk-6-jre | java2-runtime
[11:09] <directhex> for building... i wouldn't ever use debuild personaly to compile binaries so no comment
[11:09] <amarillion> What do you prefer to use then?
[11:10] <amarillion> Is this a good depends line then:
[11:10] <directhex> pbuilder. since it ensures that the build-depends are sane, by reinstalling them for every package
[11:10] <amarillion> Depends: default-jre | java2-runtime
[11:10] <amarillion> Ok, I'll try it with pbuilder
[11:18] <amarillion> directhex: There is no package named java6-runtime
[11:18] <amarillion> nor java2-runtime
[11:43] <directhex> amarillion, i know. that's what Provides: is for
[11:51] <doctormo> Hey all,
[11:51] <doctormo> I want to look at dependancies for jaunty vs lucid, does anyone have a jaunty machine they could check for me?
[11:52] <doctormo> I need to know if they have a python-lazr-restfulclient or python-lazr.restfulclient package available. (note the dot insteadof hyphen)
[11:53] <_ruben> you can check on http://packages.ubuntu.com
[12:13] <doctormo> _ruben: Is there a way in the control file I can specify 'this-package or this-other-package' ?
[12:13] <_ruben> this-package | this-other-package
[12:13] <doctormo> thanks
[12:41] <amarillion> directhex: thanks. So to recap,
[12:41] <amarillion> I should do Depends preferred | general-alternative
[12:41] <amarillion> So I'm going to do
[12:41] <amarillion> Depends: sun-java6-bin | java6-runtime
[12:41] <amarillion> And Build-Depends should remain
[12:41] <amarillion> Build-Depends: debhelper (>= 5), ant, default-jdk
[12:42] <amarillion> And I shouldn't use debuilder :)
[12:43] <amarillion> I mean, I shouldn't use debuild for binary packages.
[12:49] <rmunn> Woo-hoo, my first Ubuntu package is uploaded and ready for review!
[12:49] <rmunn> https://bugs.launchpad.net/ubuntu/+bug/514936 and http://revu.ubuntuwire.com/p/python-nltk
[12:50] <rmunn> It's my first time creating a "real" Debian or Ubuntu package (as opposed to training exercises), so please tell me if there's any important steps I missed... Thanks!
[13:17] <c_korn> rmunn: does the b in 2.0b8 stand for beta ?
[13:19] <Rhonda> rmunn: If it does I would suggest to prefix the b with a ~ so that when 2.0 final gets released you won't have to use an epoch or other means to have increasing version numbers. :)
[13:20] <rmunn> c_korn, Yes, it's "beta".
[13:21] <rmunn> Rhonda, Thanks, I'll do that. I'm guessing I'll need to reupload after that, right?
[13:23] <Rhonda> Sure, before anyone uploads your package and you have to deal with the version woes. :)
[13:35] <rmunn> Done, the source package at http://revu.ubuntuwire.com/p/python-nltk now has version number 2.0~b8-0ubuntu1. Thanks for the catch, Rhonda and c_korn.
[13:49] <c_korn> rmunn: is the priority for the package really extra ? I would set it to optional: http://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities
[14:04] <rmunn> Huh. I meant to make it optional, don't know when it got changed to extra. Thanks.
[14:10] <rmunn> OK, new upload at http://revu.ubuntuwire.com/p/python-nltk now has Priority: optional.
[14:33] <c_korn> rmunn: good, you would have my vote if I was a motu :P
[14:46] <mr_steve> statik: thanks for the review of my cnetworkmanager package.
[15:01] <sebner> rmunn: it's not in the archive yet?! Then it should be -0ubuntu1
[15:04] <om26er> are those motu videos still valid. I have been using them and never got succeeded
[15:07] <RainCT_> om26er: I haven't seen them, but I guess they should be. What problem do you have?
[15:09] <rmunn> sebner, the version I have on http://revu.ubuntuwire.com/p/python-nltk is -0ubuntu1 -- which one are you looking at that isn't?
[15:10] <sebner> rmunn: That's true but it should be the _only_ changelog entry
[15:11] <Rhonda> Why so?
[15:11] <Rhonda> Why would one have to strip history?
[15:11] <rmunn> sebner, I originally uploaded a 2.0~b7-0ubuntu1 package, then upstream released 2.0b8 before I had gotten 2.0b7 reviewed. Since 2.0~b7 was my original upload, I left it in the changelog. Should I go back and edit the changelog so *only* the 2.0~b8 entry remains?
[15:11] <sebner> Rhonda: because it has no history when it's not in the archive
[15:11] <sebner> rmunn: exactly
[15:11] <rmunn> sebner, Will do... new REVU upload will be coming shortly
[15:11] <Rhonda> sebner: Isn't it allowed to have a history outside the archive? I consider that a pretty narrow point of view.
[15:12] <Rhonda> Or are debian changelogs stripped off from before the first sync into ubuntu? :)
[15:12] <sebner> Rhonda: The one and only changelog entry before entering the archive is always "Initial Release" as it's the initial archive release
[15:12] <rmunn> Rhonda: It's got plenty of history outside the archive, but the changelog in debian/ only refers to the history of the package -- so the first entry should be the first version of the package, I guess.
[15:12] <sebner> Rhonda: that's something different
[15:12] <Rhonda> It hight have been hosted someplace else before.
[15:13] <sebner> Rhonda: sure but a new package that enters the archive doesn't have a archiv history and is not necessary therefore
[15:13] <Rhonda> rmunn: I still consider that a pretty narrow stand and would challenge it. There is valid reasons to have previous history documented.
[15:13] <sebner> Rhonda: that's against packaging policy though ;)
[15:13] <Rhonda> sebner: Not an archive history within ubuntu. But it might have an archive history someplace else.
[15:14] <Rhonda> I would highly disagree with that impression, please show me that piece.
[15:14] <sebner> Rhonda: that doesn't matter for the package entering Ubuntu for the first time
[15:14] <ScottK> sebner: That's no always true
[15:14] <sebner> ScottK: so?
[15:14] <ScottK> Rhonda: I think what sebner is saying is a good general rule, but I also think there are exceptions.
[15:15] <sebner> ScottK: I've never seen of any "exception" like that before, mind providing an example?
[15:15] <ScottK> sebner: To take it on from a slightly different POV, I took on the klamav package in Debian.  It was unmaintained and broken.
[15:15] <ScottK> Look at debian/changelog.
[15:15] <Rhonda> sebner: When one works with a sponsor it is valid to "request" from the sponsoree to bump the versions so that it's easier to check just the differences and not check the whole thing again.
[15:15] <sebner> ScottK: well, that's more like a special special case
[15:15] <ScottK> Even though it's uploaded in Debian, it's got the Ubuntu history in it.
[15:16] <ScottK> Rhonda: On our tool for this (REVU) it will give you diffs of successive uploads with the same version.
[15:16] <Rhonda> Ah, sounds convenient. :)
[15:16] <sebner> Rhonda: as I said, in 95% of the cases it has to be the one and only entry
[15:17] <Rhonda> s/has to be/should be/
[15:17] <sebner> Rhonda: must be :P
[15:17] <Rhonda> If it's 95% there isn't any "has to be … but". Either it has to, or it doesn't have to.
[15:18] <Rhonda> has to equals must be
[15:18] <Rhonda> A guideline and suggestion must not be written explicit. ;)
[15:19] <sebner> Rhonda: It's not a suggestion imho, except this special case ScottK mentioned it always has to be the only entry. Also with rmunns package.
[15:19] <Rhonda> hmmmmm
[15:20] <Rhonda> rmunn: Who is Robin Munn? I thought this is the initial version of the package?
[15:20] <sebner> I suppose it's him ^^
[15:20] <rmunn> I'm Robin Munn.
[15:20] <Rhonda> Oh, right.
[15:21] <Rhonda> Why aren't you in Maintainer but XSBC-Original-Maintainer? Is that the way it should be?  . o O ( and that might very well be my naive approach to not knowing it :) )
[15:21] <rmunn> Packages in universe should have "ubuntu-motu" as maintainer, I believe.
[15:22] <rmunn> So I put myself as original-maintainer so that any MOTU with questions about the package would know who to contact.
[15:22] <sebner> rmunn: it's Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
[15:23] <rmunn> Hm? https://wiki.ubuntu.com/DebianMaintainerField says (at the end) that it should be ubuntu-motu... has this changed?
[15:24] <rmunn> Oh wait, that's the previous rules.
[15:25] <rmunn> Yet another re-upload coming to fix the Maintainer field... I guess this is why we have a review process. :-)
[15:25] <ScottK> That particular one isn't critical, but may as well get it as fixed as you can right now.
[15:26] <sebner> ScottK: I'm wondering about this wiki site though. Also the "updated" version says Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>. I'll change that?!
[15:26] <ScottK> Please
[15:26] <sebner> aye
[15:27] <Rhonda> #
[15:27] <Rhonda> Otherwise, the Maintainer field will be set to Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
[15:27] <Rhonda> sebner: Where do you see ubuntu-motu?
[15:27] <Rhonda> Or did you already change?
[15:28] <rmunn> Hmmm, any way to tell dput "Yes, I'm forcing an upload with -f, but you don't need to re-upload the .orig.tar.gz since it hasn't changed"? This .orig.tar.gz is only about 830k so it's not a big deal, but if I was maintaining OpenOffice or something that might get rather tedious...
[15:28] <Rhonda> Hmm, no, it's still the same old version from colin.
[15:28] <sebner> Rhonda: ScottK updated
[15:29] <rmunn> Okay, newest version at http://revu.ubuntuwire.com/p/python-nltk now has ubuntu-devel-discuss in maintainer field.
[15:29] <RainCT_> rmunn: I don't think REVU likes uploads without .orig.tar.gz
[15:29] <sebner> https://wiki.ubuntu.com/DebianMaintainerField?action=diff&rev2=20&rev1=19
[15:29] <Rhonda> eeeks
[15:29] <Rhonda> sebner: Your change doesn't make any sense at all :)
[15:30] <sebner> Rhonda: thanks :P
[15:30] <sebner> Rhonda: why? ;)
[15:30] <Rhonda> Now the "Previous rules" section doesn't make any sense to me.
[15:30] <Rhonda> It says the exactly same for main and universe, at least mail address wise?
[15:30] <sebner> ah
[15:30]  * sebner brokes something 
[15:30] <rmunn> RainCT, In this case there's an .orig.tar.gz with the same md5sum already in the REVU queue, a more "clever" dput could potentially check the MD5sum and/or use rsync. Not a big deal, probably.
[15:30] <Rhonda> You changed the _previous_ rules?
[15:31] <ScottK> sebner: Don't change the previous rules.
[15:31] <sebner> ScottK: sorry, mistake -.-
[15:31] <Rhonda> ScottK: We are there already. ;)
[15:31] <ScottK> rmunn: REVU is Free software.  Patches welcome (it's written in Python).
[15:32] <RainCT> rmunn: If you upload without the .orig.tar.gz (which you can do using debuild with the -sd option, btw, iirc) it won't be listed in the .changes file, which REVU uses to know which files the package has
[15:32] <Rhonda> sebner: I think just reverting your change would be the sensible way to do?
[15:32] <RainCT> (but as ScottK just said, if anyone wants to fix this so that REVU looks for previous .orig.tar.gz files when one is missing, I'd be happy to review the patch)
[15:32] <rmunn> ScottK, Hey, my favorite language! Mental note made, and filed in the Copious Free Time category. (Which, sadly, means "probably not anytime soon...")
[15:32] <ScottK> Undertsand
[15:33] <RainCT> Although, the relevant code for this is a shell script, not Python
[15:33] <sebner> Rhonda: yeah done already. I'm a little bit confused today ^^
[15:33] <Rhonda> No worries. :)
[15:33] <RainCT> (or maybe it is Python.. meh, haven't touched REVU since too long :P)
[15:33] <Rhonda> sebner: Reviews everywhere. :P
[15:35] <sebner> ScottK: but the maintainer for universe *is* Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com> nowadays?! update-maintainer proposes
[15:35] <ScottK> sebner: That's correct.
[15:35] <sebner> ScottK: so my change was right?!
[15:35] <ScottK> Not as part of the previous rules.
[15:35] <ScottK> That's current rules
[15:36] <sebner> ahhh
[15:36] <sebner> I misread
[15:36] <sebner> I'm sorry :(
[15:36] <mr_steve> Now I'm confused to. If I submit a package to REVU for Universe, Maintainer: should be Ubuntu Developers, not Universe Maintainers?
[15:37] <randomaction> it should be Ubuntu Developers (and REVU lies about it)
[15:37] <RainCT> mr_steve: Yeah
[15:38] <mr_steve> Okay, thanks.
[15:38] <randomaction> rmunn: it you want to exclude orig.tar.gz from upload, tell debuild about it (-sd)
[15:51] <RainCT> randomaction: fixed (MOTU -> Ubuntu Developers)
[15:51] <randomaction> RainCT: thank you :)
[15:51]  * Laney nibbles at RainCT 
[15:52] <RainCT> Laney: I'm not a cookie!
[15:55]  * iulian remembers RainCT's cookie game.
[15:55] <iulian> I was too stupid to play it. :(
[15:55] <randomaction> packages.ubuntu.com also lies about maintainer, e.g. http://packages.ubuntu.com/lucid/claws-mail-extra-plugins says MOTU, apt-cache says ubuntu-devel-discuss
[15:56] <RainCT> iulian: heheh   That was great, wasn't it? :P  I may still have it somewhere...
[15:56] <iulian> Not that I'm not anymore...
[15:56] <iulian> RainCT: Oh, really?
[15:58] <RainCT> iulian: Actually no, (unless it's in some backup CD, but I haven't done backups for ages). "find | grep -i cookie" didn't find it :(.
[15:58] <ScottK> randomaction: It was probably not updated somewhere yet.  Not all packages have been changed.
[15:59] <randomaction> ScottK: package was built 11 days ago
[16:00] <ScottK> randomaction: Does p.u.c use the development release or the current release for that data?
[16:01] <randomaction> ah, indeed, it may differ. I'll apt-cache it in karmic
[16:02] <randomaction> u-d-d in karmic as well. Maybe it uses oldest release or something?
[16:04] <jldupont> hi - I need some help with a developer level question: http://stackoverflow.com/questions/2208400/apt-get-environment-variables-when-spawning-make
[16:14] <jldupont> ... or is there a more appropriate channel for my question?
[16:28] <amarillion> jldupont, it tends to be quiet here
[16:28] <amarillion> but I don't think you should do user-specific things like that in a deb package, they're for system-wide installation
[16:29] <Pici> aye.  Why is apt-get spawning make anyway?
[16:34] <kklimonda> how is debian/rules spawned by apt-get during installation btw?
[16:34] <micahg> has anyone seen this build failure before: dpkg-genchanges: failure: cannot read files list file: No such file or directory
[16:46] <amarillion> jldupont, I've answered on stackoverflow
[17:08] <sluimers> So this is the place to be if you want to upload a package to archive.ubuntu.com/universe
[17:09] <maxb> yes
[17:10] <sluimers> It gives me the impression I ought to keep tabs of other packages as well once I become part of the team.
[17:40] <lifeless> persia: xorg-edgers xvfb now has RANDR
[17:41] <persia> Hurrah!
[17:42] <persia> Now just a couple more steps, and I can press the give-back button lots of times :)
[17:45] <fabrice_sp> Hi again. New liblo ships liblo-dev as dev lib, that 'provides' liblo0-dev (old dev package). Shouldn't be liblo0-dev deleted from Lucid to avoid using old version for packages using liblo0-dev? I rebuild one of the dependent packages, and it's still using old lib :-/
[17:46] <fabrice_sp> !info liblo0-dev | lucid
[17:46] <fabrice_sp> !info liblo-dev | lucid
[17:46] <persia> fabrice_sp: liblo0-dev is in NBS.
[17:47] <persia> But there's lots of source changes needed.
[17:47] <persia> You might want to try to contact ScottL, who was also looking into this.
[17:47] <fabrice_sp> ok: I created a bug for the transition
[17:47] <persia> I thought he did also, so there may be two.
[17:48] <persia> But they're surely dupes, if so, and can be collapsed.
[17:48] <fabrice_sp> I checked the rdepends before
[17:48] <fabrice_sp> ok. I'll  check with him
[17:48] <fabrice_sp> most packages should be buildable if liblo0-dev were deleted ,anyway
[17:48] <persia> Well, he should see the highlight in backscroll :)
[17:49] <fabrice_sp> yes :-D
[17:49] <persia> liblo0-dev won't be deleted until all the packages build-depending on it are gone.
[17:49] <randomaction> wow, its soname jumped up by 7
[17:49] <persia> If you really want to push it, go hassle the archive-admin-of-the-day in #ubuntu-devel
[17:49] <fabrice_sp> even if the new liblo-dev provides it?
[17:49] <persia> Yeah :)
[17:49] <fabrice_sp> yeah :-)
[17:49] <fabrice_sp> it's bug 517416 ;-)
[17:50] <persia> Right, because it takes someone to investigate before it gets removed: the archive-admins typically wait until someone else investigates unless they have lots of extra time.
[17:50] <persia> (and the newer liblo just entered NEW about 20 hours ago)
[17:50] <fabrice_sp> they sometimes have extra time? :-D
[17:51] <persia> Rarely :)
[17:51] <fabrice_sp> :-D
[17:52]  * fabrice_sp will reboot so that Xorg frees the 1Gb memory hostage it has right now
[17:54] <StevenK> ScottL, fabrice_sp: I'm happy to take a bunch of those rebuilds (like 10 or so) and just do them
[17:58] <StevenK> ScottL, fabrice_sp: I'm happy to take a bunch of those rebuilds (like 10 or so) and just do them (reprise)
[17:59]  * persia thinks today is such a rare day
[17:59] <fabrice_sp> StevenK, cool: I think that before rebuilding them, we should delete the old dev lib (liblo0-dev), as it's providedby the new liblo-dev package
[17:59] <StevenK> We can do that
[18:00] <fabrice_sp> some of them will FTBFS, as reported to Debian, but it's an easy patch :-)
[18:00] <persia> Surely that's just ABI transitions
[18:00]  * persia puts 5 on StevenK vs. Soyuz
[18:00] <StevenK> Done. I win.
[18:01]  * persia collects
[18:01] <fabrice_sp> great! :-)
[18:01] <StevenK> fabrice_sp: So I'm happy to take a bunch and do rebuilds on them
[18:03] <fabrice_sp> StevenK, ok: so how will we proceed? You submit the rebuilds, and if it FTBFS, we reopen the task in the bug 517416 ? (and I'll invalid them now?)
[18:05] <StevenK> fabrice_sp: So I can sort out rebuilds (as soon as the publisher runs) and see how many fail
[18:06] <fabrice_sp> StevenK, ok. The ones that have versioning dependency on liblo0-dev will fail. I saw at least 3 of them (don't remember which ones right now)
[18:08] <StevenK> fabrice_sp: Right. I'll get started in about an hour.
[18:08] <fabrice_sp> ok. Thanks :-)
[18:11] <geser> StevenK: can you please remove the old texlive-base-bin debs (NBS)? the packages listed in http://people.canonical.com/~ubuntu-archive/NBS/texlive-base-bin have an unversioned dependency on texlive-base-bin (now provided by texlive-binaries). the only exception is jadetex and a fix waits already on sponsoring. That would unblock some TeXlive related FTBFS as the buildds tries the old (now
[18:11] <geser> uninstallable) real package.
[18:11] <StevenK> geser: Sure, I'll kill it now
[18:12] <geser> thanks
[18:16] <StevenK> Well. Now ish. Sigh.
[18:20] <StevenK> geser: texlive-base-bin{,-doc} or just -base-bin?
[18:33] <geser> I haven't checked -doc yet, I only checked -base-bin for now
[18:36] <quadrispro> fabrice_sp, ping
[18:37] <quadrispro> fabrice_sp, about liblo transition: I think that no-change rebuilds is not enough. We should replace build-dependencies on liblo0-dev with another on liblo-dev
[18:39] <quadrispro> fabrice_sp, otherwise the transition won't bring benefits :)
[18:48] <fabrice_sp> quadrispro, pong. That's because we needs to delete first the old liblo0-dev (done by StevenK :-) ), provided now by liblo-dev. I saw you uploadednekobee. By the way, some packages FTBFS in Debian too
[18:49] <fabrice_sp> StevenK will do rebuilds on some of them
[18:49] <StevenK> Well, I'll see which just build and upload them
[18:49] <fabrice_sp> see 48 minutes ago ;-)
[18:49] <quadrispro> fabrice_sp, sure, they FTBFS because new liblo is in experimental and liblo-dev is not available in sid
[18:50] <fabrice_sp> Quadrispro, see Debian bug 530852
[18:50] <fabrice_sp> it seems it's because of versioned dependency
[18:52] <fabrice_sp> (also debian bug 530859 and some others in that list)
[18:52] <quadrispro> ok, should we wait for new liblo entering in unstable?
[18:54] <fabrice_sp> don't know: some bugs has been opened a quite long time ago, and nothing happened (even if it was safe to update the package with non versioned dependency)
[18:55] <fabrice_sp> as most (if not all) packages are maintained by Debian Multimedia Team, we should perhaps update the packages first in Debian
[18:55] <fabrice_sp> and sync them after
[18:56] <persia> My fear there is Alpha3, because a number of these packages ship on the Studio DVD.
[18:58] <quadrispro> and it's likely to be hard to get them fixed in debian (then synced in ubuntu) before FF being in effect
[18:59] <ScottK> So do both.
[18:59] <ScottK> Fix here and Debian and then sync.
[18:59] <quadrispro> I agree
[18:59] <fabrice_sp> just what I saw going to write :-D
[19:00]  * quadrispro going to choose a kind of pasta
[19:02] <fabrice_sp> StevenK, dssi still get dependency on old liblo package
[19:03] <quadrispro> fabrice_sp, already fixed
[19:03]  * StevenK starts
[19:04] <fabrice_sp> right. Sorry: it was another transition :-/
[19:05] <quadrispro> fabrice_sp, please re-upload whysynth
[19:06] <quadrispro> fabrice_sp, you didn't change the build-dep on liblo0-dev
[19:06] <quadrispro> http://launchpadlibrarian.net/38782264/buildlog_ubuntu-lucid-i386.whysynth_20090403-1build1_FULLYBUILT.txt.gz
[19:07] <StevenK> quadrispro: I should drop whysynth from my list?
[19:08] <quadrispro> StevenK, whysynth is not fixed
[19:08] <quadrispro> and I think it's the same for xsynth-dssi
[19:08] <quadrispro> yup -> http://launchpadlibrarian.net/38781708/buildlog_ubuntu-lucid-i386.xsynth-dssi_0.9.0-2ubuntu3_FULLYBUILT.txt.gz
[19:10] <quadrispro> guys, let's use the "Assigned to" feature :D
[19:12] <AntoineLeclair> hey, anyway, I would like to fix this bug: https://bugs.launchpad.net/ubuntu/+source/pgadmin3/+bug/347256
[19:13] <AntoineLeclair> pretty easy to fix, but I never fixed a bug in a package in Ubuntu
[19:13] <AntoineLeclair> would need some help (either *take me by the hand* or *point me the appropriate docs*)
[19:14] <AntoineLeclair> *anyway -> anyone
[19:14] <fabrice_sp_> AntoineLeclair, see https://wiki.ubuntu.com/MOTU/Contributing
[19:15] <fabrice_sp_> it will explain you how to prepare a debdiff
[19:16] <AntoineLeclair> fabrice_sp_: thanks, I'll read this and come back for questions, if any (there will probably be some ;))
[19:16] <fabrice_sp_> you're welcome ;-)
[19:25] <fabrice_sp_> AntoineLeclair, by the way: if you are working on this bug, assign it to yourself, with status 'In progress' so that other users knows you are working on it
[19:27] <AntoineLeclair> fabrice_sp_: ok, I'll do that when I know I have learned enough to fix it
[19:27] <fabrice_sp_> ok
[19:27] <fabrice_sp_> lol
[19:27] <ari-tczew> fabrice_sp_: could you check whether do I have correct debdiff for fakesync? bug 517297
[19:28] <AntoineLeclair> fabrice_sp: lol!! don't laugh :P
[19:29] <fabrice_sp> :-D
[19:31] <fabrice_sp> ari-tczew, it's in main: I prefer to let a Main sponsor to have a look. Anyway, and in general, I'm not sure about the value of a fakesync. If there are differences, you can always  replicate the Debian changesi in the Ubuntu package
[19:31] <statik> what is a fakesync
[19:31] <statik> ?
[19:32] <fabrice_sp> statik, it's when you can't sync a package from Debian because the orig tarball is different
[19:33] <statik> oh wow. when does that happen?
[19:33] <fabrice_sp> so you take the Ubuntu orig tarball, and 'copy' the Debian debian directory
[19:33]  * statik nods
[19:34] <fabrice_sp> when you repack the tarball, for example, or for some reason, the tarball has one change (last fakesync I looked, it was the date of one directory)
[19:34] <fabrice_sp> so you either wait a new upstream release to do the sync, and maitain the package in paralell or do a fakesync
[19:35] <statik> i see. thanks for explaining me!
[19:35] <fabrice_sp> you welcome ! :-)
[19:35]  * fabrice_sp discovered the fakesync not so long ago :-)
[19:36] <randomaction> it's an undocumented feature
[19:36] <fabrice_sp> right: even ubottu doesn't know about it :-D
[19:36] <fabrice_sp> !fakesync
[19:36] <fabrice_sp> ubottu> Sorry, I don't know anything about fakesync
[19:36] <randomaction> ubottu is really weak in this area
[19:37] <randomaction> !sync
[19:37] <randomaction> Aha, not so much anymore!
[19:37] <fabrice_sp> :-D
[19:37] <ScottL> ScottK, i've built all (i think) packages on the liblo0-dev NBS list, what can I do to help you and fabrice_sp ?
[19:37] <ScottL> built them in pbuilder, that is
[19:37]  * randomaction thanks whoever taught ubottu this
[19:37] <jldupont> I am confused: where do I drop the ".desktop" file upon installation of my package?  I can see .desktop file being dropped at multiple places: /usr/share/app-install , /usr/share/applications
[19:37] <persia> ScottL: I think you wanted StevenK
[19:38] <lfaraone> I fixed bug 479131 in a 0.2 upload, but because the error occurs on package removal or reinstallation (when the service is stopped), people who have already installed the package will continue to have problems. How should I go about fixing this?
[19:38] <persia> jldupont: /usr/share/applications : the ones in /usr/share/app-install are used for something else entirely.
[19:38] <jldupont> persia: like what?
[19:38] <persia> I think it's now called "Software Centre"
[19:38] <fabrice_sp> ScottL, I think the transition is quite well advanced (see bug 517416)
[19:38] <lfaraone> (or should I just tell people to "LANG=C apt-get upgrade" first?)
[19:38] <ScottL> persia, lol, yeah,
[19:39] <jldupont> persia: so if I only care about an apt-get install flow, I can safely disregard /app-install ?
[19:40] <ScottL> fabrice_sp, okay
[19:41] <jldupont> even "rhythmbox" gets 2 entries i.e. /usr/share/applications and /usr/share/app-install
[19:41] <jldupont> Is it like a "copy" of /usr/share/applications being made by "Software Center" in the /usr/share/app-install ??
[19:43] <jldupont> amarok, a typical KDE based application, gets two entries too...
[19:46] <jldupont> what about icons?  I can see lots of apps have entries in /usr/share/app-install/icons and /usr/share/icons
[19:47]  * persia hunts up the spec
[19:47]  * jldupont appreciates persia is hunting for answers
[19:48] <persia> http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html is the closest I find.
[19:48] <persia> I tend to just throw everything in pixmaps, but I know that to be wrong
[19:51] <jldupont> persia: thanks for the pointer!  Looks like it answers my question regarding icons.  I guess a similar document for .desktop would exist and state /usr/share/applications ...  what about the /usr/share/app-install  folder???
[19:51] <persia> /usr/share/app-install is special for the software centre.  Ignore it.
[19:52] <persia> http://standards.freedesktop.org/menu-spec/latest/index.html talks about menus (and has the Categories list), and a link to the .desktop spec
[19:52] <jldupont> persia: I'll that as cash and run... thanks!
[19:52] <jldupont> So, if I understood correctly, Ubuntu strives to align to Freedesktop standards, right?
[19:53] <persia> Um, that's not how I'd phrase it, but it could work.
[19:53] <jldupont> then, what is the guideline?
[19:54] <persia> I'd prefer Ubuntu includes software that conforms to the freedesktop standards, and prefers applications depending on these features to be compliant.
[19:55] <persia> Because I'm not sure we spend a lot of time forcing stuff to be compliant, so much as when stuff isn't compliant, it just doesn't work (but for reasons somewhat out of our control)
[19:55] <jldupont> hmm... I understand the subtle difference.... thanks.
[19:57]  * jldupont appreciates persia's comments.
[19:59] <\sh> "Do not try and bend the standard. That's impossible. Instead...only try to realize the truth."
[19:59] <\sh> "What truth?"
[19:59] <\sh> "There is no standard"
[19:59] <jldupont> :-)
[19:59] <\sh> ;)
[19:59] <StevenK> "That there are so many standards to bend, and only so many hours in the day."
[20:00] <\sh> "There is no standard?"
[20:00] <\sh> "Then you'll see, that it is not the standard that bends, it is only yourself"
[20:00]  * jldupont will Matrix in his movie pipeline again.
[20:01]  * persia inserts a dropped put
[20:02] <\sh> "Package Maintainer, sooner or later you're going to realize just as I did that there's a difference between knowing the standard and implementing the standard"
[20:02] <ScottK> Then you're well on the way to not caring anymore.
[20:02] <ScottK> ;-)
[20:03] <\sh> ScottK: "Welcome to the real world." ;)
[20:03]  * jldupont having flashbacks of black leather........
[20:04]  * ScottK is busy trying to mentally will a co-worker into caring more about actual functionality than renaming table names from singular to pural becuase "that's how it's done".
[20:04] <\sh> ScottK: or should I quote: "ScottK, what do you need? Besides a mircale?" "ScottK: Guns! Lot's of guns."
[20:04] <Rhonda> Can I have the red pill please?
[20:05] <jldupont> " let's go see the Oracle to resolve this matter "
[20:05] <ScottK> Guns have their place, but currently my need is for mousetraps.
[20:05] <\sh> ScottK: oh well...I told exactly that to the Chief of Development in our Company
[20:05]  * ScottK 's house is infested
[20:05] <Rhonda> jldupont: Can we the elephant instead?
[20:05] <persia> Have you considered mongeese?
[20:05]  * Rhonda inserts a "see"
[20:06] <ScottK> persia: I'm doing OK.  I've gotten 1 - 4 a day for the last several days, so I'm convinced I'm making progress.
[20:06] <persia> heh.  Indeed.  They breed quickly, but not that fast.
[20:06] <ScottK> It seems to be slowing down.  Either the residual population is smarter or they are running out.
[20:06] <jldupont> Rhonda: ;-)
[20:07] <\sh> Rhonda: -> Gerfried? (just asking, because I don't know :))
[20:07] <Rhonda> \sh: You are asking what exactly? :)
[20:07] <Rhonda> I can't decypher your APL syntax.
[20:07] <\sh> Rhonda: if Rhonda matches Gerfried in RL :)
[20:08] <\sh> as in "Gerfried the ejabberd maintainer in Debian"
[20:08] <Rhonda> Only to some degree, but yes.
[20:08] <\sh> Rhonda: nice to meet you :)
[20:08] <Rhonda> That's rather Konstix. I mostly do just mentoring and uploading.
[20:09] <Rhonda> http://www.cafepress.com/VEwarning <-- that shirt fits your question best I'd say.
[20:10] <sebner> huhu \sh :D
[20:10] <\sh> Rhonda: lol :)
[20:10] <\sh> sebner: hey friend :) how's life? :)=
[20:10] <Rhonda> But I wonder how you brought me into context with ejabberd. I'm not in the Maintainer field and there isn't much that I've done to the package, to be honest …
[20:10] <Rhonda> \sh: Well, but it's true and describes me best. :)
[20:11] <sebner> \sh: busy! now 1 month of holidays :D  I have to re-take some exams after the holidays though ^^
[20:11] <Rhonda> I mean, most people put me into context with wesnoth. This is what I can understand. Or irssi. But … ejabberd? :)
[20:11] <sebner> \sh: how's your life going? Your blogpost made me sad. everything alright?
[20:11] <\sh> Rhonda: just asking because I need some expertise with migrating ejabberd databases from one host (with more then two vhosts) to another host (where only 2 of the old vhosts needs to migrate)
[20:12] <\sh> sebner: no..everything's right..I just need to get rid of stuff to get more out of my private life:)
[20:12] <Rhonda> \sh: See, and I will redirect you for that question to konstix. ;)
[20:12] <sebner> \sh: sure, private life (family) comes first! :)
[20:12] <\sh> Rhonda: I made my notes already :)
[20:13] <Rhonda> \sh: I created a jabber conference at ejabberd@chat.deb.at for the purpose of team maintenance. You can find konstix in there at times. But I guess that question is better suited in the upstream jabber conference, let me look it up …
[20:14]  * \sh should takeover nexuis from Rhonda ;)
[20:14] <Rhonda> Feel free. I suck at that game anyway, and it's *way* too large to build on my system anyway.
[20:15] <Rhonda> \sh: ejabberd@conference.japper.ru is the proper place for that question. :)
[20:15] <Rhonda> They are quite helpful there, just like usual, don't sound too pushy with your question.
[20:16] <\sh> Rhonda: thx :) :)
[20:17] <sebner> \sh: uhh bad idea. You know, all the testing you have to do :P
[20:18] <\sh> Rhonda: /me + playing nexuis = #fail , but I know how to build the source packages :)
[20:19] <\sh> sebner: I have MrVaporUp to do the testing ;) he's a very damned good ego shooter player...
[20:19] <Rhonda> \sh: Congrats on proper hardware for that. Building wesnoth is already killing me - nexuiz-data sucks even more. :)
[20:20]  * Rhonda is off for the weekend, bye!
[20:20] <\sh> Rhonda: have a nice one...just waiting for my tram to go home now
[20:20] <sebner> \sh: hahah, I'm just happy we have fuddl ;)
[20:21] <\sh> hmm..on hardy there is my "2.4-1" name tag on nexuiz (I'm scared now)
[20:21] <sebner> hahaha!
[20:22] <\sh> micahg: we suggests the dojo packages when it's gone through NEW
[20:22] <micahg> \sh: k
[20:22] <micahg> \sh: I verified that 1.3.2 will work with 1.10
[20:23] <\sh> sebner: fuddle has a tauware.de email address, which means he and siretart are somehow related ;)
[20:24] <\sh> sebner: which makes me feel happier now ;)
[20:25] <\sh> micahg: well, I think ZF will work with dojo also with 1.4.1
[20:26] <micahg> \sh: k, but 1.3.2 was in debian
[20:26] <micahg> \sh: they ship 1.4.0 with 1.10
[20:26] <feasty> Hi all, can anyone help me as I have a fix for 2 bugs in an application that are on launchpad and I just want to make sure I get the process correct. I have my debdiff which contains both fixes in. Do I just add it as an attachment to each of the bugs it fixes and leave a comment?
[20:26] <\sh> micahg: yeah...old stuff, but usable
[20:27] <feasty> If it wasn't obvious enough its my first bugfix on Ubuntu.
[20:27]  * \sh declares web js libraries and web applications not usable with binary only non rolling linux dists
[20:27] <micahg> \sh: +1 :)
[20:27] <persia> feasty: That's a good start.  You probably want to subscribe a sponsors queue to one of the bugs (no need to do both)
[20:27] <sebner> \sh: yeah and sistpoty too, they are all together at the same university. I think fuddel writes a Doktorarbeit? with siretart looking over it
[20:28] <feasty> persia: is that the subscribers list on the right hand side of the bug page?
[20:28] <persia> Yes
[20:29] <micahg> \sh: is it worth trying to get ZF into debian?
[20:29] <\sh> sebner: regarding http://gallery.sourcecode.de/v/album_003/album_001/album/album_001/P1000071.JPG.html I know ;)
[20:29] <feasty> persia: And then what. Do I just attach my debdiff to the bug? It says in the help I should notify a developer who can confirm it. Do I need to do that?
[20:29] <\sh> micahg: yes there is an ITP for ZF and I wanted to upload it to mentors, but don't find the time for it..if you have, please try to include it into debian
[20:30] <sebner> \sh: hahah! :P
[20:30] <micahg> \sh: ok, if I can find the time :)
[20:31] <\sh> micahg: hehe..as said, please do...if you can get it into debian as maintainer, I'm happy...
[20:31] <micahg> \sh: k
[20:31] <\sh> micahg: and I can mail andy that ZF will be available in debian as well
[20:32] <micahg> \sh: once the mozilla stuff slows down a little maybe I can try for that
[20:32] <micahg> worse case, I'll do it after Lucid release :)
[20:33] <\sh> micahg: well, no problem...when you get the upload to debian, you'll take the maintainership, which means I can do more work on some very strange projects I have on my list ;)
[20:33] <micahg> \sh: k, cool :)
[20:33] <micahg> maybe by then I can apply for MOTU :)
[20:33] <randomaction> feasty: https://wiki.ubuntu.com/SponsorshipProcess
[20:34] <feasty> ah cheers randomaction
[20:35] <\sh> micahg: you could do now afaik ;)
[20:36] <micahg> \sh: I think I need a few more uploads to qualify :)
[20:36] <\sh> micahg: lucid +1 => take my merges ;)
[20:37] <micahg> \sh: k, is there a list?
[20:38] <micahg> \sh: what types of packages?
[20:41] <\sh> micahg: merges.ubuntu.com for the next cycle...
[20:48]  * \sh <- gone
[20:52] <feasty> how do I subscribe to the ubuntu-universe-sponsors? I cant seem to find where I do it.
[20:53] <fabrice_sp> feasty, on the right, in laucnhpad
[20:53] <randomaction> "subscribe someone else" link
[20:56] <feasty> What page is that on though? Is that under the individual bug?
[20:57] <fabrice_sp> can you link your bug number?
[20:58] <feasty> thats one of them: https://bugs.edge.launchpad.net/ubuntu/+source/twitux/+bug/339257
[20:59] <feasty> I subscribed on the right hand side. I was unsure how this sponsorship works from the wikiw page description. I couldn't see where I subscribed to the group
[20:59] <segler> hi, i need help with a package on revu. i made the changes that people pointed out in the comments. http://revu.ubuntuwire.com/p/rhythmbox-radio-browser
[20:59] <fabrice_sp> on the top right part, you have 3 blocks, first one is "This report is public", and in the third, you have a green + and Subscribe someone else
[21:01] <feasty> do I subscribe ubuntu-universe-sponsors in there?
[21:02] <fabrice_sp> feasty, yes
[21:03] <fabrice_sp> Hi segler . You should try to know who owns the copyright on the images you added
[21:03] <feasty> ah brilliant thanks. Sorry I was totally lost with it. To clarify, I just upload my patch to it, add a comment and subscribe ubuntu-universe-sponsors. Then wait and see?
[21:03] <michas> Hi together. I currently packaging a new piece of software, trying to get it into ubuntu and debian. Do I need to set up two seperate source packages, or is it possible to use a single source package for both ubuntu and debian?
[21:04] <fabrice_sp> feasty, yes
[21:04] <feasty> fabrice_sp, thanks for that.
[21:05] <fabrice_sp> yw :-D
[21:06] <ScottK> michas: Except for some very minor differences they should be the same.
[21:08] <randomaction> michas: if you get it into Debian, it will go into Ubuntu automatically (but not vice versa)
[21:13] <michas> randomaction, ok, than I'll concentate on debian and ignore ubuntu for the moment. :)
[21:14] <michas> ScottK, are there common "minor differences", I should be aware of or can I usually simply put it into debian?
[21:15] <ScottK> Maintainer field or original maintainer in debian/control and revision/distro in debian/changelog
[21:17] <feasty> If I have one patch file which fixes 2 bugs then should I upload it to both bugs or just comment in one of them that it fixes both bugs and link the second bug back to the first?
[21:18] <feasty> should I subscribe ubuntu-universe-sponsors to both bugs?
[21:19] <fabrice_sp> feasty, only upload it in one, and reference the bug where you uploaded it in the other bug
[21:19] <fabrice_sp> and subscribe u-u-s to the bug where debdiff has been attached
[21:19] <geser> attach to one bug and add a comment to the other (so others know where to look) and subscribe u-u-s to the bug with the attachment
[21:20] <AntoineLeclair> I made a patch for https://bugs.launchpad.net/ubuntu/+source/pgadmin3/+bug/347256 I made a .debdiff, is that what is needed?
[21:20] <michas> It's a new piece of software, hence I will be the only maintainer. changelog should be the same. (unless I really need some different name scheme.) If I don't need to change something Ubuntu specific, is there any good reason to explicitly building a ubuntu package?
[21:22] <fabrice_sp> AntoineLeclair, yes
[21:22] <AntoineLeclair> fabrice_sp: thanks, I'll upload the patch then, I hope all is fine :)
[21:22] <feasty> fabrice_sp, thanks again
[21:22] <fabrice_sp> and don't forget to subscribe u-u-s
[21:22] <fabrice_sp> AntoineLeclair, ^
[21:23] <fabrice_sp> feasty, ;-)
[21:28] <michas> ScottK, If I don't need to change anything Ubuntu specific on the code itself, is there any good reason to explicitly building a ubuntu package?
[21:28] <fabrice_sp> michas, because of libs, for example
[21:29] <ScottK> michas: Only if you want stuff formatted for acceptance into Ubuntu.
[21:29] <ScottK> It's generally better to try and get things into Debian if you can.
[21:30] <michas> ScottK, ok, so getting it into Debian is automatical a acceptance into Ubutu, right?
[21:30] <ScottK> michas: Depending on timing, yes.
[21:31] <ScottK> For the next ~ two weeks it's automatic
[21:31] <michas> ScottK, what is after the next two weeks?
[21:31] <rmunn> Debian merge deadline is this coming Thursday, isn't it?
[21:32] <ScottK> Wait for the next release (when it's automatic) or get a freeze exception.
[21:32] <michas> ok, I think I see. :)
[21:32] <michas> I'll hurry up. ;)
[21:33] <randomaction> even if it were uploaded into Debian today, it has a chance of sitting in the NEW queue until past the freeze
[21:34] <ScottK> Certainly, but New has been pretty quick recently
[21:34] <ScottK> (generally)
[21:34] <Laney> Debian source NEW is fast these days
[21:34] <Laney> in general
[21:35] <Laney> 1 and 3 days for my packages that were done in the past week :)
[21:36] <michas> ok, if the package needs more time, then I should at least have good chances getting it into the following ubuntu release.
[21:37] <Laney> backports will be available to you
[21:38] <michas> Is there an official place, where things like merge deadlines are announced?
[21:38] <Laney> !lucid
[21:38] <Laney> !releaseschedule
[21:38] <Laney> bah
[21:38] <Laney> https://wiki.ubuntu.com/LucidReleaseSchedule
[21:41] <Philip5> if i have no preferences and want to start to use a patch system for my packages is dpatch or quilt the way to go? (i don't want to start a flamewar)
[21:42] <Philip5> are there any pros or cons with either or them or mostly a matter of taste?
[21:42] <sebner> Philip5: If you also use debhelper(7) you should go with quilt
[21:43] <Philip5>  i do
[21:43] <Philip5> quilt is what i feel is the new and dpatch whats been
[21:44] <ScottK> Quilt is easier to integrate into debian/rules.  Dpatch with dpatch-edit-patch is easier to use if you aren't familiar with quilt.
[21:44] <ScottK> Quilt is more capable in many respects, but most of this capability is not relevant to most packages
[21:45] <statik> Philip5, there is some good info here http://wiki.debian.org/Projects/DebSrc3.0
[21:45] <sebner> ScottK: well, that depends .. I always found quilt easier than dpatch, even at the beginning
[21:45]  * ScottK can't imagine what would be easier than dpatch-edit-patch patchname, edit files, exit when you're done
[21:46] <sebner> ScottK: quilt push foo, edit, quilt refresh, quilt pop :P
[21:46] <rmunn> I used cdbs-edit-patch when I was making the package I just uploaded to REVU... then upstream came out with a new release that fixed the problems I was patching and I could delete my debian/patches directory. Joy!
[21:46] <ScottK> That's harder
[21:46] <ScottK> rmunn: Congrats
[21:47] <rmunn> ScottK: It helps that I was in touch with upstream about the problems, and that one of NLTK's authors is a co-worker of mine. :-)
[21:47] <sebner> urgh
[21:47] <ScottK> :-)
[21:49] <Philip5> statik: thanks, i'll have a read
[21:52] <kamalmostafa> Hi ScottK -- time for your friendly weekly reminder that we've been sitting on libtifiles/libticalcs for three weeks now.  I don't think it will take long to review, and I'd really like to get it off my plate.
[21:52] <ScottK> kamalmostafa: Certainly.  Should be able to get to it tomorrow.
[21:52] <kamalmostafa> ScottK: Excellent -- thanks!
[22:55] <ari-tczew> [exec] MozEmbed.cpp:791: error: 'PR_Unlock' was not declared in this scope
[22:55] <ari-tczew> or
[22:56] <ari-tczew> [exec] MozEmbed.cpp: In function 'gboolean gs_dispatch_cb(GSource*, gboolean (*)(void*), void*)':
[22:56] <ari-tczew> anyone knows how fix this ftbfs?
[22:56] <crimsun> ubuntu-mozillateam may be of more assistance
[22:58] <ari-tczew> I guess that this is problem with gcc 4.4
[23:05] <geser> StevenK: did you already removed texlive-base-bin? (texlive-base-bin-doc can also go away as its only rdepends is texlive-base-bin)
[23:07] <StevenK> geser: I didn't, I was waiting for you. I'll kill them both in a little while.
[23:08] <geser> that explains why it's still there :)